Почему 5G показывает 1 Гбит/с, а сайты всё равно открываются медленно

На экране горит 5G, Speedtest показывает сотни мегабит или почти гигабит, а после тапа по ссылке страница ещё секунду-другую думает. На первый взгляд это выглядит странно: если канал такой быстрый, почему небольшой сайт не появляется мгновенно?

Потому что Мбит/с и миллисекунды отвечают на разные вопросы. Высокая скорость показывает, сколько данных соединение способно передать за секунду, а открытие сайта складывается из нескольких этапов: DNS, сетевого маршрута, соединения с сервером, TLS, ожидания первого байта, загрузки ресурсов и работы браузера. Иногда сами данные скачиваются быстро, но сотни миллисекунд уже потеряны до начала передачи.

Гигабит в Speedtest не означает, что сайт должен открываться за миллисекунды

1 Гбит/с в Speedtest не означает мгновенную загрузку любого сайта. Мбит/с показывают пропускную способность канала, а миллисекунды — задержку между отдельными действиями: запросом, ответом, установлением соединения. Для веб-страницы важны обе величины.

Хорошо видно это на двух совершенно разных задачах. Большой файл после установления соединения действительно выигрывает от широкой полосы: чем выше пропускная способность, тем быстрее прилетят сотни мегабайт. У небольшой веб-страницы всё иначе. До того как браузер начнёт получать полезные данные, он успевает выполнить несколько сетевых операций, и каждая может добавить десятки миллисекунд.

Представим страницу размером около 1 МБ. При канале порядка 1 Гбит/с сама передача такого объёма занимает совсем немного времени. Но если DNS, соединение, TLS и ожидание ответа по очереди добавляют условные 30–100 мс, пользователь заметит паузу ещё до того, как скорость скачивания станет главным фактором.

Поэтому хороший Speedtest не доказывает, что «с интернетом точно всё идеально». Стоит смотреть как минимум на Download и Latency/Ping, а затем сравнить несколько сайтов. Полоса может быть широкой, но RTT — время прохождения запроса туда и ответа обратно — никуда не исчезает.

Что происходит после тапа по ссылке — ещё до загрузки самой страницы

После тапа браузер начинает работу раньше, чем на экране появляется хоть что-то новое. Упрощённо путь выглядит так:

1. Браузер выясняет IP-адрес сайта через DNS, если нужного ответа нет в кеше.
2. Устанавливает соединение с сервером.
3. Для HTTPS создаёт защищённую TLS-сессию.
4. Отправляет HTTP-запрос.
5. Ждёт, пока сервер начнёт отвечать.
6. Получает HTML.
7. Находит в нём CSS, JavaScript, изображения, шрифты и другие ресурсы.
8. Догружает их и собирает страницу на экране.

Фраза «сайт грузится две секунды» сама по себе почти ничего не объясняет. Эти две секунды могли уйти на ожидание первого байта, на десятки сторонних запросов или уже на выполнение JavaScript. Для пользователя это одна пауза, для диагностики — несколько совершенно разных мест, где можно потерять время.

Поэтому первый заход нередко тормозит, а второй внезапно оказывается быстрее. DNS уже может быть в кеше, часть файлов хранится локально, а соединение иногда удаётся использовать повторно. Первый заход в этом смысле дороже.

На ПК это хорошо видно в Chrome DevTools во вкладке Network. Waterfall показывает временную шкалу запросов и позволяет понять, где возникла длинная пауза: до соединения, во время ожидания ответа или уже при загрузке ресурсов.

DNS и расстояние до сервера: где появляются первые задержки

Медленный DNS или длинный маршрут могут задержать открытие сайта ещё до передачи его содержимого. Если IP-адрес домена не закеширован, смартфону сначала нужно получить его через DNS, а затем отправить запрос по сети оператора к нужному серверу.

После DNS пакет проходит маршрут смартфон → сеть оператора → магистральные сети → дата-центр → сервер, а ответ идёт обратно. Радиоканал от телефона до базовой станции — только первый участок этого пути. Значок 5G ничего не говорит о том, насколько коротко и удачно оператор маршрутизирует трафик до конкретного сайта.

География имеет значение, но формула «ближе — всегда быстрее» слишком грубая. Сервер в соседней стране может отвечать быстрее более близкого, если у него удачнее связность или используется CDN. И наоборот, неудачный маршрут способен добавить задержку даже при небольшом расстоянии по карте.

