PageSpeed Insights — что показывает отчёт и что с этим делать

Короткий ответ: на одной странице PSI сведены два разных измерения вашего сайта. Сверху — опыт реальных посетителей за последние 28 дней. Снизу — одна симуляция загрузки на дешёвом телефоне, сделанная только что. Цветная цифра, на которую все смотрят, относится только ко второму. И половина того, что PSI меряет, вообще не про скорость.

Ошибочный вывод из этого отчёта делают обычно не из-за незнания метрик. Просто читают не ту половину.

Две половины отчёта, которые меряют разное

Документация описывает PSI как отчёт об опыте пользователя страницы на мобильных и десктопных устройствах, с рекомендациями по улучшению. Слово «опыт» здесь не для красоты. CLS — это скачки макета, INP — задержка отклика на клики. Это не секундомеры.

Верхний блок — полевые данные. Показатели реальных пользователей за предыдущее 28-дневное окно сбора: FCP, INP, LCP и CLS. Эти числа не зависят от того, когда вы нажали «Анализировать». Их собрали до вас.

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

Google сам разводит два блока по назначению. Лабораторные данные полезны для отладки, потому что собраны в контролируемой среде, но могут не поймать реальные узкие места. Полевые фиксируют настоящий опыт, зато имеют более узкий набор метрик. Для владельца это означает простой порядок: решение «есть ли проблема» принимают по верхнему блоку, а нижний берут, чтобы понять, где копать. Пороги и значения самих метрик мы разобрали отдельно — Core Web Vitals простыми словами.

Почему 75-й перцентиль, а не «средний пользователь»

Над столбиками распределения PSI показывает 75-й перцентиль по каждой метрике. Это не среднее и не медиана.

Перевод на человеческий: из четырёх загрузок берут третью с конца, почти самую худшую. Число, которое вы видите в полевом LCP, означает, что 75% посетителей увидели контент быстрее, а остальные ждали дольше. Google советует мерить именно этот порог, отдельно для мобильных и десктопных, чтобы рекомендованное значение выполнялось для большинства пользователей.

Отсюда две вещи, которые стоит принять сразу. Первая: ваш собственный опыт ничего не доказывает. Вы открываете сайт с хорошего ноутбука в офисном Wi-Fi и попадаете куда-то в первую четверть распределения. Вторая: улучшения для «большинства» балл не сдвинут. Его двигает самый медленный сегмент. В отчётах клиентов это чаще всего мобильный трафик со старых Android и сетей за пределами крупных городов.

Что делать, когда полевых данных нет вообще

Вполне типичная картина: верхнего блока нет, а PSI пишет что-то про недостаточность данных. Это не поломка.

Полевые данные поставляет CrUX, и страница попадает в его набор при двух условиях. Первое — страница публично доступна для индексации по тем же критериям, что и у поисковых систем. Второе — достаточная популярность, то есть минимальное количество посетителей. Страницы и сайты, которые не дотягивают до порога, в набор просто не входят.

Когда по конкретному URL данных не хватает, PSI переходит на уровень всего сайта (origin), который охватывает опыт на всех страницах вместе. Поэтому карточка с данными может быть, но относиться она будет не к той странице, которую вы проверяли. Здесь ошибаются чаще всего: празднуют зелёный LCP на новой посадочной, а это средняя температура по домену.

Та же логика работает в отчёте Core Web Vitals в Search Console. URL там группируются по схожему опыту, группа должна набрать минимальный объём данных, чтобы появиться в отчёте, а если его нет, создаётся группа более высокого уровня, по сайту. Ту же механику «читать отчёт Google и понимать, чего в нём нет» мы разбирали на примере platform properties в Search Console.

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

Из чего складывается балл и почему он скачет

Балл Performance — это взвешенное среднее оценок метрик. Не сумма советов и не количество зелёных галочек.

Таблица весов, которую документация Google подаёт как актуальную, выглядит так: Total Blocking Time — 30%, LCP — 25%, CLS — 25%, First Contentful Paint — 10%, Speed Index — 10%. Одна оговорка, и она честная: страница с этой таблицей подписана как Lighthouse 10, тогда как актуальный релиз инструмента на день проверки — v13.4.1. Документация может отставать от релиза, поэтому веса читайте как ориентир порядка величин, а не как гарантированное на сегодня распределение. Для сравнения, в Lighthouse 8 CLS весил 15%, а в наборе ещё был Time to Interactive. Шкалу пересматривают.

Цвета простые: 0–49 красный, 50–89 оранжевый, 90–100 зелёный.

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

И отдельно о цели. «Идеальные» 100 баллов чрезвычайно трудно получить, и на них не рассчитывают. Это формулировка самого Google, а не наша поблажка. Цель не в цифре, а в том, чтобы полевые метрики держались в зелёных границах для 75% ваших посетителей.

Самая дорогая ошибка читателя отчёта

Под баллом идут два списка, Opportunities и Diagnostics. Выглядят как план работ, читаются как план работ, и именно на них обычно бросают бюджет.

Документация Lighthouse говорит прямо: на балл влияют только метрики, а не результаты Opportunities или Diagnostics. Там же сделано уточнение — работа над этими пунктами, скорее всего, улучшит значения метрик, так что связь есть, но косвенная.

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

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

Почему лаборатория и поле законно расходятся

Расхождение между двумя блоками не является дефектом инструмента. У него есть три конкретные причины.

LCP. В лаборатории другой размер экрана, значит, в видимой области оказываются другие элементы. «Самым большим» становится не тот, что у реального пользователя.

INP. В лабораторном блоке его нет вообще. Тест принципиально не может предугадать, когда именно пользователь решит кликнуть, а INP оценивает задержку всех кликов, тапов и нажатий клавиш за весь визит. Прокрутку, наведение и масштабирование он не считает.

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

Поэтому правильная реакция на расхождение — не «какому числу верить», а «что именно оно мне говорит». Поле говорит, что происходит у пользователей. Лаборатория говорит, что сломано в коде.

Что отчёт решает в поиске, а что нет

Core Web Vitals Google использует в своих системах ранжирования. Это официальная позиция. Но рядом с ней стоят три уточнения, которые убирают лишние ожидания.

Единого сигнала page experience не существует: базовые системы ранжирования смотрят на набор сигналов, согласующихся с общим опытом страницы. Релевантный контент Google показывает даже тогда, когда опыт страницы посредственный. А другие аспекты page experience вне Core Web Vitals прямо не поднимают сайт в выдаче, хотя делают его приятнее в использовании.

Ещё одна деталь для тех, кто читает старые материалы и не понимает, почему в отчёте нет FID. Эта метрика больше не входит в Core Web Vitals и выведена из программы, её заменил INP 12 марта 2024 года. Если статья или подрядчик до сих пор оперируют FID, они описывают инструмент прошлого.

Короткий чек-лист чтения отчёта

1. Сначала верхний блок. Нет полевых данных — не паникуйте, проверьте, не origin-уровень ли это вместо вашего URL.
2. Смотрите на 75-й перцентиль и отдельно на мобильную вкладку. Мобильная почти всегда хуже, и именно она важна.
3. Балл — индикатор, а не цель. Один прогон ничего не доказывает, сравнивайте серии.
4. Списки Opportunities и Diagnostics читайте после того, как определили проблемную метрику, а не вместо этого.
5. Проверяйте не главную, а страницы, которые приносят деньги: карточки товаров, посадочные, корзину.

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

Частые вопросы