Анализ размеров и времени загрузки ресурсов

t

Фундаментальные различия между номинальным и фактическим размером ресурса

При анализе загрузки ресурсов критически важно различать размер файла на диске сервера и объем данных, передаваемых по сети после применения сжатия и кодирования. Например, фрагмент CSS объемом 120 КБ после сжатия Brotli 11 уровня может весить всего 18–22 КБ. Однако размер в кэше браузера после декомпрессии вернется к исходным значениям.

Инструменты вкладки Network в DevTools отображают три столбца: размер (за вычетом заголовков), объем переданных данных и время до ответа. Непонимание разницы между этими метриками приводит к ошибочным выводам — например, к попытке уменьшить и без того оптимальный по протоколу манифест.

Для точного аудита необходимо также учитывать фрагментацию ресурсов при HTTP/2 мультиплексировании: несколько мелких файлов могут загружаться одновременно, но при этом каждый несет служебные заголовки, что в сумме увеличивает накладные расходы на 3–7%.

Влияние протокольных накладных расходов на время загрузки

Время загрузки ресурса складывается из трех составляющих: установка соединения (TCP + TLS handshake), время до первого байта (TTFB) и скорость передачи полезных данных. Для сайтов на HTTP/1.1 добавляется ограничение на 6–8 одновременных соединений на домен, что создает блокировки в очереди (queueing).

Анализ waterfall-диаграммы показывает, что для шрифтов .woff2 размером 35 КБ время TTFB может составлять 60–70% от общей загрузки, если сервер генерирует ответ с задержкой из-за сложной бизнес-логики на бэкенде. Сама передача данных в этом случае занимает менее 15% времени.

Использование CDN с предварительным прогревом кэша снижает TTFB до 20–50 мс, но только для ресурсов, у которых версии совпадают с теми, что уже запрошены. При обновлении файла (например, style.css?v=2) прогретый кэш не срабатывает, и задержка возвращается к исходным значениям.

Метрики критического пути рендеринга и их связь с размером

Практический анализ waterfall-диаграммы: выявление аномалий

Профессиональный анализ включает проверку последовательности загрузки. Нормальная цепочка: сначала HTML, затем внешние таблицы стилей (в порядке их объявления в документе), шрифты и критический JS, затем изображения и аналитика. Если DevTools показывает, что изображение загружается раньше стилей, это сигнал о неправильном размещении ресурсов в DOM (например, картинка в

без lazy-loading).

Типичная проблема — загрузка всех скриптов без атрибутов async/defer, что блокирует парсинг HTML. Анализ размера таких скриптов показывает, что 30–40% их объема приходится на библиотеки, которые не используются на странице (например, jQuery на сайте с React). Решение — код-сплиттинг и отложенная загрузка только тех модулей, которые нужны для текущего роута.

Для изображений узким местом становится не столько размер, сколько количество пикселей и глубина цвета. Изображение 1200x800 px в JPEG (85% качества) весит около 400 КБ, но 80% пользователей видят его в размере 400x267 px и ниже. Анализ потери данных показывает, что ресайз до 600x400 px с последующей перекомпрессией WebP дает файл 60–80 КБ без потери визуального качества.

Пример точной настройки: файл main.bundle.js весом 480 КБ после сжатия Brotli (11 уровень) — 134 КБ. DevTools показывает, что время его загрузки — 450 мс на сети 3G Fast (предустановленный профиль). Однако время выполнения (Evaluation) — 1.2 с, что создает длинную задачу (>50 мс) и ухудшает TBT. Вывод: проблема не в загрузке, а в объеме вычислений — требуется рефакторинг.

Критерии оценки качества сжатия и их влияние на метрики

  • Уровень сжатия Brotli — для статики на сервере рекомендуется уровень 11, так как это дает на 17–25% больший коэффициент сжатия по сравнению с gzip (уровень 9). На динамических данных (API) наценка за распаковку (20–50 мс на 100 КБ) может превышать выгоду от уменьшения размера.
  • Оптимизация заголовков ответов — заголовки Cache-Control и ETag могут добавлять до 500 байт на запрос. Многократные запросы (300+ ресурсов) накапливают до 150 КБ служебных данных, что эквивалентно загрузке небольшого скрипта.
  • Фрагментация кэша — при использовании CDN с разными способами хеширования (query string vs URL-based) одна и та же версия файла может быть загружена повторно, если сервер не выставил корректный Vary-заголовок. Анализ размера дублирующихся загрузок показывает потери 40–60 КБ на ресурс.
  • Метрика Save-Data (клиентский хедр) — устройства с включенным режимом экономии трафика автоматически просят сервер отдать ресурсы в минимальном размере. Анализ логов сервера показывает, что 12–15% запросов от мобильных пользователей содержат данный хедр, но большинство серверов игнорируют его, отдавая полные версии изображений.

Методика профайлинга с помощью Chrome DevTools: кастомные сценарии

Стандартный анализ включает запуск профиля «Network» и «Performance» на эмуляции устройства (например, Moto G4 с 3G Slow). Однако глубинная оценка требует создания кастомного сценария: загрузить страницу, затем очистить кэш через DevTools (Disable cache), записать два последовательных профиля — холодный и горячий старт. Разница между ними показывает эффективность HTTP-кэширования и Service Worker.

В текущей версии Chrome 2026 года вкладка «Network» отображает граф «Bytes over time», который визуализирует пропускную способность. Анализ ровной линии без пиков указывает на проблемы с буферизацией на стороне сервера (например, отсутствие chunked transfer encoding на AJAX-запросах). Для диагностики также используется фильтр «Blocked»: если ресурс находится в состоянии stalled более 50 мс, проверяются приоритеты request ordering (для HTTP/2 используется настройка stream priority).

Экспертный прием — оценка размера критического ресурса после Tree Shaking. Иногда DevTools показывает файл размером 120 КБ, но после разбора зависимостей (через вкладку Coverage) выясняется, что используется только 23% кода. Оставшиеся 77% — это мертвый код, увеличивающий время парсинга. Для его устранения требуется реструктуризация Webpack/Rollup конфигурации, а не простая оптимизация сжатия.

Добавлено: 23.04.2026