Critical CSS: как убрать рендер-блокировку и ускорить первый экран
Вы оптимизировали картинки, разогнали сервер, а PageSpeed Insights всё равно показывает белый экран первые секунды и красную надпись «Устраните ресурсы, блокирующие отображение». Знакомо? Виновники — CSS и синхронный JavaScript, которые браузер обязан скачать и обработать, прежде чем нарисовать хоть один пиксель. Это называется render-blocking, рендер-блокировка, и она одна из самых частых причин медленного первого экрана. Лекарство — Critical CSS: техника, при которой минимальный набор стилей для первого экрана подаётся мгновенно, а всё остальное грузится в фоне. Разберём, как это работает, как внедрить и каких подводных камней избежать.
Что такое render-blocking ресурсы
Когда браузер парсит HTML и натыкается на подключённый CSS-файл, он останавливает построение визуального дерева до тех пор, пока стили не будут полностью загружены и обработаны. Логика понятна: показать страницу без стилей — значит мигнуть пользователю «голым» неоформленным контентом (так называемый FOUC). Поэтому CSS по умолчанию блокирует отрисовку. То же самое с синхронным JavaScript в <head>: пока скрипт не скачается и не выполнится, парсинг HTML стоит на паузе.
Проблема в том, что типичный сайт подключает один-два больших CSS-файла фреймворка на сотни килобайт, из которых для первого экрана реально нужно от силы 10–15%. Браузер же честно ждёт загрузки всего файла, прежде чем начать рисовать. Эти потерянные секунды напрямую бьют по First Contentful Paint и Largest Contentful Paint — ключевым метрикам, о которых мы подробно писали в материале про то, как улучшить Core Web Vitals и скорость загрузки.
Что такое Critical CSS
Critical CSS (критический CSS, или above-the-fold CSS) — это тот минимальный набор стилей, который необходим для корректной отрисовки только видимой части страницы, того, что попадает в окно браузера без прокрутки. Идея в том, чтобы выделить эти стили из общего файла, заинлайнить их прямо в <head> внутри тега <style>, а основной CSS-файл загрузить асинхронно, не блокируя отрисовку.
Эффект таков: браузер получает HTML с уже встроенными критическими стилями и может нарисовать первый экран немедленно, не дожидаясь скачивания внешних файлов. Пользователь видит оформленную страницу почти сразу, а остальные стили (для нижних блоков, футера, всплывающих элементов) подтягиваются в фоне и применяются по готовности. Это один из самых результативных приёмов для ускорения первого экрана, особенно в связке с оптимизацией LCP, которую мы разбирали в статье про ускорение главного контента страницы.
Как PageSpeed и Lighthouse показывают проблему
Диагностировать рендер-блокировку проще всего через PageSpeed Insights и Lighthouse. В отчёте ищите два связанных аудита.
- «Устраните ресурсы, блокирующие отображение» (Eliminate render-blocking resources) — здесь перечислены конкретные CSS- и JS-файлы, тормозящие первую отрисовку, с указанием потенциальной экономии в миллисекундах.
- «Уменьшите неиспользуемый CSS» (Reduce unused CSS) — показывает, сколько стилей загружается, но не применяется на первом экране. Это прямой кандидат на вынос из критического пути.
Дополнительно во вкладке Coverage в Chrome DevTools можно увидеть процент неиспользуемого CSS и JS прямо по строкам. Если в красной зоне 70–80% файла — это явный сигнал, что критические стили стоит выделить отдельно. Такая диагностика — стандартная часть технического SEO-аудита сайта.
Методика внедрения Critical CSS
Процесс состоит из трёх логических шагов: выделить критический CSS, заинлайнить его в head и загрузить остальное асинхронно. Разберём каждый.
Шаг 1. Выделить критический CSS
Нужно определить, какие именно правила стилей участвуют в отрисовке первого экрана. Вручную это делать тяжело и хрупко, поэтому используют генераторы (о них ниже). Они открывают страницу в headless-браузере при заданной ширине viewport, фиксируют, какие селекторы применяются к видимым элементам, и собирают из них компактный набор критических стилей — обычно это 10–30 КБ.
Шаг 2. Заинлайнить в head
Полученный критический CSS встраивается напрямую в HTML внутри тега <style> в секции <head>. Поскольку это инлайн-стили, браузеру не нужно делать дополнительный сетевой запрос — он применяет их мгновенно при парсинге HTML. Именно это и убирает рендер-блокировку для первого экрана.
Шаг 3. Загрузить остальной CSS асинхронно
Полный CSS-файл подгружается так, чтобы не блокировать отрисовку. Классический приём — preload с переключением media по событию onload: <link rel="preload" href="style.css" as="style" onload="this.rel=stylesheet">. Альтернатива — media-трюк: подключить файл с media="print", а затем по onload сменить на all. В обоих случаях браузер качает CSS в фоне и применяет его, когда он готов, не задерживая первую отрисовку. Обязательно добавляйте <noscript>-фолбэк с обычным подключением для случаев отключённого JS.
Critical CSS — это про приоритеты внимания браузера. Дайте ему ровно столько стилей, сколько нужно нарисовать первый экран, и ни байтом больше. Остальное подождёт в фоне. Этот приём часто срезает с FCP целую секунду без всякого изменения дизайна.
Defer и async для JavaScript
CSS — не единственный блокировщик. Синхронные скрипты в <head> останавливают парсинг HTML. Два атрибута решают проблему.
| Атрибут | Когда грузится | Когда выполняется | Для чего подходит |
|---|---|---|---|
| без атрибута | сразу, блокируя парсинг | немедленно | почти никогда в head |
| async | параллельно с парсингом | сразу по готовности, в любом порядке | независимые скрипты, аналитика |
| defer | параллельно с парсингом | после парсинга HTML, по порядку | основная логика, скрипты с зависимостями |
Практическое правило: для большинства скриптов используйте defer — он не блокирует отрисовку и сохраняет порядок выполнения. async хорош для полностью независимых счётчиков и пикселей. Тяжёлая JS-логика, особенно в SPA, требует отдельного подхода — об этом материал про JavaScript SEO и продвижение SPA на React.
Инструменты генерации Critical CSS
Вручную выделять критический CSS — путь к ошибкам и боли при поддержке. Используйте автоматику.
- Critical (от Addy Osmani) — npm-инструмент, генерирует и инлайнит критический CSS, удобен в сборочном пайплайне.
- Penthouse — библиотека под капотом многих генераторов, извлекает above-the-fold стили для заданного URL и viewport.
- CriticalCSS-сервисы — онлайн-генераторы для быстрой разовой задачи.
- Плагины WordPress — LiteSpeed Cache, WP Rocket, Autoptimize умеют генерировать и подключать критический CSS почти без ручной работы. Подробности по движку — в гайде про оптимизацию сайта на WordPress для SEO.
Важный момент: критический CSS отличается для разных типов шаблонов — главная, категория, статья выглядят по-разному. Хорошие инструменты генерируют отдельный критический набор под каждый шаблон, а не один универсальный.
Влияние на FCP и LCP
Эффект от внедрения критического CSS проявляется прежде всего в двух метриках. FCP (First Contentful Paint) улучшается напрямую: браузер рисует первый контент, как только распарсил HTML с инлайн-стилями, не дожидаясь внешних файлов. LCP (Largest Contentful Paint) тоже выигрывает, потому что отрисовка крупного элемента первого экрана больше не упирается в ожидание загрузки всего CSS.
На практике корректное устранение рендер-блокировки нередко срезает 0,5–1,5 секунды с FCP на медленных соединениях. Это ощутимо и для пользователя, и для оценки скорости поисковиком. Для полноты картины критический CSS стоит сочетать с оптимизацией шрифтов — см. материал про оптимизацию шрифтов и font-display, поскольку веб-шрифты тоже умеют блокировать отрисовку текста.
Подводные камни
Техника мощная, но не без нюансов. Вот что важно держать в голове.
- Дублирование стилей. Критический CSS инлайнится в каждый HTML-документ, увеличивая его вес. Для одной страницы это плюс к скорости, но за этим надо следить, чтобы инлайн не разрастался.
- Кэширование. Инлайн-стили не кэшируются отдельно — они часть HTML. Если HTML не кэшируется, критический CSS грузится при каждом запросе. Обычно это оправдано выигрышем в скорости первого рендера.
- Поддержка и актуальность. При изменении дизайна критический CSS нужно перегенерировать, иначе на первом экране возможны визуальные дефекты. Автоматизируйте регенерацию в сборке.
- FOUC при ошибках. Если критический набор неполный, пользователь может мигнуть неоформленным контентом. Тщательно тестируйте на разных шаблонах и viewport.
Чек-лист устранения рендер-блокировки
- Прогоните страницу через PageSpeed Insights и зафиксируйте аудиты по render-blocking и unused CSS.
- Сгенерируйте критический CSS для каждого основного типа шаблона.
- Заинлайньте критический CSS в
<head>внутри тега<style>. - Подключите полный CSS асинхронно через preload и onload с noscript-фолбэком.
- Добавьте
deferко всем неблокирующим скриптам,async— к независимым счётчикам. - Проверьте отсутствие FOUC и визуальных дефектов на всех типах страниц.
- Перемерьте FCP и LCP в Lighthouse и сравните с исходными значениями.
- Настройте автоматическую регенерацию критического CSS при изменении дизайна.
Устранение рендер-блокировки через Critical CSS — одна из тех оптимизаций, что дают видимый невооружённым глазом результат: страница перестаёт мигать белым и оформляется мгновенно. Но настройка требует аккуратности и тестирования на каждом шаблоне. Если не хотите возиться с генераторами и асинхронной загрузкой стилей, доверьте это нам — закажите доработку сайта с устранением рендер-блокировки или комплексное продвижение сайтов, где скорость первого экрана — один из факторов выхода в ТОП.
Услуги LSI Продвижение
Наша команда предлагает полный спектр услуг по SEO-продвижению и технической доработке сайтов. Мы работаем только белыми методами, ориентируемся на реальный бизнес-результат — трафик, заявки и продажи, а не только позиции в отчёте, — и выстраиваем продвижение системно, под конкретные задачи и нишу вашего проекта. Начать можно с бесплатной диагностики, чтобы понять текущее состояние сайта и точки роста, а затем перейти к комплексной работе. Выберите подходящую услугу из списка ниже:
- Бесплатный SEO аудит сайта — автоматическая проверка на 50+ параметров за 2 минуты
- Комплексный SEO аудит — глубокий ручной анализ с рекомендациями от эксперта
- Продвижение сайтов — вывод в ТОП Яндекса и Google по целевым запросам
- SEO консультация — разбор вашего сайта с конкретными рекомендациями
- LSI тексты — экспертный контент, оптимизированный для поисковых систем
- Доработка сайта — техническая оптимизация и исправление ошибок
- Создание сайта под ключ — разработка с нуля с SEO-оптимизацией
- Стоимость продвижения — прозрачные тарифы и условия
- Портфолио и кейсы — реальные результаты наших клиентов
Закажите SEO продвижение сайта
Выведем ваш сайт в ТОП Яндекса и Google. Бесплатная консультация — разберём сайт, найдём точки роста и предложим стратегию продвижения.
Comments
Наконец-то внятное объяснение, почему PageSpeed ругается на «ресурсы, блокирующие отображение». Я думал, дело в тяжёлых картинках, а оказалось — синхронный CSS в head. Спасибо, буду выделять критический.
А как понять, какие именно стили относятся к первому экрану? Боюсь заинлайнить лишнего или наоборот пропустить что-то важное, и получится мигание вёрстки.
Елена, ориентируйтесь на то, что видно в области первого экрана без прокрутки: сетка, шапка, первый блок, шрифты для видимого текста. Проще всего снять это инструментом генерации по нужному разрешению, а потом глазами убрать явно лишнее. Если боитесь мигания — мы на аудитах как раз выверяем этот набор вручную.
Внедрил Critical CSS по вашему шаг 1-2-3, FCP упал с 2,8 до 1,4 секунды. Загрузку остального CSS сделал через media=print и onload. Работает!
Держу интернет-магазин на Битриксе, там шаблон генерит стили в кучу файлов. Реально ли там выделить критический CSS или это только для самописных сайтов?
Не совсем поняла разницу между defer и async для JavaScript. Если скрипт с аналитикой — что ставить, чтобы он не блокировал рендер?
Ольга, для скрипта аналитики ставьте async — он загрузится параллельно и не будет блокировать рендер, а порядок выполнения для счётчика не важен. defer нужен, когда важна последовательность и зависимость от DOM. Для критичных к порядку скриптов — defer, для независимых счётчиков — async.
Спасибо за упоминание инструментов генерации. Пробовал Critical от addyosmani, но на динамических страницах он выдаёт разный результат. Как быть с этим?
У меня после инлайна критического CSS всё равно красная надпись про render-blocking осталась, но уже из-за шрифтов Google. Это отдельная история или тоже сюда относится?
Подводные камни — самая полезная часть. Про то, что заинлайненный CSS не кэшируется и раздувает HTML, я не задумывался. Получается, для постоянных посетителей это даже минус?
Начинающий вебмастер тут. А если у меня один общий style.css на 80 килобайт — обязательно его разбивать или можно просто асинхронно грузить целиком?
Проверил через Lighthouse — показывает экономию 1,2 с на устранении render-blocking. Полез в код и понял, что jQuery грузится синхронно в head с 2012 года. Спасибо, что подтолкнули.
Очень наглядно про то, что браузер не рисует ни пикселя, пока не обработает весь CSS. Раньше не понимала, почему белый экран висит именно столько.
А влияет ли Critical CSS на LCP или только на FCP? У меня FCP хороший, а LCP красный — стоит ли вообще этим заниматься в моём случае?
Константин, напрямую Critical CSS ускоряет FCP, но косвенно помогает и LCP: пока браузер тянет и парсит весь CSS, отрисовка главного элемента откладывается. Если у вас LCP-картинка, начните с неё — preload и fetchpriority дадут больше. Critical CSS добьёт остаток.
Сделал всё по чек-листу, но забыл про fallback: если JS отключён, media=print так и остаётся, и стили не применяются. Добавил noscript-версию, теперь идеально.
Спорный момент: некоторые советуют вообще не инлайнить, а просто ставить preload на CSS. Чем ваш подход лучше preload?
Марина, preload только раньше запускает загрузку файла, но стили всё равно применяются после скачивания — на медленной сети первый экран подождёт. Инлайн отдаёт критические стили мгновенно, в том же HTML. Идеал — инлайн для первого экрана плюс асинхронная догрузка остального, preload тут вспомогательный.
Веду блог на WordPress, поставил плагин, который сам генерит критический CSS. Но он берёт стили только с главной. Для карточек товаров критический CSS ведь другой?
Спасибо огромное, статью сохранила в закладки. Особенно за пошаговую методику — всё разложено так, что даже без глубоких знаний можно повторить.
А как быть с тем, что дизайнеры постоянно правят стили? Каждый раз перегенерировать критический CSS вручную — это же ад. Есть автоматизация в сборке?
Сергей, обязательно автоматизируйте: подключите генерацию критического CSS в сборку (Gulp/Webpack/CI), тогда при каждом деплое он пересобирается сам по шаблонам страниц. Ручной путь оправдан только для статики, которую правят раз в квартал. Если нужно настроить — это одна из типовых задач, которые мы закрываем в рамках технической оптимизации.
Оставить комментарий
Мы используем cookies
Для улучшения работы сайта и вашего удобства. Оставаясь на сайте, вы соглашаетесь с политикой конфиденциальности.