Как выделить критический CSS?

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

Как браузер обрабатывает критический CSS?

Critters анализирует HTML вашей страницы и генерирует критический CSS для области видимости. Этот CSS инлайнится в style-теги прямо в head. Остальные stylesheet-файлы загружаются асинхронно через link rel preload и noscript fallback. Браузер получает критический CSS первым — рендеринг начинается сразу. Асинхронная загрузка остальных стилей не блокирует отрисовку содержимого.

Как проверить улучшение в Lighthouse?

Откройте Google Lighthouse, запустите проверку вашего сайта. Web Vitals покажет, насколько улучшился LCP. В примере: был 4,2 сек, стал 1,8 сек после внедрения critical CSS. PageSpeed Insights подтвердит рост рейтинга. На практике это дает 30–60% улучшение LCP благодаря inline CSS в head и асинхронной загрузке файлов стилей для SEO.

Критический css

Почему браузер медленнее загружает сайт? Когда вы открываете страницу, браузер не может начать рисовать контент, пока не скачает и не применит CSS. Это называется блокировка рендеринга — один из главных убийц скорости загрузки CSS на мобильных устройствах и медленных сетях.

Вот механика. Браузер загружает HTML, парсит его, затем находит <link rel="stylesheet" href="styles.css"> в head. Он останавливается. Ждёт, пока загрузится весь этот CSS-файл полностью. Только потом применяет стили и начинает отрисовку страницы. Весь этот процесс называется Critical Rendering Path — критический путь отрисовки.

На 4G-соединении эта задержка очень ощутима. Ваш HTML — 50 KB, CSS — 250 KB. На медленной сети загрузка может занять 2–3 секунды. За это время пользователь видит белый экран. По данным Google, 53% пользователей уходят, если загрузка дольше 3 секунд. Каждые 0,1 сек задержки LCP приводят к потере конверсий.

Критический путь отрисовки и области видимости

Critical Rendering Path состоит из двух частей. Первая — загрузка ресурсов (HTML, CSS, JavaScript). Вторая — парсинг и отрисовка. CSS находится в самом начале этого пути. Он блокирует всё остальное.

Но вот в чём фокус: пользователь видит первой только небольшую часть страницы. На desktop это примерно 70% viewport высоты, на мобильном — может быть и меньше. Это называется areas above the fold. Стили для первой области видимости критические — их браузер должен применить прямо сейчас. Остальные стили могут подождать.

Конкретный пример: e-commerce сайт

Представьте e-commerce: большой hero-баннер с фоновым изображением, заголовок, кнопка «Купить». Ниже товарная сетка, footer со ссылками.

Обычно полный CSS для такого сайта займет 200–300 KB. Содержит стили для: • hero-секции (10 KB) • карточек товаров (50 KB) • модальных окон (20 KB) • подвала (15 KB) • боковой навигации (25 KB) • и десяток других компонентов

Браузер скачивает ВСЕ эти 300 KB, хотя пользователь видит первыми только hero и несколько товаров. Остальные стили он не использует на первом экране.

Здесь поможет Critical CSS. Вы берёте стили, которые нужны первой области видимости — для hero это может быть 12–15 KB — и кладёте их прямо в HTML, в тег <style> в head:

<style>
  .hero { display: grid; }
</style>
<link rel="preload" href="/styles-async.css" as="style">

Остальной CSS (285 KB) загружается асинхронно, в фоне. Браузер не ждёт эти файлы, он сразу может рисовать первую область видимости.

Before и After: реальные метрики

На примере этого e-commerce улучшения были такие:

Метрика	Было	Стало	Улучшение
First Contentful Paint (FCP)	2,1 с	0,9 с	-57%
Largest Contentful Paint (LCP)	4,2 с	1,8 с	-57%

Это улучшение только за счёт переноса части CSS в HTML. FCP — это когда пользователь видит первый пиксель контента. LCP — когда загружается самый крупный видимый элемент (обычно hero-изображение).

Как измерять результаты

Откройте Google PageSpeed Insights, введите URL вашего сайта. Смотрите на метрики загрузки — FCP, LCP и CLS:

FCP — первый видимый контент
LCP — самый крупный видимый элемент (обычно фото, заголовок, кнопка)
CLS — Cumulative Layout Shift, смещение макета при загрузке

Также используйте Lighthouse (F12 → Lighthouse tab). Запустите аудит для мобильных устройств. Google покажет точно, требуется ли вам Critical CSS и как много вы сможете выиграть.

PageSpeed Insights отображает эти метрики для мобильных и desktop отдельно. На медленных сетях улучшения ещё более заметны.

Почему стандартный CSS медленный

Обычный подход — написать весь CSS для всех компонентов, собрать в один stylesheet, положить в HEAD:

<link rel="stylesheet" href="/styles.css">

Браузер смотрит на этот тег, начинает скачивать styles.css. Пока скачивается, парсинг HTML приостанавливается. CSS блокирует рендеринг. Браузер ждёт загрузку всего файла, затем применяет стили, потом уже может начать отрисовку страницы. Это неэффективно, когда первой области видимости нужно только 5–10% от всех стилей.

Инструменты для Critical CSS

Есть несколько инструментов для работы с критическим CSS:

Critters — автоматизирует весь процесс для webpack и Next.js
CriticalCSS — специализированный инструмент для анализа
Penthouse — найдёт и выделит критические стили

Они работают одинаково: анализируют HTML, находят, какие CSS-правила применяются к первой области видимости, выделяют эти стили. Плагины для webpack инлайнят их прямо в HTML во время сборки.

Остальной CSS загружайте с помощью rel="preload":

<link rel="preload" href="/styles-async.css" as="style">
<link rel="stylesheet" href="/styles-async.css" media="print" onload="this.media='all'">

Особенно важно для мобильных и медленных сетей

На смартфоне с 3G-соединением загрузка CSS может быть в 5–10 раз медленнее, чем у вас в офисе. Первая область видимости становится критичной. Если её стили должны загружаться отдельно — это добавляет задержку. Если инлайнить критический CSS, браузер может отрисовать её мгновенно.

В странах с медленным интернетом (Индия, Бразилия, Юго-Восточная Азия) это не опция, а необходимость. Google учитывает это в Web Vitals и использует как ранк-фактор для SEO поиска.

На практике улучшение LCP составляет 30–60%, FCP улучшается на 40–70%. Размер критического CSS обычно 10–30 KB из полных 150–300 KB. Это минимальная цена инлайнирования, а выигрыш в скорости загрузки значительный.