Инлайн критического CSS убирает блокирующий запрос стилей и ускоряет первую отрисовку - но каждая страница везёт этот кусок CSS заново, тогда как внешний файл браузер скачал бы один раз и держал в кэше. У нас на сайте инлайн вместе с описанием шрифтов добавляет около 7 килобайт в сжатом виде на каждую страницу, HTML вырос с 23 до 31 килобайта. Разбираем, когда этот размен окупается, а когда работает против самого сайта.
В любой инструкции по скорости сайта инлайн критического CSS идёт отдельным пунктом: убрать блокирующий запрос, отрисовать первый экран без ожидания стилей. Мы так и сделали - получили честный прирост в PageSpeed. Но вторую половину истории обычно не пишут: CSS, который раньше жил в одном файле на весь сайт, теперь печатается заново в каждом HTML-документе. Для человека, который посмотрел одну страницу, это чистый выигрыш. Для того, кто читает статью за статьёй, это лишний вес на каждой загрузке.
Что печатается прямо в HTML
Инлайн - это не только правила первого экрана. Туда же ушли описания шрифтов (font-face) и предзагрузка двух начертаний: не объявишь шрифт в критическом блоке - браузер сначала прочитает файл стилей и только потом узнает, что шрифт вообще есть. Отдельно рассказывали про сам переезд на свои шрифты в статье про шрифты для сайта - там речь про экономию на весе файлов, а не про то, где эти описания в итоге лежат.
Суммарно блок вырос до 7 килобайт в сжатом виде. Это описания шрифтов, критические селекторы и два тега preload. Основной файл стилей при этом продолжает грузиться - просто неблокирующим способом, с запасным вариантом на случай отключённого JS. Убрать блокирующий запрос стоило того: он заметно двигает и FCP, и LCP, метрики разбирали подробно в статье про Core Web Vitals.
Арифметика размена: вес против глубины просмотра
Смысл сравнения прост: инлайн стоит фиксированный вес на каждой странице, а внешний файл стоит один раз за всю сессию - дальше он лежит в кэше браузера. Если умножить вес инлайна на среднее число страниц за визит, получится честная цена решения.
Возьмём наши 7 килобайт. Посетитель, который смотрит одну страницу и уходит, платит примерно столько же, сколько заплатил бы за одну закачку внешнего файла - инлайн даже немного впереди, потому что не тратит время на отдельное соединение. Посетитель, который смотрит пять страниц подряд, с инлайном грузит эти 7 килобайт CSS пять раз, суммарно 35 килобайт, а с внешним файлом - одну закачку в начале и почти ноль на остальных четырёх: файл уже в кэше. Чем больше страниц за визит, тем дороже инлайн и тем выгоднее внешний файл. Простая арифметика, только её обычно никто не считает.
Где смотреть свою глубину просмотра, а не решать на глаз
Прежде чем менять схему подключения стилей, стоит один раз открыть отчёт "Аудитория" в Яндекс.Метрике: там есть и глубина просмотра, и доля новых посетителей. Если у вас на сайте пока не настроены цели, у нас есть материал про настройку целей в Яндекс.Метрике - без целей часть отчётов всё равно работает, но собирать полную картину лучше вместе с ними.
Два числа решают почти всё. Средняя глубина просмотра меньше двух страниц за визит - инлайн почти не имеет обратной стороны, лишний вес заметит разве что каждый третий-четвёртый посетитель. Глубина выше трёх-четырёх страниц - счёт идёт на десятки лишних килобайт за сессию, и стоит присмотреться к внешнему файлу. Доля новых посетителей тоже важна: если 90% трафика - новые люди с рекламы, кэш браузера почти не успевает пригодиться, и инлайн там почти не проигрывает.
Когда инлайн выигрывает: лендинг и рекламный трафик
Лендинг под рекламную кампанию - хрестоматийный случай: человек приходит по объявлению, смотрит одну страницу, либо оставляет заявку, либо закрывает вкладку. Второго визита чаще всего не будет вовсе, а если будет, то через неделю или месяц, когда кэш браузера уже давно очищен. В этом сценарии инлайн работает без всякого проигрыша: за первую отрисовку не приходится платить повторными визитами. Тут спорить не о чем.
То же самое верно для любого трафика из рекламных кампаний, куда бы он ни вёл: холодный визит, малая глубина просмотра, решение принимается за один заход. Похожие сценарии разбирали в общем материале про ускорение сайта - инлайн там один из инструментов, но не универсальный.
Когда инлайн проигрывает: каталог, блог, кабинет
Каталог интернет-магазина, блог с несколькими статьями за визит, личный кабинет, куда человек заходит по нескольку раз в неделю, - всё это сценарии с высокой глубиной просмотра и постоянными посетителями. Каждая новая страница везёт с собой уже знакомый браузеру CSS заново, и суммарный трафик за сессию растёт линейно вместе с числом просмотренных страниц.
У нас в блоге читатель нередко открывает пять-шесть статей за один заход - переходит по внутренним ссылкам, изучает тему. Для такого посетителя инлайн - чистый перерасход: было бы честнее один раз скачать внешний файл и дальше брать стили из кэша. Мы сознательно выбрали инлайн, потому что PageSpeed и первый визит для нас сейчас важнее, но на сайте с другим профилем аудитории решение может быть обратным.
Промежуточные варианты между инлайном и обычным подключением
У полного инлайна и обычного блокирующего тега link есть промежуточные варианты - они снимают часть проблемы, не давая полного выигрыша ни одной из сторон.
Внешний файл критического CSS с предзагрузкой. Тот же слепок первого экрана выносится в отдельный маленький файл и подключается через rel=preload с высоким приоритетом. Первый визит почти не отличается от инлайна по скорости, а на повторных страницах браузер берёт файл из кэша. Плата - лишнее соединение на холодном визите, обычно 20-50 миллисекунд.
Разделение стилей по шаблонам. Вместо одного большого файла на весь сайт - несколько файлов поменьше под конкретные типы страниц: главная, карточка товара, статья блога. Человек, который смотрит только карточки товара, скачивает один файл и держит его в кэше для всех следующих карточек. Инлайн в таком случае вообще не нужен, если сами файлы небольшие.
CDN для статики. Раздача CSS и шрифтов через сеть доставки контента ускоряет соединение, но не отменяет сам вопрос "инлайн или нет" - это отдельное решение, разбирали его в статье про CDN для сайта.
Почему мы не стали ставить service worker ради кэша
Service worker умеет решить проблему радикальнее: закешировать критический CSS на стороне клиента при первом визите и на втором заходе отдавать его без сети вовсе, минуя даже обычный HTTP-кэш. Технически это работает, и на сайте с высокой глубиной просмотра дало бы больше, чем предзагрузка внешнего файла.
Мы не стали его ставить по двум причинам. Первая - сложность отладки: service worker кэширует агрессивно, и типичная ошибка новичка - показывать посетителю старую версию сайта после деплоя, потому что воркер не обновился. Вторая - выигрыш не окупает риск: аудитория студии и так смотрит по одной-две страницы за визит, разница между инлайном и внешним файлом там небольшая. Овчинка выделки не стоила.
Как посчитать размен для своего сайта
Проверка занимает вечер, если данные в Метрике уже собираются.
- Открыть отчёт "Аудитория" - "Глубина просмотра" за последний месяц и записать среднее число страниц за визит.
- Посмотреть долю новых посетителей: если она выше 70-80%, повторные визиты почти не влияют на общую картину.
- Замерить вес критического блока в сжатом виде через вкладку "Сеть" в инструментах разработчика, с включённым сжатием на сервере.
- Умножить вес блока на среднюю глубину просмотра и сравнить с одной закачкой внешнего файла плюс временем на лишнее соединение.
- Если разница за сессию выходит за пределы 15-20 килобайт - переходить на внешний файл с предзагрузкой или разделять стили по шаблонам.
- Пересчитывать раз в полгода: аудитория и её поведение меняются, а решение, принятое один раз, потом забывают пересмотреть.
Правило зависит от типа сайта, а не от совета в отчёте
PageSpeed и похожие инструменты меряют холодный первый визит, поэтому любая метрика будет хвалить инлайн сильнее, чем того заслуживает реальная аудитория сайта. У лендинга с рекламным трафиком и разовым визитом инлайн почти всегда прав. У каталога, блога с высокой глубиной просмотра и личного кабинета правильнее считать вес на сессию целиком, а не на одну загрузку.
Мы для себя выбрали инлайн осознанно и переплачиваем на части визитов - решение принято, зная цену, а не по умолчанию. Универсального ответа здесь нет: правильная схема зависит от того, что у вас за сайт, и у каждого проекта этот ответ выходит свой.
Если разбираетесь, какая схема подключения стилей подойдёт вашему проекту, - мы собираем корпоративные сайты и считаем такие вещи заранее, а не постфактум. Как это устроено, можно посмотреть на странице корпоративных сайтов.
