Как читать вкладку network в браузере при медленной загрузке страницы

Вкладка Network помогает увидеть, какие запросы браузер отправляет при загрузке страницы, сколько они занимают и на каком этапе возникает задержка. Чтобы понять, как пользоваться вкладкой Network в Chrome, сравните несколько одинаковых замеров, изучите диаграмму Waterfall и отделяйте наблюдаемые времена от предположений о причине. Так анализ скорости загрузки сайта становится практической основой для проверки гипотез.

Ориентиры для чтения сетевого следа

• Замеряйте одну и ту же страницу при сопоставимых условиях: состояние кэша и сеть влияют на результат.
• Начните с запросов, связанных с отображением основного содержимого, а не только с самых крупных файлов.
• Смотрите на этапы запроса: DNS, подключение, TLS, ожидание ответа и передача данных.
• Большое время ожидания может указывать на задержку до получения ответа, но само по себе не доказывает проблему сервера.
• Перед передачей записи другому человеку проверьте, не попали ли в неё cookies, токены или персональные данные.

Подготовьте замер: чистый профиль, кэш и условия сети

Этот способ подходит разработчикам, тестировщикам и владельцам сайтов, которым нужно локализовать задержку в браузере. Не используйте личную авторизованную сессию для публичной демонстрации сетевых данных и не делайте вывод по одному нестабильному замеру.

Откройте страницу в Chrome, вызовите инструменты разработчика клавишей F12 или через меню браузера и выберите вкладку Network. Для сравнения используйте одинаковые условия: тот же URL, устройство и профиль сети. При необходимости проверьте страницу в отдельном чистом профиле Chrome, где меньше влияния расширений.

Сначала решите, что именно измеряете. Для загрузки с кэшем оставьте его включённым; для проверки загрузки без кэша установите флажок Disable cache в Network и держите DevTools открытыми. Это настройка только на время открытых инструментов разработчика, но результаты такого режима нельзя напрямую приравнивать к обычному повторному посещению.

Найдите запрос, который задерживает показ страницы

Понадобятся актуальный браузер с DevTools, доступ к исследуемой странице и возможность перезагрузить её. Установка дополнительных программ для первичной диагностики не обязательна. Вкладка Network - один из инструментов для проверки скорости сайта; для оценки общей производительности её вывод полезно сопоставлять с другими методами измерения.

Включите запись запросов, перезагрузите страницу и дождитесь завершения основной загрузки. В таблице изучите столбцы Name, Status, Type, Initiator, Size и Time, а на диаграмме Waterfall - последовательность и длительность запросов. Фильтры по типам ресурсов помогают отдельно проверить документы, скрипты, стили, изображения и шрифты.

Не выбирайте запрос только потому, что он дольше всех выполнялся. Сначала проверьте, блокирует ли он отображение важного содержимого, запускает ли последующие запросы и не загружался ли он параллельно с другими ресурсами.

Сопоставьте DNS, подключение, TLS и ожидание ответа

Перед разбором учитывайте ограничения измерения:

• Значения зависят от сети, сервера, кэша, расширений и текущей нагрузки.
• Принудительное отключение кэша меняет сценарий загрузки и может увеличить число сетевых запросов.
• Длинный этап не всегда указывает на неисправность именно того компонента, с которым он связан.
• Экспорт сетевого журнала может содержать конфиденциальные заголовки и адреса запросов.

1. Выберите запрос для анализа. В первую очередь проверьте основной документ и ресурсы, от которых зависит появление видимой части страницы. Откройте запрос и найдите вкладку Timing.
2. Проверьте DNS. Этап Queueing или Stalled может отражать ожидание перед отправкой, а DNS Lookup - разрешение доменного имени. Если DNS-этапа нет, браузер мог использовать уже имеющееся соединение или кэшированное разрешение.
3. Сопоставьте подключение и TLS. Изучите Initial connection и SSL, если они показаны. Наличие длительного этапа - наблюдение; причина может зависеть от сети, повторного использования соединения и других условий.
4. Оцените ожидание ответа. Waiting for server response (TTFB) показывает время до получения первого байта ответа после отправки запроса. Это не измерение только серверной обработки: на него также могут влиять сеть и промежуточные узлы.
5. Проверьте передачу данных. Сопоставьте Content Download с размером ответа и общей длительностью. Если этап передачи заметен, проверьте объём ресурса и условия сети, не делая вывод по одному запросу.

