Формула на салфетке: проверить гипотезу о PageSpeed за минуту

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

Формула

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

Откуда числа: килобайты умножаем на 8 — получаем килобиты; делим на 1600 — скорость сети в модели, 1,6 Мбит/с. Получается время, за которое этот вес «скачался» бы на эталонном медленном телефоне. Модель так и делает: всё, что запрошено до отрисовки, проходит через эту линию по очереди, и LCP не может наступить раньше, чем она освободится.

Проверка на живом примере

Каталог получал 69 баллов, LCP в отчёте — 12,8 секунды. В окне первой отрисовки нашлись шрифты: 2062 КБ. Считаем:

2062 × 8 ÷ 1600 ≈ 10,3 с

А в отчёте PageSpeed, в разбивке LCP, стоит «Задержка при отрисовке элемента — 10 523 мс». Совпадение почти до десятых: 82 % всего LCP — это одни шрифты. Гипотеза подтверждена до того, как мы тронули хоть одну строчку кода.

Если расчёт сходится с отчётом — причина найдена. Если не сходится — ищите не там.

Шпаргалка: сколько стоит в модели то, что обычно попадает в окно

Что попало в окно	Вес	Модель добавит к LCP
шрифты: всё семейство с прелоадом	2062 КБ	≈ 10,3 с
видео-превью в карточках каталога	706 КБ	≈ 3,5 с
картинка скрытого мобильного меню	27 КБ	≈ 0,14 с — на каждой странице
блокирующий CSS, три файла	24 КБ	≈ 0,12 с + круги запросов (в замере ≈ 0,17 с)

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

Когда формула не сходится

Формула считает только сеть. Если модельный LCP большой, а веса в окне мало — задержка сидит в другом месте. Три частых случая:

1. Элемент загрузился, но спрятан. Анимация появления держит крупнейший элемент под visibility: hidden или opacity: 0. На одном сайте картинка первого экрана грузилась за 180 мс, а отчёт показывал «задержку отрисовки» 2040 мс — ровно длину анимации.
2. Страница долго не рисуется по вине скриптов. Код, выполняемый до отрисовки (например, инициализация слайдеров в defer), держит белый экран — и за это время в окно успевает уйти всё подряд.
3. Длинная цепочка запросов. Документ → CSS → шрифт, который браузер находит только внутри CSS: каждый шаг — отдельный круг задержки 150 мс в модели, даже если файлы лёгкие.

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

Как получить «вес в окне»

В веб-версии PageSpeed удобной суммы нет. Её даёт JSON-отчёт Lighthouse: список всех запросов со временем старта и наблюдаемое время отрисовки. Отфильтровать запросы, ушедшие до отрисовки, сложить вес — пять строк кода. Как запустить Lighthouse у себя и написать этот фильтр — в следующей, третьей части цикла.

Почему 1600, если в Lighthouse указано 1638,4 кбит/с?

Для прикидки разница в 2 % несущественна, а 1600 проще держать в голове. Точность формулы и так ограничена: модель учитывает ещё задержку сети и параллельность запросов. Нам важен порядок величины — секунды это или доли секунды.

А сжатие gzip/brotli?

Считайте переданный вес (transferSize в отчёте), а не размер файла на диске. Шрифты woff2 и картинки уже сжаты, поэтому для них разницы почти нет; для CSS и JS — есть, и заметная.