Критический CSS: как собрать первый экран и не потерять градиенты

Критический CSS - это слепок правил первого экрана, который печатается прямо в HTML, а весь остальной файл стилей сайт подгружает не блокируя показ страницы. У нас на этом попался градиентный заголовок: автоматический сборщик слепка стёр правило с переменной цвета внутри, и текст на нём стал прозрачным. С тех пор мы знаем, где технология ломается и как собирать её без таких сюрпризов.

Браузер не рисует страницу, пока не получит и не разберёт файл стилей. Если это отдельный файл по ссылке в шапке, страница держит пустой экран до конца его загрузки. Отчёты о скорости называют это блокирующим ресурсом, и критический CSS - стандартный ответ на такую рекомендацию.

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

Что теряет сайт на обычной загрузке стилей

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

На быстром домашнем интернете разница едва заметна. На мобильной сети с высокой задержкой такой цикл стоит десятки и сотни миллисекунд. Про остальные способы ускорения мы разбирали в статье как ускорить сайт до 1,5 секунды - критический CSS решает конкретно задержку до первой отрисовки, а не общий вес страницы.

Как снять слепок правил первого экрана

Слепок - не весь файл стилей, а только те правила, которые реально применяются к тому, что видно без прокрутки. Чтобы их найти, страницу открывают headless-браузером, дожидаются отрисовки и через встроенный учёт покрытия смотрят, какие селекторы сработали.

Легко упустить тонкость: одна и та же вёрстка выглядит по-разному на мобильном и на десктопе, а сайт состоит не из одного шаблона, а из нескольких - главная, карточка товара, статья блога, страница услуги. Каждый шаблон снимают отдельно и на двух ширинах, иначе слепок подойдёт только той странице, с которой снят. На остальных шаблонах первый экран останется без части нужных стилей: расползутся отступы, поедет сетка блоков, а иногда элемент покажется голым HTML-тегом.

Почему нельзя брать правила из объектной модели браузера

Самая обидная ошибка - брать готовые правила из объектной модели страницы, а не из текста исходного файла. Кажется логичным: браузер уже разобрал CSS, остаётся выгрузить то, что получилось. На деле он пересобирает объявления по-своему и упрощает сокращённые свойства, а переменные внутри них раскрывать не обязан.

У нас так пострадал заголовок с градиентной заливкой текста. В исходном файле было свойство background с градиентом и переменной цвета внутри. Объектная модель вернула его пустым: background-image превратился в ничего. Цвет самого текста для эффекта градиента специально сделан прозрачным, поэтому слова буквально исчезли с экрана. Без сравнения с исходником было непонятно, что случилось.

Тот же способ теряет и вендорные префиксы: браузер их не показывает, а старым устройствам они всё ещё нужны. Правильный путь - разбирать сам файл style.css как текст и переносить нужные селекторы дословно, со всеми переменными и префиксами как есть.

Комментарий, который увёл медиазапрос в один блок

Вторая грабля ждёт в собственном парсере, который читает файл текстом. Комментарии не мешают браузеру, но мешают разборщику, если тот ищет начало медиазапроса простым сравнением строки. У нас перед одним из медиазапросов стоял комментарий-баннер вида /* ==== MOBILE ==== */, и код, проверявший, начинается ли строка с @media, об эту строку спотыкался. Весь блок мобильных стилей уезжал в разбор как одно нечитаемое правило, и мобильная часть слепка выпадала целиком.

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

Как подключить остальной CSS, не блокируя показ

Готовый слепок печатают прямо в HTML внутри тега style в шапке - без отдельного запроса. Основной файл стилей подключают так, чтобы он не блокировал отрисовку: ссылке ставят атрибут media="print", а по завершении загрузки атрибут скриптом меняют обратно на all. Для браузеров с отключённым JavaScript этот приём не сработает, поэтому рядом добавляют обычную ссылку внутри тега noscript - она подключается сразу, блокирующим способом, но только там, где скриптов и так нет.

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

Когда пересобирать слепок и почему про это забывают

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

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

Когда критический CSS не нужен вовсе

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

Проверить свою ситуацию несложно: посмотреть вес style.css после сжатия и долю новых посетителей в аналитике. Если файл лёгкий, а аудитория возвращается снова, эффект от критического CSS окажется ниже цены его поддержки.

Чек-лист перед внедрением

Прежде чем включать критический CSS в проект, стоит пройти по короткому списку:

• Проверить вес style.css после сжатия - если он меньше 20-30 килобайт, эффект может не окупить сложность.
• Определить все типы шаблонов сайта и снять слепок на каждом, а не только на главной.
• Снять слепок на двух ширинах экрана - мобильной и десктопной.
• Собирать правила из текста исходного CSS-файла, а не из объектной модели браузера, особенно если в стилях есть градиенты и переменные.
• Вырезать комментарии из текста файла до поиска медиазапросов и селекторов.
• Предусмотреть откат на обычные блокирующие стили, если файла со слепком не оказалось.
• Добавить noscript-ссылку на полный файл стилей для браузеров без JavaScript.
• Включить пересборку слепка в чек-лист выкладки любой заметной правки style.css.

Заодно можно свериться с остальной технической частью: адаптивность на нужных ширинах есть в статье про адаптивную вёрстку, а полный порядок проверки скорости и индексации - в материале про технический SEO-аудит.

Итог для тех, кто решает, внедрять ли критический CSS

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

Если на сайте уже настроены свои шрифты и сжатие изображений, а первый экран всё равно показывается медленно, дело, вероятно, в блокирующем CSS - это легко проверить по отчёту Core Web Vitals конкретной страницы. Похожая логика неблокирующей загрузки работает и для шрифтов - мы писали об этом в статье про шрифты для сайта. Вместе эти две правки дают заметный, а не косметический эффект на мобильной скорости.