Этап или признак	Что показывает	Что проверить
DNS Lookup	Разрешение доменного имени, если этот этап выполнялся отдельно	Повторяется ли задержка в сопоставимых замерах
Initial connection	Установление сетевого соединения	Зависит ли результат от нового соединения или повторного использования
SSL	Установка защищённого соединения TLS	На каких запросах и при каких условиях этап появляется
Waiting for server response (TTFB)	Время ожидания первого байта ответа	Повторяется ли задержка и затрагивает ли она основной документ
Content Download	Передача тела ответа	Размер ресурса и влияние пропускной способности сети

Различайте долгий ответ сервера и медленную передачу данных

Используйте этот чек-лист после первого просмотра Waterfall:

• Повторите загрузку в тех же условиях и проверьте, воспроизводится ли задержка.
• Отметьте, задержан ли основной документ или отдельный второстепенный ресурс.
• Сравните Waiting for server response и Content Download в Timing.
• Проверьте размер ответа и тип ресурса; большой файл сам по себе не доказывает, что именно он задерживает показ.
• Посмотрите, не ожидал ли запрос завершения другого ресурса или свободного соединения.
• Проверьте столбец Initiator, чтобы понять, какой ресурс или скрипт запустил запрос.
• Сравните результаты при включённом и отключённом кэше, не смешивая эти сценарии.
• Запишите наблюдаемые этапы и отдельно сформулируйте гипотезу о причине.

Если долго именно ожидание первого байта, проверьте повторяемость и другие запросы к тому же источнику. Если заметна передача, сопоставьте её длительность с объёмом ответа и условиями сети. Эти признаки помогают выбрать направление проверки, но окончательно причину устанавливают дополнительными замерами и анализом серверной стороны.

Сравните запросы по типу ресурса, приоритету и объёму

При разборе часто мешают ошибки интерпретации:

• Считать самый долгий запрос главным препятствием для отображения страницы, не проверив его роль.
• Сравнивать замер с кэшем и замер без кэша как один и тот же сценарий.
• Принимать общий столбец Time за длительность одного конкретного этапа.
• Считать TTFB точным временем работы приложения на сервере.
• Сопоставлять разные страницы, устройства или условия сети без оговорок.
• Игнорировать приоритет ресурса и порядок зависимостей между запросами.
• Делать вывод по размеру без проверки того, когда ресурс нужен для отображения.
• Объявлять причиной расширение или сервер без контрольного замера в другом профиле либо сценарии.

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

Проверьте гипотезу повторным замером и не раскройте чувствительные данные

Выберите подходящий следующий шаг:

• Повтор в том же профиле. Уместен, чтобы проверить воспроизводимость при неизменных условиях и отличить устойчивый признак от случайного скачка.
• Замер в чистом профиле. Помогает проверить влияние расширений и локальных настроек браузера; результаты сравнивайте с исходным профилем.
• Сравнение с другими средствами. Если нужен более широкий анализ скорости загрузки сайта, дополните DevTools инструментами для проверки скорости сайта и проверкой реального поведения страницы. Учитывайте, что условия внешнего теста могут отличаться от пользовательских.
• Передача журнала специалисту. Сначала проверьте экспорт: удалите или замаскируйте cookies, токены, персональные данные и чувствительные параметры URL. Не публикуйте HAR-файл без проверки его содержимого.

Сформулируйте результат как наблюдение и проверяемую гипотезу, например: "в нескольких замерах запрос основного документа долго ожидает первый байт". Так проще определить следующий шаг и не выдавать предположение за установленную причину, когда задача - понять, как ускорить загрузку сайта.

Что проверить, прежде чем делать выводы по вкладке Network

Почему при повторной загрузке страница быстрее?

Браузер может использовать кэш и уже установленные соединения. Сравните повторную загрузку с отдельным замером при отключённом кэше, не смешивая эти сценарии.

Что означает высокий TTFB?

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

Нужно ли всегда включать Disable cache?

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

Как понять, что запрос задерживает показ страницы?

Проверьте его тип, Initiator, порядок в Waterfall и зависимость от него видимого содержимого. Большая длительность сама по себе не подтверждает влияние на отображение.

Можно ли безопасно отправить HAR-файл?

Только после проверки и удаления чувствительных данных. В HAR могут присутствовать заголовки, cookies, параметры URL и сведения о запросах.

Почему замер в DevTools отличается от другого теста?

Инструменты могут использовать разные устройства, сети, кэш, местоположение и сценарии загрузки. Сравнивайте результаты с учётом этих условий.

Автор: Андрей Федотов.