Шесть мест, где прячется вес в окне первой отрисовки

Из первых частей цикла мы знаем главное: оценку PageSpeed тянет вниз не общий вес страницы, а то, что браузер успел запросить до первой отрисовки, — окно первой отрисовки. Скрипт из третьей части показывает, что именно туда попало. Остаётся понять, откуда оно там взялось.

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

#	Источник	Как выглядит в отчёте	Сколько было у нас
1	прелоад шрифтов	много Font в окне	2062 КБ, 40 файлов
2	видео-превью в карточках	Media в окне	706 КБ из 960
3	ленивые блоки, догруженные раньше времени	XHR/Fetch и картинки блоков ниже сгиба	1,2 МБ
4	картинки ниже сгиба без размеров	Image, которых нет на первом экране	от десятков КБ до мегабайта
5	блокирующий CSS	Stylesheet	24 КБ ≈ 0,17 с
6	соседние слайды слайдера	Image из слайдера первого экрана	335 ↔ 432 КБ, +0,4 с к LCP

1. Прелоад шрифтов

Самая частая и самая тяжёлая находка. Сборщик расставляет <link rel="preload"> на каждый шрифт из CSS, который считает критическим. А «критическим» он считает весь CSS, подключённый на странице синхронно, — не только первый экран. Одна строчка, подключившая семейство шрифтов ради одного начертания, превратилась в 40 прелоадов: 18 начертаний в двух форматах, 2062 КБ с высоким приоритетом.

Как проверить за секунду:

curl -s https://example.ru/ | grep -c 'as="font"'

Больше шести — повод разобраться. Лечение: прелоадить только начертания первого экрана и только в woff2, а сами шрифты сократить до нужных символов. Результат на каталоге: 40 файлов и 2062 КБ → 6 файлов и 143 КБ, LCP 12,5 → 2,3 с. Подробно — в части про шрифты.

2. Видео-превью в карточках

Карточки товаров с роликом при наведении — красиво, но у такого компонента часто свой механизм запуска: он видит карточку на экране и вызывает video.play() сразу, мимо всех отложенных загрузок. На каталоге это было 706 КБ из 960 КБ в окне — три четверти всего веса. Отсюда же автозапуск роликов «для всех» и фоновое видео первого экрана, которое уходило в сеть на 185-й миллисекунде при отрисовке на 283-й.

Лечение: никаких запросов видео до первой отрисовки — постер картинкой, ролик после. Подробно — в части про видео.

3. Ленивые блоки, догруженные раньше времени

Блоки ниже сгиба (отзывы, каталожные подборки, карты) часто грузятся отдельным запросом. У них обычно два пути загрузки: по приближению к экрану и фоновая догрузка «на всякий случай», чтобы быстрый посетитель не долистал до пустоты. Если отложить только первый путь, второй обгоняет отрисовку. Так у нас фоновая догрузка стартовала на 600 мс раньше отрисовки и принесла в окно 1,2 МБ: разметку блоков и все их картинки.

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

4. Картинки ниже сгиба без размеров

loading="lazy" обещает не грузить картинку, пока она далеко от экрана. Но если у картинки нет атрибутов width и height, при первом расчёте вёрстки её высота равна нулю, и всё, что ниже, «сжато» к первому экрану. Браузер решает, что картинка рядом, и качает её сразу. Та же история с картинками внутри скрытых элементов (display: none): меню, вкладки, фильтры. На одном сайте картинка в скрытом мобильном меню добавляла 27 КБ в окно на каждой странице.

Лечение: размеры у каждой картинки, у скрытых — подстановка адреса при раскрытии. Подробно — в двух частях про картинки.

5. Блокирующий CSS

Стили в <head> браузер обязан получить до отрисовки. Чаще всего их немного: на одном сайте три файла на 24 КБ стоили около 170 мс. Поэтому CSS проверяют последним — но не забывают: на странице, где всё остальное уже чисто, именно он отделяет 90 от 100. Тут есть свои приёмы, от разделения стилей по ширине экрана до встраивания критического CSS в страницу, — и свои подводные камни. Подробно — в части про CSS.

6. Соседние слайды слайдера

Слайдер на первом экране показывает одну картинку, но соседние слайды уже в вёрстке, и браузер часто грузит их сразу. Хуже того, их число может меняться от загрузки к загрузке: на одном и том же билде окно первой отрисовки прыгало между 335 и 432 КБ — это лишние 0,4 с к LCP в модели и, заодно, один из источников разброса оценки.

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

Как пользоваться списком

1. Запустите серию прогонов и скрипт разбора из третьей части.
2. Посмотрите разбивку окна по типам: Font, Media, Image, XHR, Stylesheet.
3. Начните с самого тяжёлого типа и найдите его источник в списке выше.
4. Посчитайте по формуле из второй части, сколько секунд он стоит, — и сверьте с фазами LCP.
5. Поправьте одно место, сделайте серию замеров, переходите к следующему.