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

Core Web Vitals: загрузка, отклик и устойчивость страницы

Core Web Vitals — три показателя того, как человек воспринимает работу страницы: LCP, INP и CLS. Они отвечают на разные вопросы: когда появился главный контент, быстро ли страница реагирует на действия и не уезжают ли элементы во время чтения. Улучшать их стоит через поиск конкретной причины задержки или сдвига, а не через погоню за общей оценкой сервиса.

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

• LCP, Largest Contentful Paint: время появления крупнейшего подходящего элемента в видимой области — например, изображения или текстового блока. Меньше — лучше.
• INP, Interaction to Next Paint: задержка между действием пользователя и следующим отображённым кадром. Показывает отзывчивость интерфейса во время просмотра.
• CLS, Cumulative Layout Shift: оценка неожиданных сдвигов макета. Показывает визуальную устойчивость и не измеряется в секундах.

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

Мы предлагаем начать с вопроса «что мешает посетителю?». Когда основная проблема найдена, показатели помогают поставить измеримую задачу и проверить результат. Общую работу с ресурсами, сервером и загрузкой разбираем отдельно в статье как проверить и ускорить сайт.

Пороги LCP, INP и CLS: как читать оценку

У каждой метрики есть зоны «хорошо», «нужно улучшить» и «плохо». Таблица ниже основана на методологии порогов web.dev. Границы включены намеренно: ровно 2,5 секунды для LCP — ещё хорошо, ровно 4 секунды — нужно улучшить.

У CLS нет единицы времени: 0,1 — значение оценки сдвигов, а не десятая доля секунды. Поэтому задача «уменьшить CLS на секунду» некорректна. А для LCP и INP нужно сохранять единицы при сравнении отчётов: секунды и миллисекунды легко перепутать.

Зачем нужен 75-й перцентиль

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

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

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

Что именно измеряют показатели и почему FID больше не ориентир

LCP: главный контент уже виден?

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

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

INP: человек нажал — когда увидел ответ?

INP оценивает клики, касания и ввод с клавиатуры за время просмотра страницы. Итог — самое долгое взаимодействие за просмотр; на каждые 50 взаимодействий одно самое медленное отбрасывается как выброс. Это не средняя скорость всех кнопок. Прокрутка и наведение курсора сами по себе к измеряемым взаимодействиям не относятся; если подходящих действий не было, значение может отсутствовать.

12 марта 2024 года INP заменил FID в составе Core Web Vitals. Дата подтверждена сообщением web.dev о запуске. FID измерял задержку до начала обработки первого ввода. INP охватывает взаимодействия за время просмотра и учитывает также обработку и ожидание следующей отрисовки. Хороший старый FID не доказывает хороший INP.

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

CLS: содержимое остаётся на месте?

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

Практическая проблема выглядит просто: человек читает условия поставки, над ними появляется блок, и текст уезжает. Или картинка получает высоту только после загрузки, смещая кнопку. Отсутствие сдвигов в момент первого открытия не исключает их после прокрутки или подгрузки содержимого. Детали расчёта объясняет описание CLS.

Полевые и лабораторные данные: почему отчёты расходятся

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

Что такое CrUX и почему данных может не быть

Chrome User Experience Report, или CrUX, — набор агрегированных измерений реального опыта подходящих пользователей Chrome. Это не все посетители сайта. Для включения действуют условия доступности страниц, участия пользователей и достаточного числа наблюдений. Точный минимальный объём аудитории методология CrUX не раскрывает.

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

Как читать PageSpeed Insights без ложных выводов

1. Проверьте адрес, тип устройства и то, есть ли реальные данные вообще.
2. Уточните уровень: текущая страница или весь источник. Не приписывайте источнику свойства отдельной карточки и наоборот.
3. Посмотрите LCP, INP и CLS по отдельности, затем общий статус оценки Core Web Vitals.
4. Перейдите к лабораторной диагностике и установите, какой ресурс, обработчик или сдвиг требует исследования.
5. Сохраните результат и условия запуска, чтобы после изменений сравнивать сопоставимые данные.

