Core Web Vitals: как разобраться в LCP, INP и CLS и выбрать исправления

Три показателя описывают разные неудобства

Страница может быстро появиться на экране и всё же раздражать: меню открывается с задержкой, а кнопка уезжает из-под пальца, когда загружается баннер. Core Web Vitals помогают разделить эти проблемы. В отчёте нужно найти показатель, который ухудшился, определить затронутые страницы и воспроизвести соответствующее поведение. После этого можно выбирать исправление.

В набор входят LCP, INP и CLS. Первый показывает, когда появляется крупнейший видимый элемент содержимого. Второй характеризует задержку реакции на действия посетителя. Третий оценивает неожиданные сдвиги элементов. Быстрая загрузка изображения не устраняет тяжёлый обработчик кнопки, а ускорение JavaScript не резервирует место под баннер.

Пороги и состав набора приведены в документации Web Vitals. CLS — безразмерная величина, поэтому к нему нельзя приписывать секунды или проценты. Категория качества в отчёте помогает оценить проблему, но не заменяет просмотр страницы.

Ниже разбираем чтение метрик и постановку задач по ним. Общий порядок проверки сервера, ресурсов и кеширования описан отдельно в статье о скорости загрузки сайта.

Сначала выясните, какие данные перед вами

В PageSpeed Insights соседствуют два вида результатов. Полевые данные приходят из Chrome User Experience Report, или CrUX: это наблюдения реальных посещений. Лабораторная часть создаётся отдельным запуском Lighthouse. Она показывает поведение страницы в заданных условиях теста.

Полевой отчёт PSI охватывает предшествующие 28 дней. Если наблюдений для конкретного адреса мало, сервис может показать сводку по всему origin — сочетанию протокола, домена и порта. Если данных не хватает и там, полевого результата не будет. Эти условия описаны в справке PageSpeed Insights. Проверьте подпись над результатами: данные отдельного URL и всего сайта относятся к разному набору посещений.

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

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

Для рабочей таблицы запишите URL, тип страницы, устройство, источник данных, период и три значения. Укажите, относятся ли данные к одному URL или всему сайту. Отдельно сохраните дату лабораторного запуска. Через неделю по этим сведениям будет понятно, сравниваете ли вы одну страницу в сопоставимых условиях.

Как читать 75-й процентиль и итоговую оценку

В полевом отчёте используется 75-й процентиль, или p75. Его представление показано в руководстве Chrome по данным CrUX в PSI. Это граница, ниже которой или на которой находится примерно 75% измеренных значений. Представьте учебную выборку из ста посещений, упорядоченную от лучших результатов к худшим: p75 будет около семьдесят пятого значения. Среднее арифметическое здесь не используется.

Если LCP на p75 равен 2,4 секунды, большая часть наблюдений укладывается в этот срок, но остальные посещения могут быть заметно медленнее. Поэтому рядом с p75 полезно смотреть распределение по категориям качества. Зелёный показатель не означает одинаково хороший опыт у каждого клиента.

Мобильные и настольные результаты рассматривают отдельно. Смешивание их в одну среднюю цифру способно скрыть задержки на телефонах. В пределах одной группы также проверяйте шаблоны: посетители статьи и пользователи каталога выполняют разные действия, даже если открывают один домен.

При достаточном наборе данных оценка Core Web Vitals в PSI считается пройденной, когда p75 всех трёх метрик находится в хорошей зоне. В справке PSI оговорено исключение: если наблюдений INP недостаточно, оценка может опираться на хорошие LCP и CLS. Если не хватает LCP или CLS, оценить набор нельзя. Отсутствие цифры нужно описывать как ограничение данных, а не как нулевую задержку.

LCP: найдите элемент и разложите ожидание на этапы

Начните с определения LCP-элемента в записи загрузки. На одной странице им окажется фотография, на другой — крупный текстовый блок. При другой ширине экрана элемент может измениться. Советы для баннера бессмысленны, если измеряется заголовок, который ждёт шрифт или оформление.