Для первой проверки достаточно открыть один и тот же сайт через мобильную сеть и Wi-Fi. Если по Wi-Fi он стабильно начинает отвечать заметно быстрее, стоит смотреть на мобильный маршрут, DNS, VPN или Private DNS. Если разницы почти нет, круг подозреваемых смещается ближе к самому сайту.

TCP, TLS и TTFB: почему данные ещё не идут, хотя интернет уже работает

Если браузер долго ждёт первый байт ответа, а затем страница передаётся почти мгновенно, высокая скорость 5G мало помогает. Задержка возникает до этапа собственно скачивания данных.

Для нового соединения браузеру нужно установить связь с сервером, а для HTTPS — ещё и создать защищённую TLS-сессию. Современные протоколы сокращают часть накладных расходов, а HTTP/3 в некоторых сетевых условиях делает соединение устойчивее, но никакой протокол не заставит медленный backend сформировать страницу быстрее.

Ключевая метрика здесь — TTFB, Time to First Byte, время от отправки HTTP-запроса до прихода первого байта ответа. В типичном waterfall DNS, Connect и SSL/TLS показываются отдельно, а Waiting/TTFB включает сетевой путь запроса и ответа плюс серверную обработку. Это важное различие: высокий TTFB сам по себе ещё не говорит, что виноват именно CPU или база данных.

Картина знакомая: после тапа полсекунды почти ничего не происходит, а затем страница появляется разом. Допустим, Content Download занимает 40 мс, а Waiting/TTFB — 900 мс. Переход с 300 Мбит/с на 1 Гбит/с почти ничего не изменит в ощущениях. Канал уже не узкое место: до скачивания браузер почти секунду просто ждёт.

Полезно смотреть на всю цепочку целиком: DNS → Connect/TLS → отправка запроса → Waiting/TTFB → Content Download → выполнение JavaScript. Длинный участок waterfall и есть подсказка, куда двигаться дальше. Если долго до первого байта — проверяем маршрут и серверную сторону. Если HTML приходит быстро, а потом тянется хвост запросов — проблема уже ближе к frontend.

Сервер получил запрос быстро, но сам сайт готовит ответ слишком долго

Если большинство сайтов на том же смартфоне открываются быстро, а один стабильно отвечает медленно и через 5G, и через Wi-Fi, проблема с высокой вероятностью находится ближе к конкретному сайту. Такой тест не ставит точный диагноз, но резко сужает поиск.

Динамическая страница не всегда лежит на диске в полностью готовом виде. Сервер может запустить PHP или другое приложение, обратиться к базе данных, проверить кеш, дождаться внешнего API и только потом сформировать HTML. Запрос до сервера дошёл. Теперь вопрос в том, сколько времени серверу нужно, чтобы было что отправлять обратно.

На время ответа влияют загрузка CPU, доступная RAM, активный swap, скорость дисковой подсистемы, запросы к базе, кеширование и конкуренция за ресурсы. Если Speedtest показывает сотни мегабит, а TTFB конкретного сайта остаётся высоким на разных подключениях, имеет смысл смотреть не только на сеть, но и на то, работает ли проект в перегруженном общем окружении или использует сервер с выделенными ресурсами. Это не универсальное лекарство от высокого TTFB, а один из факторов, который помогает убрать конкуренцию за вычислительные ресурсы из списка подозреваемых.

Показательный симптом — несколько страниц одного сайта начинают отвечать одинаково медленно, тогда как другие ресурсы в тот же момент открываются нормально. Если картина повторяется через разные сети, проверять стоит приложение, базу данных, кеш и серверную инфраструктуру, а не только уровень сигнала 5G.

Почему страница размером всего 1 МБ тоже может загружаться медленно

Небольшой вес страницы не гарантирует быструю загрузку. Десятки сетевых запросов, JavaScript и сторонние сервисы могут занять больше времени, чем скачивание самого HTML.

Один файл размером 1 МБ и страница общим весом 1 МБ — не одно и то же. Во втором случае этот мегабайт может быть разбит на сотню отдельных ресурсов: CSS, скрипты, иконки, шрифты, изображения, рекламу, аналитику и виджеты. Часть запросов уходит на другие домены, а значит, там снова могут появиться DNS, соединение и TLS.

Дополнительная проблема — JavaScript. Файл может приехать быстро, но смартфону ещё нужно его разобрать и выполнить. Пока тяжёлый скрипт занят работой, страница уже загружена по сети, но визуально продолжает «собираться». Поэтому ситуация «HTML пришёл быстро, а блоки ещё несколько секунд появляются один за другим» чаще говорит не о нехватке Мбит/с, а о frontend-части.

