Определите, подходит ли вам задача критического CSS
Начинайте с доказательств, а не с ярлыка аудита. Запишите холодную загрузку приоритетной страницы на репрезентативных мобильных и десктопных профилях. Проанализируйте waterfall и трассировку: задерживает ли первое содержимое загрузка стилевого файла и достаточно ли он велик, чтобы иметь значение? Панель Coverage в DevTools показывает CSS, использованный в одной сессии, а не во всех маршрутах и состояниях.
Попробуйте сначала методы с меньшими затратами на поддержку: удалите неиспользуемые правила, минифицируйте и сожмите выходной файл, загружайте CSS маршрута только там, где он нужен, и избегайте цепочек @import. web.dev называет извлечение и отложенную загрузку продвинутыми приёмами.
Измеримая задержка первого рендера связана с CSS, холодный визит важен, и начальная вёрстка может быть сохранена.
Если узким местом являются задержка сервера, изображения, шрифты, JavaScript или уже небольшой файл стилей, встраивание CSS вряд ли поможет.
Определите начальный вьюпорт как матрицу тестов
Начальный вьюпорт, иногда называемый above the fold (то, что видно до прокрутки), — это то, что посетитель видит до прокрутки. У него нет универсальной высоты: устройства, масштаб, язык, куки и варианты контента изменяют его. Одна десктопная скриншот-фиксация может пропустить телефон или переведённый заголовок.
Используйте именованные профили. Включите узкие и широкие макеты, ключевые брейкпойнты, разные структуры входа, а также любые баннеры согласия, промо-объявления, сообщения о техническом обслуживании или ошибки валидации, которые появляются в верхней части страницы.
Зафиксируйте шаблон, вьюпорт, локаль, аутентификацию, согласие и варианты в верхней части страницы, которые будут использоваться для генерации и тестирования набора.
Протестируйте быструю прокрутку, меню и фокус форм; правило, загруженное позже, небезопасно, если его элемент управления может появиться до применения полного CSS.
Извлеките небольшой набор из единого источника правды
Генерируйте критический CSS из сборки, той же, что идёт в продакшен. Извлечение может определить правила, используемые в вьюпорте, но проверьте условные, динамические и переходные правила. Не копируйте вручную вторую систему дизайна в шаблоны — она будет расходиться по мере эволюции компонентов и разметки.
Держите выходные данные под генерацией и версионированием вместе со сборкой, а исходный CSS остаётся авторитетным. Встраивайте только правила, необходимые для первого пригодного состояния. Большие встроенные блоки увеличивают HTML и не переиспользуются внешним кешируемым файлом CSS на последующих страницах. Сравните холодную и тёплую навигацию, прежде чем объявлять изменение улучшением.
Отслеживайте сжатые байты встроенного CSS, оставшиеся байты стилевого файла и дублирующиеся правила. Один отсутствующий блокирующий запрос не обязательно даёт чистую выгоду.
Помечайте сборку, если извлечение пусто, превышает бюджет встроенного размера или меняется неожиданно по сравнению с проверенной базовой линией.
Загрузите оставшийся CSS безопасно и соблюдайте ограничения политики
Оставшийся стилевой файл должен прийти до того, как нижний контент и последующие состояния станут выглядеть завершёнными. Описанный паттерн предварительно подгружает CSS как preload/стиль и затем меняет его обратно в stylesheet после загрузки, с запасом для случаев без JavaScript. Preload запрашивает ресурс заранее; он не применяет CSS. Неполный набор может заметно перестилить страницу.
Проверьте Политику безопасности содержимого (Content Security Policy) перед использованием inline-обработчика загрузки. web.dev отмечает, что политика может запрещать встраиваемый onload JavaScript, поэтому используйте совместимый загрузчик или другой дизайн. Тестируйте при отключённом JavaScript. Файлы с media-запросами полезны для действительно условных стилей, например печати; несоответствующий запрос не блокирует отрисовку, хотя может всё ещё скачиваться.
Проверьте, что посетитель без JavaScript получает полный CSS и может завершить приоритетный сценарий.
Отдельно исследуйте поздний первый-вид шрифт или изображение; критический CSS не меняет их поведение загрузки.
Тестируйте визуальные, функциональные и кеш-регрессии
Используйте визуальное сравнение для каждого именованного вьюпорта и состояния в верхней части страницы. Проверьте неотрендеренный текст, перекрытия, скрытую навигацию, отсутствующие индикаторы фокуса, сдвиг вёрстки и «вспышку» при применении отложенного CSS. Пройдите клавиатурную навигацию, сенсорные пути, ошибки и быструю прокрутку. Если отложенное правило делает элемент управления непригодным, оно должно быть в критическом пути или дизайн должен измениться.
Тестируйте холодные и тёплые визиты. Холодное тестирование показывает, помогает ли удаление ожидания CSS улучшить отрисовку; тёплое — показывает повторяющуюся стоимость встроенных байтов. Тестируйте кешированное предыдущее HTML и возврат после деплоя. Сохраняйте совместимые ресурсы, пока закешированные документы могут запрашивать их, и не перезаписывайте URL с fingerprint-метками.
Сравните first content и main visible content, затем используйте трассировку, чтобы объяснить выигрыш или регрессию.
Включите фокус, контраст, предпочтения по анимациям, масштаб и читаемый порядок. Более быстрая отрисовка не означает успеха, если интерфейс недоступен.
Эксплуатируйте это как обратимую функцию доставки
Назначьте владельца пайплайна и задокументируйте входы, артефакт, шаблоны, тестовые профили и предел встроенного размера. Запускайте тесты при каждом изменении CSS, разметки, библиотеки компонентов, флага функции или третьей стороны, влияющей на верхнюю часть страницы. Coverage направляет обзор, но одна запись не может доказать, что правило безопасно везде.
Выпускайте за флагом, позволяющим откат, где это возможно. Записывайте известный рабочий путь стилевого файла, версию артефакта, идентификатор сборки и метод восстановления. Если появится регрессия, сначала восстановите совместимую доставку, затем диагностируйте пропущенное состояние. SIU использует такой рабочий процесс, чтобы стабилизировать критические пути до распространения влияния на клиентов.
Новый баннер, поток согласия, локаль, брейкпоинт или макет аккаунта требует регенерации и тестирования.
Верните шаблон и конфигурацию доставки к совместимой генерации; не изменяйте неизменяемые URL-адреса ассетов, на которые ссылаются старые документы.