Для LCP с отдельным ресурсом, например изображением, удобно выделить четыре части: ожидание первого байта HTML, задержку до начала запроса ресурса, его загрузку и ожидание отрисовки. Такое разложение приведено в руководстве по оптимизации LCP. Сначала установите, какая часть велика в вашей записи.

Если поздно приходит HTML, разработчик проверяет путь до сервера и подготовку ответа. Если HTML уже получен, но запрос фотографии начинается поздно, нужно выяснить, когда браузер узнаёт её адрес. Если ресурс загружен, а блок ещё не появился, причина может находиться в оформлении или выполнении кода. Уменьшение файла полезно лишь в той мере, в какой его передача задерживает показ.

Условный пример для карточки товара: фотография занимает мало места, но добавляется скриптом после получения сведений о наличии. До изменения последовательности запросов дополнительное сжатие даст мало. В задаче разработчику опишите зависимость изображения от этого запроса. Потребуется убрать ненужное ожидание, сохранив правильное отображение остатка.

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

INP: воспроизведите действие, которое задерживается

INP учитывает нажатия мышью, касания и действия клавиатурой на протяжении посещения. Задержка отсчитывается от начала взаимодействия до следующего отображённого кадра. Для большинства посещений итог связан с самым медленным действием; при большом числе взаимодействий методика отбрасывает отдельные крайние значения. Определение дано в описании INP.

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

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

Если фильтр немедленно показывает состояние загрузки, а результаты приходят позже, INP может быть хорошим при долгом ожидании ответа. Метрика не измеряет всё время ожидания результата из внешней системы. В приёмке отдельно проверяйте быструю реакцию интерфейса и время завершения действия, иначе посетитель получит отзывчивую кнопку и бесконечный индикатор.

Обычный запуск Lighthouse без пользовательских действий не измеряет INP. Его Total Blocking Time, или TBT, помогает заметить блокировку основного потока при лабораторной загрузке, но не равен INP. Хороший TBT ещё не подтверждает быструю работу фильтра, который тест не открывал. Для проверки взаимодействий нужна запись самих действий в браузере.

Передайте разработчику короткий сценарий: открыть конкретный каталог, выбрать два свойства, снять одно, повторить на менее производительном устройстве. Приложите запись задержки. После исправления пройдите тот же сценарий. Результаты фильтра должны оставаться правильными, а быстрые повторные нажатия не должны приводить к показу устаревшего списка товаров.

CLS: ищите причину смещения, а не только сдвинувшийся блок

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

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

В записи будут видны сместившиеся элементы. Причина часто расположена выше: текст поехал вниз из-за фотографии без зарезервированного места. Тогда исправлять отступы текста не нужно. Разработчик задаёт подходящие размеры или пропорции изображения и проверяет, сохраняется ли место до получения файла на каждой ширине.

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

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

Как оформить исправление и принять работу

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

В задаче укажите URL, устройство, исходный результат, запись проблемы и предполагаемое изменение. Критерий приёмки должен относиться к тому же сценарию. Формулировка «LCP-изображение запрашивается сразу после получения HTML, без ожидания виджета» полезнее пожелания «ускорить сайт».

• Сохраните исходные отчёты и дату изменения, чтобы не потерять точку сравнения.
• Повторите лабораторные измерения в одинаковых условиях и сравните несколько запусков.
• Проверьте форму, меню и другие действия после изменения загрузки кода.
• Убедитесь, что улучшение одной метрики не ухудшило другую и не изменило содержимое.
• Проследите за полевыми данными после выпуска с учётом периода накопления.

Если лабораторный результат улучшился, а полевой остаётся плохим после обновления окна наблюдений, проверьте охват исправления. Возможно, изменена только одна версия шаблона, пользователи получают старый ресурс из кеша или проблема возникает в другом сценарии. Для разбора передайте ШТАБ ИТ адреса, отчёты и последовательность действий: по этим данным можно начать диагностику и определить состав работ.