Высокий балл Lighthouse не доказывает прохождение полевой оценки. В обычном загрузочном прогоне нет всей истории взаимодействий пользователя; TBT, Total Blocking Time, помогает искать причины плохой отзывчивости, но не равен INP. Для проверки меню или фильтра нужен сценарий с действиями, а для поздних сдвигов — наблюдение после загрузки.

Различия инструментов разобраны в объяснении web.dev о лабораторных и полевых данных. Окно наблюдений и переход с URL на origin описаны в документации PageSpeed Insights. Если значения не совпали, сначала проверьте условия, а затем ищите техническую причину.

Как Google и Яндекс относятся к скорости и удобству

Google: показатели участвуют в ранжировании, но не гарантируют место

Google прямо пишет: «Core Web Vitals are used by our ranking systems» — показатели используются системами ранжирования. Одновременно официальное объяснение page experience говорит, что единого сигнала качества взаимодействия нет, а хорошие значения не гарантируют верхние позиции.

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

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

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

Яндекс: важность скорости подтверждена, пороги Google официально не приняты

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

В изученной официальной справке мы не нашли подтверждения, что Яндекс принимает именно тройку LCP, INP и CLS с порогами Google как отдельное правило ранжирования. Поэтому таблица выше — ориентир методологии Web Vitals, а не опубликованная норма Яндекса. Утверждать, что Яндекс вообще не учитывает скорость, тоже нельзя.

Если на сайте установлена Яндекс Метрика, полезен отчёт «Время загрузки страниц»: он разбирает этапы загрузки и позволяет сегментировать данные по страницам, браузерам и регионам. «Ответ сервера», «Время загрузки и парсинга HTML» и «Время до загрузки DOM» — другие измерения, а по умолчанию отчёт показывает квантиль 50%, а не 75-й перцентиль. Они помогают расследованию, но не подменяют LCP, INP и CLS.

Как улучшить LCP: найти задержку до главного элемента

Начните с определения LCP-элемента в проблемном сценарии. Затем разберите цепочку его появления. Для изображения с внешним ресурсом web.dev выделяет ожидание первого байта, задержку начала загрузки ресурса, саму загрузку и задержку отображения. У текстового элемента без внешнего ресурса цепочка может быть другой.

Не назначайте lazy loading LCP-изображению. Если его появление отложено, небольшой вес файла не устранит задержку старта. Для действительно важного изображения можно рассмотреть fetchpriority="high". Но назначать высокий приоритет всем картинкам или предварительно загружать все ресурсы страницы без разбора мы не советуем.

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

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

Подробный порядок разбора приведён в руководстве по оптимизации LCP. После правки проверяйте итоговое время появления элемента: сокращение одного этапа ещё не доказывает улучшение всего показателя.

Как улучшить INP и CLS: проверить действия и геометрию

INP: записать медленное взаимодействие

Сначала назовите действие, которое тормозит: открытие меню, изменение фильтра, выбор варианта товара или ввод в форму. Затем воспроизведите его во время записи производительности. По одному общему числу трудно понять, какой обработчик менять. Полевой мониторинг с контекстом взаимодействия помогает сузить поиск.

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

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

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

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

CLS: выделить место до прихода содержимого

Основные причины неожиданных сдвигов — изображения и встраивания без размеров, динамические вставки и изменения при загрузке веб-шрифтов. Руководство по CLS рекомендует заранее задавать геометрию, в том числе через размеры изображений и CSS aspect-ratio.

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

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

Порядок работ: от отчёта до проверки после релиза

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

1. Зафиксируйте исходное состояние. Запишите URL, дату, устройство, уровень полевых данных, доступные значения p75 и условия лабораторного теста.
2. Выделите проблему. Какая метрика не укладывается в порог и какое неудобство ей соответствует? Есть ли аналогичное поведение на других страницах этого типа?
3. Подтвердите причину. Найдите LCP-элемент, запишите медленное взаимодействие или установите источник сдвига.
4. Поставьте ограниченную задачу. Укажите, что изменить и каким повторным сценарием проверить результат.
5. Проверьте исправление и функции. Сравните лабораторные записи в одинаковых условиях; пройдите меню, фильтр, форму и подгрузку.
6. Наблюдайте после выпуска. Отметьте дату релиза и следите за полевыми значениями, учитывая окно накопления данных.

