Critical CSS

Как работает

Стили делят на две части. Критические — те, что оформляют видимую без прокрутки часть страницы, первый экран, — встраиваются прямо в <head> внутри тега <style>. Остальной CSS грузится отдельным файлом асинхронно, чтобы не блокировать отрисовку.

<head>
  <style>
    /* критические стили первого экрана — инлайн */
    header{...}.hero{...}h1{...}
  </style>
  <!-- остальные стили грузятся асинхронно -->
  <link rel="preload" href="/style.css" as="style" onload="this.rel='stylesheet'">
</head>

Браузер отрисовывает первый экран сразу по инлайн-стилям, а полный файл догружается в фоне и применяется к остальной странице. Критический CSS обычно извлекают автоматически инструментами вроде Critical или Penthouse на этапе сборки — вручную поддерживать его тяжело.

У приёма есть предел разумного объёма: инлайн-стили не кэшируются отдельно и едут заново с каждой загрузкой HTML, поэтому в <style> держат только правила первого экрана — обычно до нескольких килобайт. Всё, что ниже линии сгиба, оставляют во внешнем файле: он закэшируется и на следующих страницах подтянется мгновенно. Баланс между быстрым первым экраном и кэшированием и есть главная настройка приёма.

Почему важно для SEO

Внешний файл стилей по умолчанию блокирует отрисовку — это подробно разобрано в карточке render-blocking. Critical CSS снимает эту блокировку для первого экрана: стили нужной части уже в HTML, браузеру не нужно ждать сетевой запрос. За счёт этого раньше наступает FCP — первая отрисовка контента, — а это одна из метрик, влияющих на оценку скорости страницы.

Эффект заметнее всего на мобильных с медленной сетью, где каждый лишний запрос к CSS-файлу стоит сотен миллисекунд. Приём не пересекается с минификацией: минификация уменьшает вес файла, а критический CSS меняет способ доставки стилей. Их применяют вместе. Робот при рендеринге тоже быстрее получает оформленную страницу, хотя на само содержимое это не влияет.

Главная сложность приёма — поддержка. Критический набор стилей привязан к конкретному шаблону, и после каждой заметной правки дизайна его нужно извлекать заново, иначе первый экран отрисуется по устаревшим правилам и «поедет». Поэтому извлечение встраивают в сборку, а не делают руками. На сайтах с разными типами страниц — главная, категория, карточка — критический CSS собирают отдельно под каждый шаблон, потому что первый экран у них устроен по-разному.

Частые ошибки

• В инлайн попадает весь CSS сайта — HTML раздувается, выигрыш теряется.
• Критический CSS выделен один раз и не обновляется после редизайна — первый экран ломается.
• Основной файл стилей грузится синхронно, и блокировка отрисовки остаётся.
• В критические стили не включили шрифты первого экрана — текст прыгает при догрузке.
• Инлайн-стили дублируют правила из основного файла, увеличивая суммарный вес.

Как проверить

В PageSpeed Insights и Lighthouse пункт про блокирующий рендеринг CSS подскажет, вынесены ли критические стили. В DevTools → Coverage видно, какая доля загруженного CSS реально используется на первом экране — большой неиспользуемый остаток намекает, что стили стоит разделить. В Performance проверяют момент первой отрисовки.

SEO Crawler при обходе замеряет скорость первой отрисовки и вес подключённого CSS, помогая найти страницы, где тяжёлый блокирующий файл стилей откладывает появление контента. Это отправная точка, чтобы решить, где внедрять критический CSS.

Вывод

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