Как мы измеряем

Нажмите «Начать тест», и браузер около минуты будет занят четырьмя вещами: скачает пару файлов, опросит десять доменов, постучится на десять часто блокируемых сайтов и загрузит набор изображений, размеры которых нам заранее известны. Все выполняется на стороне клиента; сервер получает только результаты. Эта страница разбирает каждый шаг — что он может сказать и чего не может. Процедура совпадает с Circumvention Central от GreatFire, плюс два наших дополнения: проверка доступности и пик в параллельных потоках.

Скорость

Для каждого URL теста скорости выполняется один fetch с cache: 'no-store', после чего тело ответа читается как поток — байты считаются по мере поступления, а не после получения всего файла. Чтение останавливается на конце файла или по истечении лимита времени, смотря что наступит раньше. speed = bytes read / elapsed time.

Сейчас URL два: наш собственный /api/speedtest-file (50 МБ случайных байтов, лимит 15 секунд) и speed.cloudflare.com/__down от Cloudflare (тоже 50 МБ, лимит 10 секунд). Зачем два? Локальный файл измеряет путь от вас до нашего сервера; файл Cloudflare — путь до ближайшего узла глобального CDN. Эти два пути часто выходят из страны через разные точки. Инструмент может летать до CDN и еле ползти до обычного VPS — или наоборот.

«Скорость» в таблице — это avgAll, среднее по обоим файлам. Это основная метрика, соответствующая averageSpeedAllFiles у GreatFire. Мы также считаем avgVideo — среднее только по нелокальным файлам, — которое идет в оценку качества видео ниже.

Наше дополнение: параллельная загрузка в 3 потока в течение 5 секунд с локального файла, суммарная пропускная способность которой записывается как max. Однопоточная загрузка целиком зависит от контроля перегрузки TCP и потерь пакетов — а трансграничные маршруты с потерями именно этим и славятся. Три потока показывают, что маршрут способен пропустить; большой разрыв между max и однопоточным числом обычно означает серьезные потери.

Задержка

Тест задержки отправляет по 2 запроса HEAD на каждый из 10 доменов с mode: 'no-cors', cache: 'no-store' и таймаутом 8 секунд. Каждый успешный запрос дает один замер времени; медиана двадцати замеров — задержка теста. Неудачи попадают в список failures.

Выбор no-cors заслуживает пояснения. Браузер не позволяет странице читать ответы с чужих источников, но в режиме no-cors запрос все равно уходит — просто в ответ приходит «непрозрачный» (opaque) объект. Ни кода статуса, ни тела, но момент прихода ответа известен. Это все, что нам нужно: нас интересует только время обхода.

Цена этого — мы не можем отличить 200 от 403 или редиректа. Запрос, который сервер отклонил, выглядит так же, как обслуженный. Соединения, которые Великий китайский файрвол сбрасывает или роняет, проявляются как таймауты или как исключение из fetch — они записываются как неудачи и в замеры задержки не входят.

Несколько известных источников шума: браузеры кэшируют DNS, поэтому второй запрос к домену может пропустить разрешение имени; повторное использование HTTP-соединений означает, что второй запрос может пойти по уже открытому соединению и вернуться заметно быстрее первого; некоторые браузеры устанавливают соединение заранее, еще до клика. Все это слегка занижает число. Медиана часть этого поглощает, но не все.

Доступность

Эта проверка наша; GreatFire ее не делает. По одному запросу HEAD в режиме no-cors к YouTube, X, Instagram, Facebook, ChatGPT, Telegram Web, Discord, GitHub, Wikipedia и Google с таймаутом 8 секунд; записывается, пришел ли ответ и сколько это заняло.

Она отвечает на простой вопрос: с этим инструментом эти сайты открываются прямо сейчас? Медиана задержки описывает общее качество маршрута; доступность говорит, до каких конкретных сайтов этот маршрут — или этот внешний IP — не дотягивается. Некоторые диапазоны хостингов Google или OpenAI блокируют полностью, и никакая скорость тут не поможет.

Из-за no-cors, опять же, мы можем сказать только «ответил», а не «ответил тем, чем нужно». Сайт, вернувший страницу блокировки с 403, считается доступным. Это ограничение браузера, а не наша небрежность.