Один из инструментов наблюдения — отчёт Core Web Vitals в Search Console, рекомендованный Google Search Central. Если там обнаружена проблема, используйте его как начало расследования и переходите к конкретным страницам и сценариям. Сам отчёт не заменяет запись выполнения кода.

Что написать разработчику вместо «сделайте зелёным»

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

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

Набор адресов и критерии проверки удобно включить в техническое задание на разработку. Если непонятно, какие страницы и сценарии исследовать первыми, начните с общей проверки сайта в рамках SEO-аудита и отделите проблемы контента от технических задержек.

Когда ждать изменения полевых значений

Лабораторный повторный тест позволяет проверить выпущенную версию сразу. Полевые данные PageSpeed Insights используют скользящий период наблюдений, поэтому после релиза в выборке ещё остаются старые просмотры. Новые данные постепенно меняют распределение; точного обещания даты перехода в зелёную зону из этого не следует.

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

Ошибки, из-за которых оптимизация не доходит до пользователя

• Проверять одну главную страницу. Добавьте важные шаблоны и действия: хорошая главная не подтверждает хороший фильтр каталога.
• Сравнивать разные условия. Зафиксируйте устройство, сеть, состояние кеша и шаги сценария.
• Исправлять вес файла без поиска причины. Ресурс может быть небольшим, но обнаруживаться или показываться поздно.
• Считать отсутствие данных прохождением. Отметьте ограничение выборки и используйте доступную диагностику.
• Принимать только балл Lighthouse. Отдельно проверяйте полевые метрики и работоспособность сценариев.
• Ждать роста позиций как критерия технической приёмки. Зафиксируйте измеримое поведение страницы; поисковый результат зависит от множества обстоятельств.

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

Нужны ли обязательно максимальные баллы PageSpeed?

Для работы с Core Web Vitals ориентируйтесь на значения LCP, INP и CLS, их полевую оценку и реальные сценарии. Лабораторный балл полезен как часть диагностики, но не заменяет эту проверку. Решение о следующих правках принимайте по оставшимся проблемам и ценности для посетителя.

Почему на компьютере всё хорошо, а на телефоне плохо?

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

Что делать, если у страницы нет данных CrUX?

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

Поможет ли смена хостинга исправить все три показателя?

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

Можно ли считать старый хороший FID подтверждением отзывчивости?

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

Гарантируют ли хорошие показатели рост в Google и Яндексе?

Такой гарантии нет. Google подтверждает использование Core Web Vitals в ранжировании и отдельно предупреждает, что хорошие значения не гарантируют верхние позиции. У Яндекса подтверждена важность скорости как показателя качества; применение именно порогов Google в изученной справке не установлено.

Источники

• Состав показателей, p75 и пороги — web.dev, Web Vitals и Defining the Core Web Vitals metrics thresholds.
• Определения метрик — web.dev, Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift.
• Дата замены FID — Rick Viscomi, web.dev, 12.03.2024, Interaction to Next Paint is officially a Core Web Vital; анонс — Jeremy Wagner, Rick Viscomi, web.dev, 31.01.2024, Interaction to Next Paint becomes a Core Web Vital on March 12.
• Правила выборки и чтение отчётов — Chrome for Developers, CrUX methodology; Google for Developers, About PageSpeed Insights; Philip Walton, web.dev, Why lab and field data can be different.
• Устранение причин задержек и сдвигов — web.dev, Optimize Largest Contentful Paint, Optimize Interaction to Next Paint, Optimize Cumulative Layout Shift.
• Поиск и качество страницы — Google Search Central, Understanding page experience in Google Search results и Understanding Core Web Vitals and Google search results.
• Скорость и диагностика в Яндексе — Вебмастер, «Как сделать сайт быстрее»; Метрика, «Время загрузки страниц».