Почему критический путь рендеринга вообще важен
Если упростить до предела, критический путь рендеринга — это цепочка действий браузера от момента, когда пользователь жмёт на ссылку, до момента, когда он реально видит «живую» страницу. Чем короче и чище этот путь, тем быстрее сайт кажется «живым» и полезным.
Крутой дизайн, навороченный бэкенд и модный фреймворк не спасут, если страница открывается 4–6 секунд. Пользователь просто уходит.
По данным HTTP Archive и отчётов Web Almanac (2021–2023 годы):
— медианный Time to First Byte (TTFB) на десктопе держится в районе 0,3–0,4 секунды;
— медианный Largest Contentful Paint (LCP) для мобильных сайтов в 2021–2023 годах топчется около 3,5–4 секунд — то есть большинство сайтов всё ещё не укладываются в рекомендуемые 2,5 секунды;
— доля сайтов, которые проходят Core Web Vitals по всем метрикам, выросла с ~25–30% в 2021 до примерно 40–45% в 2023 году.
У меня нет доступа к полноценной статистике за 2024–2025 годы, но тренд понятен: требования ужесточаются, пользователи привыкают к скорости, поисковые системы учитывают метрики. Поэтому оптимизация производительности веб страниц — это уже не «приятный бонус», а вопрос выживаемости.
Критический путь рендеринга по шагам, но по‑человечески
Что делает браузер после клика
Давайте разложим процесс без академического занудства, но по сути:
1. DNS‑резолвинг и соединение
Браузер выясняет IP сервера, устанавливает TCP‑ и TLS‑соединение. Уже здесь можно проиграть секунду‑другую на медленном хостинге или без HTTP/2/3.
2. Загрузка HTML
Как только начинает приходить HTML, браузер строит DOM‑дерево. Но рендеринг по‑настоящему стартует только когда становится ясно, какие стили и шрифты применить.
3. Загрузка и обработка CSS
CSS блокирует рендеринг: пока не загружены критические стили, браузер не рисует страницу, чтобы не мигать макетом. Каждый лишний CSS‑файл на старте — это задержка.
4. Загрузка и выполнение JS
Синхронные `