Технологии · 7 мин

Core Web Vitals: что измерять и как улучшать сайт

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

Тематическая иллюстрация к материалу: Core Web Vitals: что измерять и как улучшать сайт

Редакция Romanov Lab · Обновлено

Скорость — это несколько разных ощущений

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

Эти метрики полезны как диагностические сигналы, но не заменяют проверку реальных задач. Быстрая страница с непонятными условиями не становится хорошим предложением. И наоборот, содержательный сайт стоит улучшать технически, чтобы его было удобно использовать на обычных устройствах. Цель оптимизации — убрать конкретные препятствия, а не получить красивую картинку отчета.

Разберитесь в актуальных метриках

LCP отражает время появления крупнейшего видимого элемента содержимого. INP оценивает отзывчивость страницы при взаимодействиях, а CLS — неожиданные сдвиги макета. По документации web.dev хорошие ориентиры: LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1. Оценка проводится по 75-му процентилю, отдельно для мобильных и настольных устройств.

INP входит в актуальный набор Core Web Vitals; старые отчеты с FID нельзя механически использовать как текущий стандарт. При обсуждении аудита уточняйте, какая метрика измерялась, каким инструментом и на каких данных. Значение без этой информации может выглядеть убедительно, но не объяснять опыт людей, которые действительно заходят на ваш сайт.

Не смешивайте лабораторию и реальные посещения

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

Обычный Lighthouse-тест загрузки не измеряет полноценный INP без пользовательских взаимодействий; для диагностики он использует другие показатели, включая TBT. Если полевых данных мало, это нужно прямо отметить. Не подменяйте отсутствие наблюдений утверждением, что проблема решена. Используйте повторяемые тесты и собирайте дополнительные данные в рамках согласованной аналитики.

Ищите причину в конкретном шаблоне

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

Для LCP полезно проверить обнаружение и приоритет главного изображения, размер файла и задержки сервера. Для INP — длинные задачи и лишний JavaScript. Для CLS — зарезервированное место под изображения, вставляемые блоки и поведение шрифтов. Рекомендации web.dev помогают выбрать техническое направление, но конкретное исправление должно опираться на наблюдаемую причину.

  • Какой пользовательский сценарий страдает
  • Какие типы страниц затронуты
  • Что воспроизводится в одинаковых условиях
  • Какой результат подтвердит полезность изменения

Проверяйте компромиссы и побочные эффекты

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

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

Сделайте производительность частью процесса

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

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

Практический разбор LCP: не вся задержка находится в картинке

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

Разделите причину на задержку сервера, позднее обнаружение ресурса, передачу и отрисовку. Для каждого участка подберите проверку. Не назначайте высокий приоритет всем изображениям одновременно: приоритет полезен, когда помогает действительно важному ресурсу. Главное изображение первого экрана обычно не стоит откладывать до ленивой загрузки. Любое изменение проверяйте по фактическому элементу LCP, который может различаться на разных экранах.

Практический разбор INP: воспроизведите конкретное действие

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

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

Практический разбор CLS: найдите источник сдвига

Запишите экран во время загрузки и дальнейшего использования. Если текст прыгает после появления изображения, проверьте зарезервированную область и соотношение сторон. Если движение появляется после виджета или объявления, заранее определите его место. Если меняется геометрия текста при загрузке шрифта, изучите совместимость запасного и основного начертания. Не все видимые перемещения имеют одинаковую причину.

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

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

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

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

Выбирайте оптимизацию по охвату и риску

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

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

Что включить в проверку следующего релиза

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

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

Источники и дальнейшее чтение

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

Читайте также