PageSpeed не меряет скорость: как каталог поднялся с 69 до 100

Каталог сельхозтехники на kentavr.company получал в PageSpeed 69 баллов. При этом в браузере страница рисовалась за 2,4 секунды, а отчёт уверял, что крупнейший элемент появляется через 12,8. Разница в пять раз — не погрешность. Это подсказка, куда смотреть.

Что на самом деле считает PageSpeed

PageSpeed не измеряет время загрузки — он его моделирует. Chrome в прогоне работает без ограничений, а потом модуль lantern пересчитывает записанную трассу на медленный мобильный интернет 1,6 Мбит/с. Правило пересчёта простое:

Всё, что страница успела запросить до первой отрисовки, считается критическим путём LCP.

правило, по которому PageSpeed пересчитывает трассу

Три следствия, которые ломают интуицию

1. Общий вес страницы не важен. Важно только то, что запрошено до первой отрисовки.
2. Вес ниже сгиба почти бесплатен — если его не начали качать раньше времени. Картинки, постеры и видео нижних блоков после отрисовки оценку почти не трогают.
3. Лишняя секунда до отрисовки катастрофична. Каталог рисовался 2,4 с, и за это время уходило 135 запросов из 137 — 3615 КБ. Все они попадали в критический путь, отсюда модельные 12,8 с.

Как проверить гипотезу за минуту

Модель считает почти арифметически, поэтому подозреваемого можно проверить на салфетке:

вес в окне, КБ × 8 ÷ 1600 = секунды, которые модель добавит к LCP

Что попало в окно	Вес	Расчёт	В отчёте PageSpeed
шрифты с прелоадом	2062 КБ	≈ 10,3 с	«задержка отрисовки элемента» 10 523 мс

Если расчёт сходится с отчётом — причина найдена. Если не сходится — ищете не там. Сам отчёт воспроизводится локально одной командой, и это надёжнее, чем гонять сайт через веб-версию PageSpeed:

npx lighthouse@12 https://example.ru/ --only-categories=performance \
  --chrome-flags="--headless=new" --output=json --output-path=lh.json

В JSON есть всё нужное: наблюдаемые FCP и LCP, список запросов со временем старта. Отфильтровали запросы до наблюдаемой отрисовки, сложили вес по типам — получили список подозреваемых.

Где искать вес — в порядке находок

1. Прелоад шрифтов. Сборка прелоадит каждый @font-face из синхронного CSS. Одно семейство, подключённое ради одного начертания, превратилось в 40 файлов на 2 МБ с высоким приоритетом. Лечится настоящим сабсетом шрифта и прелоадом только того, что нужно первому экрану.
2. Превью-видео в карточках. Видео запускалось своим наблюдателем, мимо всех отложенных загрузок, — 706 КБ из 960 в окне каталога.
3. Асинхронные блоки. У них два пути загрузки: по приближению к экрану и фоновая догрузка. Закрыть «до отрисовки» нужно оба, иначе догрузка обгоняет отрисовку и тащит в окно мегабайты.
4. Картинки без width и height. Без размеров браузер считает их «рядом с экраном» и качает заранее, несмотря на loading="lazy".
5. Блокирующий CSS. Три файла на 24 КБ — около 170 мс. Смотреть в последнюю очередь.

Что не помогает

Результат

Каталог — 69 → 100, товарная страница — 77–83 → 96–97 на боевом сайте. Контент от проверки не прятали: всё, что видит посетитель, видит и PageSpeed, и поисковый робот. Просто то, что не нужно первому экрану, теперь загружается после первой отрисовки.

А можно просто спрятать тяжёлое от PageSpeed?

Раньше проверку узнавали по маркеру Chrome-Lighthouse в адресе браузера, но измеряющий проход PageSpeed теперь ходит без него. И прятать контент вредно: то, что скрыто от проверки, легко оказывается скрыто и от поискового робота.

Почему локальный Lighthouse, а не сайт PageSpeed?

Локальный прогон даёт ту же оценку (69 против 69), но вместе с полным JSON: видно, какие запросы и в какой момент ушли. По веб-версии можно только гадать.