Страница каталога открывается в браузере за 2,4 секунды. PageSpeed по той же странице пишет: «Отрисовка самого крупного контента — 12,8 с» и ставит 69 баллов. Ошибки нет: просто эти две цифры отвечают на разные вопросы. Первая — сколько ждал человек. Вторая — сколько, по расчёту PageSpeed, ждал бы человек с медленным телефоном и плохим интернетом, если бы страница грузилась так, как она устроена.

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

Что происходит, когда вы нажимаете «Анализировать»

  1. Страница загружается по-настоящему. На сервере Google запускается Chrome и открывает ваш адрес — быстро, без искусственных ограничений. По дороге записывается трасса: какой файл когда запрошен, когда пришёл, что делал процессор, когда что появилось на экране.
  2. Трасса пересчитывается на «плохие» условия. Модуль Lighthouse под названием lantern берёт записанную цепочку запросов и вычисляет, сколько бы всё это заняло на эмулированном телефоне в медленной сети.
  3. Из пересчитанных метрик складывается оценка. Больше всего весят время до появления крупнейшего элемента (LCP), блокировка главного потока (TBT) и скорость заполнения экрана (Speed Index).

Условия эмуляции для мобильной проверки фиксированные:

ПараметрЗначение в модели
Устройствотелефон среднего класса (Moto G Power), плотность экрана 1,75
Сеть1,6 Мбит/с на загрузку, задержка 150 мс
Процессорв 4 раза медленнее, чем у машины, где идёт проверка
профиль мобильной проверки Lighthouse

Важно. Сеть 1,6 Мбит/с — это не то, что «намерил» Google у ваших посетителей. Это одинаковая для всех сайтов линейка, по которой их сравнивают. Даже если ваш сервер отвечает за 30 мс, а у посетителей быстрый интернет, оценка считается по этой линейке.

Две цифры в одном отчёте

Отчёт хранит обе версии метрик — пересчитанную и наблюдаемую. В веб-версии PageSpeed видна только первая, но в JSON-отчёте Lighthouse они лежат рядом: largestContentfulPaint (модель) и observedLargestContentfulPaint (то, что реально произошло при загрузке).

МетрикаНаблюдаемаяВ отчёте (модель)
Отрисовка крупнейшего элемента2,4 с12,8 с
Оценка—69
страница каталога: одна загрузка, два ответа

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

Главное правило модели

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

правило пересчёта lantern

Модель не знает, какие файлы на самом деле нужны первому экрану. Она видит только порядок: что было запрошено раньше, чем страница что-то нарисовала. Всё это она считает обязательным и «прокачивает» через линию 1,6 Мбит/с. Отсюда три вывода, которые идут против интуиции.

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

1. Общий вес страницы не важен

Главная страница одного из наших сайтов весит 5,5 МБ и получает 98–100. Она рисуется быстро, и почти весь этот вес запрашивается уже после первой отрисовки, так что в расчёт модели не попадает. Советы «облегчите страницу» в такой ситуации бьют мимо.

2. Вес ниже сгиба почти бесплатен

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

3. Лишняя секунда до отрисовки — катастрофа

Каталог из начала статьи рисовался 2,4 секунды. За это время страница успела запросить 135 файлов из 137 — 3615 КБ. Всё это модель посчитала критическим путём. Чем дольше страница не рисуется, тем больше запросов успевает уйти и тем хуже модельный LCP — эффект нарастает сам на себя.

Что из этого следует для оптимизации

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

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

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

Мифы, которые мешают

«Оценка показывает, как быстро сайт открывается у моих посетителей»

Нет. Оценка — расчёт для одного эталонного медленного телефона. Что видят реальные посетители, PageSpeed показывает отдельно, в блоке данных о реальных пользователях (он есть, если у сайта достаточно трафика в Chrome). Эти данные и оценка могут сильно расходиться — в обе стороны.

«Нужно уменьшить число запросов»

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

«Поставлю CDN / быстрый хостинг — оценка вырастет»

Быстрый ответ сервера помогает, но модель всё равно пересчитывает загрузку на 1,6 Мбит/с. Если в окне первой отрисовки 2 МБ шрифтов, они «скачиваются» в модели за 10 секунд на любом сервере.

«Оценка плавает — значит, PageSpeed сломан»

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

Что дальше в цикле

  • Часть 2. Формула, которой модель проверяется за минуту: сколько секунд к LCP добавит каждый килобайт в окне первой отрисовки.
  • Часть 3. Lighthouse у себя: как воспроизвести оценку PageSpeed и разобрать отчёт до конкретных файлов.
  • Часть 4. Почему один прогон ничего не доказывает и как мерить так, чтобы не обмануть себя.

Не понимаете, откуда у сайта низкая оценка?

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

· полезно?
АЧ
Алексей Чикун веб-разработчик, команда TRIOHEAD

Делаю сайты и сервисы целиком: от вёрстки до сервера. Пишу о том, что проверил на своих проектах.

Комментарии

// загружаю комментарии…

Комментарии публикуются после проверки. Ссылки и HTML не принимаются.