Как CSS и JavaScript замедляют сайт: критические стили, шрифты и сторонние скрипты

Часть 5 из 6 · Серия «Скорость сайта без магии»

В четвёртой части мы разобрались с изображениями. Но бывает так: картинки подготовлены идеально, а белый экран всё равно держится дольше, чем хочется.

Причина в том, что браузер вообще не начинает рисовать страницу, пока не разберётся со стилями. А когда наконец нарисовал — оказывается занят выполнением скриптов и не отвечает на нажатия.

Это вторая половина веса страницы: CSS, шрифты, свой JavaScript и чужие скрипты. Здесь легче всего сломать сайт неаккуратной оптимизацией, поэтому разбираться будем по порядку.

Почему стили задерживают первый экран

Браузер получил HTML и увидел в нём подключённые таблицы стилей. Рисовать страницу без них он не станет: иначе посетитель на секунду увидит нечто несвёрстанное, а потом всё прыгнет на свои места.

Поэтому CSS блокирует отрисовку — и это нормальное, полезное поведение. Проблема начинается, когда стилей становится слишком много.

Типичный сайт, живущий несколько лет, подключает стили из трёх источников одновременно:

тема оформления      → свой набор
десяток плагинов     → каждый свой файл
конструктор страниц  → ещё один набор

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

Оптимизация CSS: что действительно помогает

Порядок работ здесь противоположен интуитивному. Хочется начать с минификации — но она даёт меньше всего.

1. Убрать то, что не подключается на этой странице. Стили формы обратной связи не нужны в карточке товара, а набор конструктора — на странице, собранной без него. Многие плагины умеют ограничивать свою загрузку конкретными страницами.

2. Сократить количество запросов. Десять маленьких файлов дороже одного среднего: каждый — отдельное обращение к серверу. Объединение стилей в один бандл делают сборщики и плагины оптимизации.

3. Минифицировать. Убрать пробелы и переносы. Полезно, но это последние проценты, а не первые.

Отдельно про соблазн, о котором мы предупреждали ещё в первой части: не удаляйте всё, что отчёт назвал неиспользуемым. Лабораторный запуск видит один маршрут. Стиль может не понадобиться на первом экране, но быть нужным после открытия меню, модального окна или формы. «Не использовалось во время теста» — не то же самое, что «не используется на сайте».

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

Идея приёма: выделить те стили, без которых нельзя нарисовать первый экран, вставить их прямо в HTML, а всё остальное загрузить асинхронно — так, чтобы это уже не блокировало отрисовку.

Было:  HTML → ждём весь CSS (200 КБ) → рисуем
Стало: HTML + критические стили внутри → рисуем сразу
       остальной CSS подгружается параллельно

Выигрыш бывает ощутимым, особенно на медленном соединении. Но у приёма есть цена, о которой обычно молчат:

• критический CSS нужно пересобирать при каждом изменении вёрстки, иначе он устаревает и первый экран начинает выглядеть сломанным;
• у разных шаблонов страниц первый экран разный, значит наборов нужно несколько;
• если ошибиться с составом, посетитель на мгновение увидит «поехавшую» вёрстку.

Поэтому критический CSS — инструмент для сайтов, где сборка автоматизирована. Для небольшого сайта на готовой теме честнее сначала выкинуть лишние наборы стилей: эффект сопоставимый, а рисков почти нет.

Шрифты: почему текст мигает

Шрифт — тоже ресурс, и до его загрузки браузеру нужно решить, что показывать вместо текста.

Вариантов ровно два: не показывать ничего или показать запасным системным шрифтом, а потом переключиться. Первое выглядит как пустое место, второе — как скачок текста. Управляет этим свойство font-display.

@font-face {
  font-family: "MyFont";
  src: url("/fonts/myfont.woff2") format("woff2");
  font-display: swap;
}

По документации MDN, значение swap даёт крайне короткий период невидимого текста и затем бесконечно долго разрешает показывать запасной шрифт — то есть текст появляется сразу и переключается на ваш, когда тот загрузится. Значение block держит текст невидимым чуть дольше, ожидая «правильный» шрифт. Точные длительности этих периодов зависят от браузера и в стандарте числами не заданы.

Для основного текста swap обычно правильный выбор: читать сразу важнее, чем читать сразу в фирменной гарнитуре.

Нюанс, на котором ошибаются почти все