Стабильность

Тест стабильности использует список изображений с известными размерами, [url, width, height]. Каждое загружается через new Image() с антикэширующей меткой времени и таймаутом 10 секунд; после загрузки naturalWidth и naturalHeight должны точно совпасть с ожидаемыми значениями. stability = passed / total × 100%.

Почему проверка размера ловит проблемы? Потому что большинство видов вмешательства меняют размер. Прозрачный прокси провайдера подменяет изображение картинкой «страница не может быть отображена» — другие размеры. Middlebox, встраивающий контент в ответ, — изображение не декодируется или выходит другого размера. Отравление DNS направляет домен на подставной IP, который либо не отвечает, либо возвращает что-то совсем другое. И наоборот: если изображение пришло целым и ожидаемого размера, этот путь с большой вероятностью чист.

Чего тест не измеряет — так это производительность. Изображение, которое ползло девять секунд, но имеет правильные размеры, все равно проходит. Стабильность и скорость — разные оси; 100% стабильности не означает «быстро».

Оценка качества видео

Дополнительных измерений здесь нет — avgVideo переводится в мегабиты в секунду (байты × 8 ÷ 10⁶) и сверяется с таблицей порогов:

Скорость	Оценка качества
< 0,7 Мбит/с	240p
< 1,5 Мбит/с	360p
< 2,5 Мбит/с	480p
< 5 Мбит/с	720p
< 8 Мбит/с	1080p
< 20 Мбит/с	1440p
≥ 20 Мбит/с	2160p

Пороги взяты из реализации GreatFire и оставлены без изменений, чтобы два сайта совпадали. Это грубый ориентир: реальные битрейты YouTube зависят от контента и кодека, а плеер непрерывно адаптируется. 3 Мбит/с в течение десяти секунд не гарантируют устойчивых 3 Мбит/с на сорокаминутном ролике. Читайте это как «примерно в какой уровень качества вы попадете».

Искажения, от которых браузерный тест не избавится

В конечном счете это тест внутри браузера, а не iperf. Несколько вещей, о которых стоит помнить.

Один поток загрузки ограничен контролем перегрузки TCP (или QUIC), и на пути с высокой задержкой и потерями он не заполнит канал — поэтому мы и добавили параллельный пик. У самого браузера есть накладные расходы, на телефонах заметные. Ваш Wi‑Fi, облачный диск, синхронизирующийся в фоне, кто-то еще на том же роутере смотрит видео — все это внутри числа. Один и тот же выходной узел в 21:00 может быть втрое медленнее, чем в 3 часа ночи.

И две вещи мы проверить не можем: выбранную вами локацию и введенное название инструмента. Приходится верить на слово. Именно поэтому рейтинг требует не менее пяти тестов за 48 часов и поэтому медианы важнее средних: единичный шум и честные ошибки размываются объемом и статистикой.

Если нужны строгие числа, инструменты командной строки (iperf3 или speedtest-cli напрямую до сервера) точнее. Но они не отражают того, что испытывает обычный человек, пользуясь браузером через туннель, — а именно об этом опыте этот сайт.

Вопросы и ответы

Почему другие сайты для теста скорости показывают мне число больше? Большинство из них автоматически выбирают ближайший сервер и открывают много параллельных потоков. Наша основная метрика — один поток до фиксированного сервера, так что она естественно ниже, зато сравнима между инструментами. Значение max будет ближе к тому, что показывают другие сайты.

Почему некоторые домены всегда проваливают тест задержки? Некоторые серверы медленно обрабатывают HEAD; некоторые соединения сбрасывает сеть, в которой вы находитесь. Неудачи в медиану не входят, но видны в детальном представлении и сами по себе информативны.

Что сохраняется из теста? Выбранная вами локация, введенные название и версия инструмента, результаты и детали четырех проверок, а также семейство вашего браузера и ОС. Если используется инструмент, мы записываем страну внешнего IP — никогда не сам IP.

Можно ли тестировать без инструмента? Да — выберите «Нет». Такие результаты в рейтинг не попадают, но формируют медиану «прямого соединения» для каждого региона, которая служит базовой линией.