В DevTools такая страница часто выглядит не как один большой файл, а как длинный «гребень» из мелких запросов. Смотреть стоит не только на общий объём данных, но и на количество запросов, длительные соединения со сторонними доменами и ресурсы, которые завершаются позже остальных. Если HTML уже получен, а экран продолжает перестраиваться, искать проблему нужно после этапа получения основного ответа.

Почему один сайт по 5G может открываться медленнее другого сайта по обычному 4G

5G ускоряет только один участок пути, а не весь интернет целиком. Поэтому сайт A на 4G вполне может визуально открыться быстрее сайта B на 5G, даже если пропускная способность второго подключения в несколько раз выше.

Условный сайт A может иметь закешированный DNS, близкий CDN, низкий TTFB, мало ресурсов и почти никаких сторонних сервисов. Условный сайт B — новый DNS lookup, более длинный маршрут, высокий TTFB, сотню запросов, тяжёлый JavaScript и рекламу с нескольких доменов. В такой паре сравнение «4G против 5G» почти ничего не говорит о реальной причине.

Именно здесь легко попасть в ловушку: сравнить 4G и 5G по двум совершенно разным сайтам. Корректнее проверять один и тот же ресурс примерно в одинаковых условиях. У разных страниц разные серверы, маршруты, кеширование, наборы скриптов и сторонних сервисов.

Для первой проверки никакие программы не нужны: откройте несколько сайтов через мобильную сеть, а затем те же страницы через Wi-Fi. Уже по этому сравнению часто видно, искать проблему у оператора или ближе к конкретному сайту.

Как за несколько минут понять, кто тормозит: смартфон, оператор или конкретный сайт

Самый простой способ отделить проблему сети от проблемы сайта — сравнить несколько ресурсов и повторить тест через другое подключение. Метод не даст точную строку в логе, зато быстро покажет, в какую сторону копать.

Симптом	Что проверить в первую очередь
Speedtest быстрый, но медленными кажутся почти все сайты	Задержку мобильной сети, DNS, VPN, Private DNS, состояние телефона и маршрут оператора
Большинство сайтов быстрые, один стабильно медленный	Маршрут к конкретному сайту, TTFB, backend и frontend этого ресурса
Первая загрузка долгая, повторная заметно быстрее	DNS-кеш, HTTP-кеш, повторное использование соединения и TLS
Долго пусто, затем страница появляется почти сразу	Waiting/TTFB, маршрут и серверную обработку
HTML приходит быстро, но блоки ещё долго догружаются	JavaScript, изображения, рекламу, шрифты и сторонние запросы
Через Wi-Fi быстро, через 5G заметно медленнее	Мобильный маршрут, DNS, VPN/Private DNS и качество соединения
Через Wi-Fi и мобильную сеть один сайт одинаково медленный	Серверную сторону и frontend конкретного сайта

Проверять лучше от простого к сложному. Не начинайте с TTFB и DevTools. Сначала выясните, тормозит один сайт или почти все. Затем смените 5G на Wi-Fi. После этого сравните первый и повторный заход на ту же страницу. Часто уже этих трёх шагов хватает, чтобы локализовать проблему.

1. Откройте несколько разных сайтов на одном подключении.
2. Повторите проверку через Wi-Fi вместо 5G или наоборот.
3. Сравните первую и повторную загрузку одной страницы.
4. Если медленным остаётся один сайт, посмотрите Waiting/TTFB.
5. Если HTML приходит быстро, а страница продолжает собираться, переходите к JavaScript и другим ресурсам frontend.

Если нужен следующий уровень, откройте сайт на ПК и посмотрите Network в DevTools. Большой Waiting/TTFB при коротком Content Download указывает на задержку до первого байта. Быстрый HTML при длинном хвосте запросов чаще ведёт к JavaScript, изображениям и сторонним сервисам.

Один симптом диагноз не ставит. Высокий TTFB ещё не доказывает проблему с CPU, а быстрый Speedtest не гарантирует идеальный маршрут. Сначала локализуем слой — сеть, путь до сервера, серверный ответ или сборка страницы в браузере. После этого искать конкретную причину намного проще.

5G действительно убирает одно из возможных узких мест — нехватку пропускной способности мобильного канала. Но между тапом по ссылке и появлением страницы всё равно остаются DNS, маршрут, соединение, TLS, серверная обработка и работа браузера.

Поэтому правильный вопрос звучит не «почему у меня почти 1 Гбит/с, а сайт медленный», а «на каком именно этапе исчезает время». Как только разделить путь на эти этапы, противоречие между быстрым 5G и медленной страницей исчезает.