А вот для иконочных шрифтов совет «поставьте swap» вредный, и вот почему.

Иконочные наборы вроде FontAwesome размещают свои глифы в приватной зоне Unicode. У системного шрифта в этой зоне глифов нет. Поэтому swap показывает не «временные системные иконки», а пустые квадраты — так называемые тофу. Посетитель видит ряды прямоугольников, пока не догрузится шрифт.

Правильное значение для иконочного шрифта — block (современные версии FontAwesome ставят его сами) либо отказ от иконочного шрифта в пользу встроенного SVG.

И здесь же — честная неприятность. Аудит Lighthouse засчитывает только значения swap, fallback и optional. Это значит, что грамотное решение — оставить иконкам block или перейти на SVG — предупреждение из отчёта не уберёт. Балл останется с замечанием, а сайт будет работать правильно.

Такие развилки в серии встречаются не первый раз, и ответ на них один: мы оптимизируем сайт для посетителя, а не отчёт для себя.

Что ещё стоит проверить по шрифтам

• сколько начертаний подключено: часто в вёрстке используются два, а грузятся шесть, включая курсивы, которых нет в макете;
• формат: woff2 компактнее предшественников и понимается всеми актуальными браузерами;
• набор символов: если сайт русскоязычный, полный многоязычный шрифт — лишний вес, помогает подмножество;
• откуда шрифт берётся: собственный сервер или внешний сервис — это ещё одно соединение перед отрисовкой.

Оптимизация шрифтов на сайте почти всегда сводится к простому «уберите лишнее», а не к тонким настройкам.

JavaScript: страница видна, но не работает

Со скриптами история другая. Они реже мешают увидеть страницу и чаще мешают ею пользоваться — это та самая метрика INP из третьей части.

Браузеру нужно скачать файл, разобрать его и выполнить. Всё это делает тот же поток, который отвечает на нажатия. Пока он занят, интерфейс не реагирует — на недорогом телефоне это секунды.

Отложенная загрузка JavaScript

У тега скрипта есть два атрибута, и разница между ними важнее, чем кажется.

<script src="app.js" defer></script>
<script src="metrika.js" async></script>

• defer — скачивать параллельно с разбором HTML, выполнить после того, как разбор закончен, строго в порядке подключения. Подходит скриптам, которым нужна готовая страница, и это безопасный выбор по умолчанию.
• async — скачивать параллельно, но выполнить сразу по готовности, не соблюдая порядок. Годится независимым скриптам вроде счётчика; для кода, зависящего от библиотеки, опасен: библиотека может не успеть.

Модульные скрипты (type="module") откладываются сами, добавлять им defer не нужно. И оба атрибута не действуют на код, написанный прямо в HTML: у него нет файла, который можно было бы скачать заранее.

Что откладывать нельзя: код, от которого зависит вид первого экрана. Если слайдер, меню или шрифтовой переключатель собираются скриптом, отложенная загрузка JavaScript превратится в пустое место или прыжок вёрстки.

Что ещё уменьшает вес

Оптимизация JavaScript не сводится к атрибутам загрузки. Стоит проверить ещё три вещи:

• не грузить на всех страницах то, что нужно одной: карта на контактах, галерея в карточке товара, калькулятор на посадочной;
• проверить, не подключены ли две библиотеки, делающие одно и то же, — обычное дело после нескольких лет доработок;
• посмотреть на неиспользуемый код с той же осторожностью, что и на стили: тест видит один сценарий.

Сторонние скрипты на сайте

Отдельная категория, потому что вы их не писали и не контролируете.

Чат поддержки, системы аналитики, пиксели рекламных сетей, виджеты отзывов, карты, баннер согласия на cookie, формы подписки — каждый ставится в один клик, и почти каждый тянет собственный набор файлов с чужого домена.

Три свойства делают их особенно дорогими:

1. Вы не влияете на их вес. Обновился виджет — изменился и вес, без вашего участия.
2. Они живут дольше, чем нужны. Пиксель кампании, закончившейся два года назад, продолжает исправно выполняться.
3. Они грузятся с чужих серверов. Медленный ответ чужого домена становится вашей задержкой.

Как измерить их вклад, не гадая:

1. сохранить отчёт «до»
2. отключить ОДИН самый тяжёлый сторонний скрипт на тестовой странице
3. повторить замер
4. вернуть на место и повторить со следующим

