Кратко: критический CSS (Critical CSS) — это минимальный набор стилей, который нужен браузеру, чтобы отрисовать первый экран страницы, не дожидаясь загрузки всей таблицы стилей. Обычный CSS блокирует рендеринг: пока файлы стилей не загружены, пользователь видит белый экран. Решение — встроить стили первого экрана прямо в head страницы, в тег style, а основной файл CSS подключать асинхронно и применять сразу после загрузки. В WordPress это делается тремя путями: плагином оптимизации, генератором критического CSS (npm-пакет critical, Penthouse или онлайн-сервис) либо собственным PHP-хуком на wp_head. Результат — быстрый First Contentful Paint, меньше предупреждений в PageSpeed Insights и первый экран, который появляется мгновенно. Ниже — рабочие примеры кода, таблицы сравнения и чек-лист проверки.
Что такое критический CSS и зачем он нужен
Критический CSS — это часть таблицы стилей, которая отвечает за всё, что видно на первом экране сразу после загрузки: шапка и меню, заголовок, кнопки, фон, карточки в верхней части страницы. Идея приёма проста: вместо того чтобы заставлять браузер ждать загрузки огромного style.css целиком, мы отдаём ему маленький набор правил прямо в HTML-коде страницы, а остальные стили загружаются параллельно и незаметно для пользователя.
Зачем это нужно, объясняется механикой браузера. CSS — ресурс, блокирующий рендеринг (render-blocking). Пока браузер не скачает и не разберёт все подключённые таблицы стилей, он не начнёт показывать страницу: сначала строится дерево DOM, затем стилевое дерево CSSOM, и только после этого происходит первая отрисовка. Чем больше файлов стилей подключено — стили темы, плагинов, библиотек, — тем позже пользователь увидит хоть что-то на экране. Критический CSS убирает эту зависимость для первого экрана: страница отрисовывается сразу, а полный набор стилей догружается фоном.
Практическая польза заметна в метриках. First Contentful Paint (первая отрисовка контента) приходит раньше, Largest Contentful Paint (отрисовка главного элемента) улучшается, а Lighthouse и PageSpeed Insights перестают ругаться на render-blocking ресурсы. Скорость — один из факторов ранжирования и, что важнее, один из факторов конверсии: посетитель, который видит контент через секунду, реже возвращается к поиску. Прежде чем браться за генерацию критического CSS, убедитесь, что стили в теме подключены правильным способом — детально об этом в статье про подключение CSS и JS в WordPress через wp_enqueue_scripts.
Как CSS блокирует первую отрисовку
Посмотрим, что происходит при загрузке типичного сайта на WordPress. В head страницы подключено несколько таблиц стилей: основная тема, дочерняя тема, стили двух-трёх плагинов, библиотека иконок, шрифты. Пока все эти файлы не загрузятся, страница остаётся пустой: браузер не рисует даже ту часть, стили которой уже известны.
<link rel="stylesheet" href="/wp-content/themes/my-theme/style.css">
<link rel="stylesheet" href="/wp-content/plugins/my-plugin/assets/style.css">На быстром соединении разница незаметна, но на мобильном интернете каждый файл — это отдельный запрос, задержка сервера и время загрузки. Пользователь смотрит на белый экран две-три секунды вместо того, чтобы читать страницу. Именно поэтому «устраните ресурсы, блокирующие отрисовку» — одна из первых рекомендаций любого аудита скорости.
Оптимальная схема выглядит иначе: минимум стилей для первого экрана встроен прямо в head, а полный файл стилей загружается асинхронно и применяется, как только скачается.
<style>
/* стили первого экрана: шапка, меню, заголовок */
.site-header { min-height: 64px; background: #ffffff; }
.site-title { font-size: 28px; margin: 0; }
</style>
<link rel="preload" href="/wp-content/themes/my-theme/style.css" as="style" onload="this.rel='stylesheet'">Уменьшить итоговый вес стилей помогает минификация и объединение файлов — это дополняет критический CSS, но не заменяет его: даже маленький файл, подключённый синхронно, остаётся блокирующим. Подробнее о том, как уменьшить вес ресурсов, — в отдельном материале про минификацию и объединение CSS и JS.
Важный нюанс: асинхронная загрузка основного CSS — это всегда компромисс. Если критический набор неполный или устаревший, пользователь увидит скачок стилей: страница успеет показаться в «черновом» виде и перестроится. Такой эффект называют FOUC (flash of unstyled content), и бороться с ним нужно не отказом от приёма, а аккуратной генерацией критического CSS — об этом ниже.
Способы внедрения критического CSS в WordPress
Есть четыре рабочих подхода, и выбор между ними — это вопрос контроля против усилий. Для разового проекта проще взять плагин; для сайта, который развивается и часто обновляется, рано или поздно захочется автоматизировать генерацию.
| Способ | Как работает | Плюсы | Минусы |
|---|---|---|---|
| Плагин оптимизации | Встраивает критический CSS и откладывает загрузку остального по настройке | Минимум усилий, всё в админке | Меньше контроля, зависимость от обновлений плагина |
| Онлайн-генератор | Отдаёт готовый набор стилей для конкретной страницы | Быстро для разовой задачи, ничего не нужно устанавливать | Приходится повторять вручную, набор устаревает после редизайна |
| Сборка на Node | Пакеты critical и Penthouse генерируют наборы для списка страниц одной командой | Автоматизация, точность, встраивается в процесс сборки проекта | Нужен Node и понимание, как устроена сборка |
| Свой PHP-хук | Встраивает заранее сгенерированный файл в head, а основной CSS откладывает фильтром | Полный контроль и прозрачность, никаких сторонних сервисов | Всю поддержку и обновление берёте на себя |
Начать проще всего с плагина: он покажет результат и позволит оценить выгоду без правки кода. Когда поймёте, что приём работает, можно перейти к более точным инструментам — например, генерировать набор для каждого шаблона с помощью npm-пакета critical и складывать результаты в собственную тему. Оба пути мы разберём по шагам, а сначала — короткий обзор плагинов.
Плагины для критического CSS: что выбрать
Если не хочется трогать код, начните с плагина. Важно выбрать один инструмент и не включать одновременно несколько оптимизаторов: пересекающиеся настройки ломают вывод стилей и создают трудноуловимые конфликты, которые потом ищут по всему сайту.
| Плагин | Что умеет | Когда выбирать |
|---|---|---|
| Autoptimize | Бесплатный: минификация и объединение CSS и JS, встраивание критического CSS (вручную или через сервис) | Когда нужен рабочий результат без бюджета |
| WP Rocket | Платный кэш-плагин: оптимизация доставки CSS, генерация критического набора, отложенная загрузка | Когда нужен комбайн «кэш и оптимизация» из коробки |
| Perfmatters | Платный: удаление неиспользуемого CSS, тонкие настройки загрузки стилей и скриптов по страницам | Когда базовая оптимизация уже сделана и нужны детали |
| Clearfy | Бесплатный комплексный оптимизатор: минификация, кэш, отключение лишних ресурсов | Когда хочется собрать полезные оптимизации в одном месте |
Установить и активировать плагин можно прямо из командной строки — это быстрее, чем через админку, и удобно, когда настраиваете сразу несколько сайтов. Основные команды собраны в гайде по WP-CLI для новичков.
wp plugin install autoptimize --activateПосле установки включите опцию инлайна критического CSS, вставьте или сгенерируйте набор и проверьте результат на трёх типах страниц: главная, запись и архив. Если что-то отображается не так, сначала отключите новую опцию и убедитесь, что проблема именно в ней, — а не в конфликте с другим плагином.
Генерация критического CSS: инструменты и команды
Генератор открывает страницу в «безголовом» браузере, вычисляет, какие стили влияют на элементы первого экрана, и возвращает готовый набор правил. Два самых известных инструмента — пакет critical и его движок Penthouse. Оба ставятся через npm и запускаются одной командой.
npx critical index.html --inline --minify --width 1300 --height 900
npx critical https://example.com --inline --minifyФлаг —inline сразу встраивает результат в HTML, —minify сжимает код, а —width и —height задают размер окна, для которого считается первый экран. Для WordPress удобнее генерировать наборы не по готовому HTML, а по адресам страниц: главная, статья, страница, каталог товаров — у каждого шаблона свой первый экран.
const penthouse = require('penthouse');
const fs = require('fs');
penthouse({
url: 'https://example.com',
css: 'wp-content/themes/my-theme/style.css',
width: 1300,
height: 900
}).then(function (criticalCss) {
fs.writeFileSync('css/critical-home.css', criticalCss);
console.log('Критический CSS готов');
});Несколько практических правил. Генерируйте наборы отдельно для мобильной и десктопной ширины: на смартфоне выше линии сгиба оказываются совсем другие блоки, чем в широком окне. Храните файлы критического CSS в дочерней теме — тогда обновление основной темы не сотрёт ваши файлы; как её создать, рассказано в гайде про дочернюю тему WordPress. И не пренебрегайте регламентом: после редизайна или правок шапки набор нужно пересобрать, а сами обновления движка проходят без риска, если следовать правилам безопасного обновления WordPress.
Асинхронная загрузка основного CSS: два паттерна
Когда критический CSS встроен в head, остальные стили можно грузить асинхронно. Есть два проверенных способа сделать это без JavaScript-библиотек — чистым HTML.
Паттерн 1: media=»print» плюс onload. Браузер считает таблицу стилей «для печати» и не блокирует ей рендеринг, а как только файл загрузится, скрипт в атрибуте onload переключает media на all. В noscript остаётся обычная синхронная версия — для посетителей с отключённым JavaScript.
<link rel="stylesheet" href="/style.css" media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/style.css"></noscript>Паттерн 2: rel=»preload». Файл загружается с высоким приоритетом, но не применяется до переключения rel на stylesheet. Этот вариант считается более современным: preload сообщает браузеру, что ресурс важен, и он скачивается раньше и стабильнее, чем при первом подходе.
<link rel="preload" href="/style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/style.css"></noscript>Оба паттерна дают одинаковый результат, поэтому выбирайте тот, что лучше ложится в ваш код. Главное — помнить: асинхронно стоит грузить именно основной файл стилей, а всё, что нужно для первого экрана, должно быть в инлайновом наборе. И не забудьте про кэш: после внедрения очистите кэш плагина и браузера, иначе рискуете тестировать старое поведение — общие принципы в статье про кэширование WordPress.
Своя реализация: PHP-хуки WordPress
Когда набор готов, его нужно встроить в тему. Самый простой способ — вывести содержимое файла критического CSS в head через хук wp_head с минимальным приоритетом, чтобы блок стоял в самом начале секции и применялся раньше стилей плагинов.
<?php
add_action('wp_head', function () {
if (!is_front_page()) {
return;
}
$critical = get_stylesheet_directory() . '/css/critical-home.css';
if (file_exists($critical)) {
echo '<style id="critical-css">' . file_get_contents($critical) . '</style>';
}
}, 1);Такой сниппет удобно держать в functions.php дочерней темы: он подключает отдельный файл для главной страницы, а для остальных шаблонов можно добавить свои ветки условий — is_single(), is_archive(), is_product(). Главное — не превращать условие в свалку и следить, чтобы критический CSS выводился только на фронтенде и только там, где он действительно нужен.
Вторая часть задачи — отложить основной файл стилей. Если стили темы подключены через wp_enqueue_style, их тег можно переписать фильтром style_loader_tag, превратив синхронную загрузку в отложенную.
<?php
add_filter('style_loader_tag', function ($tag, $handle) {
if ('my-theme-style' !== $handle) {
return $tag;
}
return str_replace(
"rel='stylesheet'",
"rel='preload' as='style' onload=\"this.rel='stylesheet'\"",
$tag
);
}, 10, 2);Имя дескриптора (handle) видно в исходном коде страницы: в id каждого тега link есть суффикс -css и название подключения. Применяйте фильтр точечно — только к стилям темы, а не ко всем подряд: у части плагинов от порядка загрузки зависит корректность работы. Если после правок что-то пошло не так, включите отладку по инструкции WP_DEBUG и отладка WordPress и посмотрите логи — большинство ошибок в хуках видно сразу.
Проверка результата: метрики и инструменты
После внедрения обязательно сравните «до» и «после». Тестируйте в режиме инкогнито, с очищенным кэшем и включённым троттлингом сети — иначе получите идеальные цифры на локальном соединении, которые ничего не говорят о реальных посетителях.
| Инструмент | Что проверяем | Ориентир |
|---|---|---|
| PageSpeed Insights и Lighthouse | FCP, LCP и предупреждения о блокирующих ресурсах | FCP до 1,8 с, LCP до 2,5 с |
| DevTools, вкладка Network | Порядок загрузки CSS и момент первой отрисовки | Основной стиль не мешает первому рендеру |
| DevTools, вкладка Coverage | Доля неиспользуемого CSS на странице | Критический набор маленький, остальное грузится отложенно |
| WebPageTest | Плёночная раскадровка загрузки | Первый экран появляется сразу, без белой паузы |
Быстрее всего посмотреть на первую отрисовку прямо в консоли браузера — метрики paint доступны через PerformanceObserver.
new PerformanceObserver(function (list) {
list.getEntries().forEach(function (entry) {
console.log(entry.name, Math.round(entry.startTime));
});
}).observe({ type: 'paint', buffered: true });А для полноценного отчёта подойдёт Lighthouse из командной строки — тот же движок, что работает в PageSpeed Insights.
npx lighthouse https://example.com --only-categories=performance --preset=desktop --viewВ отчёте смотрите на две вещи: предупреждение о блокирующих ресурсах должно исчезнуть или сильно похудеть, а FCP — сократиться. Не забывайте про картинки: изображения первого экрана часто упираются в LCP, поэтому заодно проверьте оптимизацию изображений в WordPress.
Типичные ошибки и подводные камни
Неполный критический CSS. Самая частая ошибка: в набор не попали элементы, которые видны сразу — всплывающая шапка, баннер, фильтры каталога. Пользователь видит скачок стилей. Лечение одно: перегенерировать набор для каждого шаблона и проверить на реальных страницах под разными разрешениями.
Один набор на весь сайт. Главная, статья и каталог имеют разную структуру первого экрана. Универсальный «средний» набор либо раздут, либо неполон. Лучше несколько маленьких файлов по типу шаблона, чем один большой компромисс.
Забыли про мобильные. Проверка только на десктопе — классика. Ширина окна 1300 пикселей и 390 пикселей показывает разные первые экраны, поэтому генерируйте отдельные наборы или консервативный общий, покрывающий оба случая.
Двойная оптимизация. Два плагина, которые встраивают критический CSS и откладывают загрузку, складывают эффекты непредсказуемо: стили могут задваиваться или теряться. Выберите один инструмент и отключите дублирующие опции у остальных.
Устаревшие наборы. После обновления темы или правок шапки старый критический CSS начинает врать. Заведите привычку пересобирать его вместе с релизом изменений — руками или скриптом в процессе сборки.
Раздутый инлайн. Критический CSS на десятки килобайт убивает идею: HTML толстеет, а эффект теряется. Держите набор компактным — только первый экран, без правил «на всякий случай».
Смешанный контент. Асинхронные стили, подключаемые по http на https-странице, блокируются браузером — оптимизация ломается. Если сайт ещё не полностью переведён на HTTPS, начните с миграции: пошаговый порядок — в статье про миграцию сайта WordPress на HTTPS.
Медленный сервер. Никакой критический CSS не спасёт, если сервер отвечает секунду: время до первого байта съедает весь выигрыш. Проверьте, правильно ли выбран хостинг для сайта, и при необходимости рассмотрите перенос сайта на другой хостинг.
Эксперименты без бэкапа. Правки в хуках и стилях легко откатить, только если есть свежая копия. Перед любыми экспериментами сделайте резервную копию — как настроить резервное копирование WordPress, мы уже подробно рассказывали.
Частые вопросы о критическом CSS в WordPress
Что такое критический CSS простыми словами?
Критический CSS — это минимальный набор стилей для того, что видно на первом экране: шапка, меню, заголовок, кнопки. Он встраивается прямо в HTML страницы, поэтому браузер рисует её сразу, не дожидаясь загрузки основного файла стилей. Остальные правила подгружаются асинхронно и применяются следом. В итоге пользователь быстрее видит контент, а метрики скорости в отчётах улучшаются.
Не сломает ли критический CSS дизайн сайта?
Нет, при правильной генерации дизайн не изменится. Критический CSS дублирует только стили первого экрана, а полный набор всё равно загружается и применяется следом. Сломать вид страницы может лишь неполный или устаревший набор — тогда заметен скачок оформления. Регулярно пересобирайте критический CSS после правок дизайна и проверяйте ключевые шаблоны — так риск сводится к нулю.
Можно ли внедрить критический CSS без программиста?
Да. Проще всего — плагином: многие оптимизаторы умеют встраивать критический CSS автоматически или принимают готовый набор в настройках. Для разового решения подойдут онлайн-генераторы: указываете адрес страницы, получаете готовый CSS и вставляете его в тему. Программист понадобится, если хочется автоматизации, точного контроля над шаблонами и интеграции в процесс сборки.
Почему после внедрения мигают стили?
Это эффект FOUC: страница успевает показаться до применения основного CSS, а критический набор не покрывает первый экран. Причина почти всегда одна — набор неполный или устаревший: не хватает правил для шапки, баннеров, отдельных блоков. Перегенерируйте критический CSS для всех типов страниц, проверьте мобильную и десктопную версии и очистите кэш — мигание исчезнет.
Нужен ли критический CSS, если у сайта есть кэш и CDN?
Да, нужен. Кэш и CDN ускоряют отдачу файлов и повторные визиты, но при первом заходе браузер всё равно ждёт загрузки CSS, прежде чем показать страницу — свойство блокировки рендеринга никуда не девается. Критический CSS снимает именно это ограничение: первый экран рисуется сразу даже на новом устройстве с пустым кэшем. Поэтому оба инструмента дополняют друг друга, а не заменяют.
Как часто нужно обновлять критический CSS?
При каждом изменении внешнего вида сайта: обновление темы, новая шапка, правки сетки, новые блоки на первом экране. Если генерация автоматизирована, добавьте её в процесс сборки, чтобы набор всегда соответствовал актуальной вёрстке. Начните с простого правила: после любого редизайна пересобрать критические наборы для основных шаблонов и проверить метрики заново.
Вывод
Критический CSS — самый прямой способ убрать блокирующий рендеринг и ускорить первую отрисовку WordPress. Логика работы такая: измерьте текущие метрики, сгенерируйте наборы стилей для первого экрана по шаблонам, встройте их в head, отложите загрузку основного файла одним из двух паттернов и проверьте результат в Lighthouse. Всё это делается кодом, без магии, и предсказуемо работает.
Не усложняйте: для старта достаточно плагина и одного-двух наборов; автоматизацию стоит подключать, когда сайт активно развивается. И держите под контролем два слабых места — актуальность наборов после редизайна и аккуратность в хуках: их легко проверить через отладку, а эксперименты страховать бэкапами.
Если не хочется разбираться с генераторами и фильтрами самостоятельно, доверьте это команде: мы настроим критический CSS, отложенную загрузку ресурсов и кэширование так, чтобы сайт стал быстрее без риска для дизайна. Посмотрите услуги по разработке и поддержке сайтов, изучите портфолио выполненных проектов и почитайте блог о разработке и продвижении. А если сайт уже работает и нужна точечная доработка, можно заказать доработку сайта у программиста. Опишите задачу через форму контактов — подскажем, какие оптимизации дадут прирост именно вашему сайту.
