Core Web Vitals: как проверить LCP, INP и CLS

Страница открылась, но главное изображение ещё пустое. Кнопка не сразу отвечает на нажатие, а баннер внезапно сдвигает форму. Это разные проблемы, и исправлять их одним советом «сжать картинки» неудобно. Core Web Vitals помогает разделить загрузку, отзывчивость и стабильность интерфейса.

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

Что означают LCP, INP и CLS

Согласно документации Web Vitals, текущий набор включает три показателя. LCP описывает появление крупнейшего изображения или текстового блока в видимой области. INP оценивает задержку взаимодействия до следующей отрисовки. CLS отражает неожиданные сдвиги содержимого. Это разные стороны удобства, а не три названия общего времени загрузки.

Для оценки используют 75-й процентиль с разделением мобильных и настольных устройств. Он показывает значение, не превышенное в 75% наблюдений. Хороший результат одного быстрого визита не подтверждает хороший опыт всей аудитории. FID встречается в старых материалах, но в актуальном наборе его заменил INP.

Показатели TTFB, FCP и TBT полезны для поиска причин, однако не входят в эту тройку. Не ставьте знак равенства между оценкой Performance в Lighthouse и прохождением Core Web Vitals. В рабочем задании указывайте метрику, источник, адрес и условия измерения.

Как проверить сайт и различать реальные данные и тест

Откройте PageSpeed Insights для нужного URL и проверьте, какой блок читаете. По описанию инструмента, реальные данные CrUX отражают предшествующие 28 дней. Лабораторная часть строится на запуске Lighthouse в контролируемых условиях. Они отвечают на разные вопросы: как работала страница у пользователей и что произошло в конкретном тесте.

Обратите внимание на уровень данных: отдельный URL или весь источник origin. При недостатке наблюдений для страницы инструмент может показать сведения по origin. Их нельзя выдавать за измерение именно этой карточки товара. Отсутствие полевых данных также не означает, что сайт быстрый или медленный.

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

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

Как найти причину большого LCP

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

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

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

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

Как разобраться с медленным ответом на нажатие

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

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

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

При доработке frontend проверяйте фильтры, меню, ввод и отправку формы на доступном устройстве со скромной производительностью. Для SPA-приложения включайте внутренние переходы и длительную работу. Быстрая первая загрузка не доказывает, что последующие действия отзывчивы.

Как убрать неожиданные сдвиги страницы

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

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

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

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

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

Для каждой найденной проблемы оформите короткую задачу: адрес, сценарий, подтверждённая причина, изменение и способ проверки. Приоритет выбирайте по затронутым страницам и важности действия, а затем по трудоёмкости. Начинайте с проблем, которые удаётся воспроизвести и объяснить.

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

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

Google рекомендует хорошие Core Web Vitals в контексте качества страницы. Из этого нельзя вывести гарантию конкретной позиции или перенести пороги Google на формулу ранжирования Яндекса. В Гуси-Лебеди мы предлагаем связывать работу со скоростью с удобством посетителя: он видит содержимое, получает ответ на действие и не теряет форму из-за сдвига страницы.