Дальше — обычное продуктовое решение. Если виджет приносит две заявки в месяц, а стоит всем посетителям заметной задержки, вопрос уже не технический.

Ещё один приём — не грузить тяжёлые виджеты сразу. Чат можно поднимать по нажатию на кнопку, карту — при прокрутке до неё, видео — по клику на превью. Функциональность сохраняется, а первый экран перестаёт за них платить.

Отдельно про заставки и прелоадеры

Иногда сайт показывает анимацию загрузки поверх страницы, пока «всё не подготовится». Выглядит аккуратно, а по факту это добровольная задержка: содержимое уже могло бы отображаться, но его прячут.

Честное решение — убрать заставку и позволить странице появляться постепенно. Попытки «ускорить» её, перенеся снятие на более раннее событие, лечат симптом: посетитель по-прежнему смотрит на анимацию вместо товара.

Чек-лист

[ ] известно, сколько файлов стилей грузит страница и откуда они
[ ] отключены наборы стилей, не нужные на этой странице
[ ] число начертаний шрифта соответствует вёрстке
[ ] у текстового шрифта font-display: swap
[ ] у иконочного шрифта НЕ swap
[ ] скриптам проставлены defer или async осознанно
[ ] перечислены все сторонние скрипты и известно, зачем каждый
[ ] вклад самого тяжёлого стороннего скрипта измерен отключением
[ ] тяжёлые виджеты грузятся по действию, а не сразу
[ ] на странице нет заставки, прячущей готовое содержимое

Проверка в Turbo

Turbo в разборе показывает конкретные файлы, стоящие за проблемой, и отмечает, какие из них свои, а какие сторонние. Это важно именно здесь: советы для своих и чужих ресурсов принципиально разные — свой файл можно переписать, чужой остаётся только отложить или убрать.

Рекомендации даются с учётом определённой платформы сайта, а у каждой карточки есть пометка, правится это в админке или нужен разработчик. Отчёт по ссылке удобно передать тому, кто будет делать работу.

Короткие ответы на частые вопросы

С чего начать оптимизацию CSS-кода?

С инвентаризации: посмотрите, сколько файлов стилей грузит страница и какие из них добавлены плагинами и конструктором. Первый и самый крупный выигрыш — отключить наборы, которые на этой странице не используются. Объединение файлов и минификация дают меньше, а критический CSS имеет смысл, когда сборка автоматизирована.

Что такое критический CSS и нужен ли он моему сайту?

Это стили, необходимые для отрисовки первого экрана: их вставляют прямо в HTML, а остальное подгружают асинхронно, чтобы не блокировать отрисовку. Приём эффективный, но требует пересборки при каждом изменении вёрстки, иначе первый экран начнёт выглядеть сломанным. Небольшому сайту на готовой теме обычно выгоднее сначала убрать лишние стили.

Что даёт оптимизация JavaScript и что можно отложить?

Скрипты занимают тот же поток, который отвечает на нажатия, поэтому их избыток проявляется как «страница видна, но не работает». Откладывать через defer или async можно всё, от чего не зависит вид первого экрана: аналитику, чаты, виджеты, дополнительные библиотеки. Нельзя откладывать код, который строит сам первый экран.

Как понять, сколько стоят сторонние скрипты на сайте?

Измерением, а не оценкой: сохраните отчёт, отключите на тестовой странице один самый тяжёлый сторонний скрипт, повторите замер и сравните. Так вы получите цену конкретного виджета в секундах и сможете взвесить её против пользы. Часто выясняется, что сервисом давно никто не пользуется.

Нужна ли оптимизация шрифтов на сайте?

Нужна, если начертаний подключено больше, чем реально используется в вёрстке, — это самый частый случай. Проверьте формат woff2, ограничьте набор символов нужными языками и задайте текстовому шрифту font-display: swap. Иконочным шрифтам swap противопоказан: вместо иконок посетитель увидит пустые квадраты.

Что дальше

Мы прошли всё, что происходит в браузере: изображения, стили, шрифты и скрипты. Остался участок, с которого всё начинается, — сервер.

В шестой, заключительной части разберём время ответа сервера: что такое TTFB, почему страница может «думать» ещё до первого байта, как здесь работают кэширование, редиректы, база данных и сжатие — и когда медленный сайт действительно начинается с хостинга.

Посмотреть, какие стили и скрипты задерживают вашу страницу, можно бесплатно на turbo.siteko.net.