Core Web Vitals оценивают три свойства пользовательского опыта: скорость появления основного контента, отзывчивость интерфейса и визуальную стабильность. Решение нельзя принимать по одному общему баллу. Сначала смотрят полевые данные реальных посещений за 75-й процентиль, отдельно для мобильных и настольных устройств. Затем лабораторными измерениями воспроизводят проблему и находят техническую причину. Исправление принимают только после проверки того же шаблона, пользовательского сценария и условий, в которых возникло отклонение.
Какие показатели считаются хорошими
| Метрика | Что измеряет | Хороший результат |
|---|---|---|
| LCP | Время появления крупнейшего значимого элемента | не более 2,5 секунды |
| INP | Задержку реакции страницы на взаимодействия | не более 200 миллисекунд |
| CLS | Суммарную визуальную нестабильность | не более 0,1 |
Порог оценивается на 75-м процентиле загрузок. Страница или группа считается прошедшей проверку только тогда, когда все три метрики находятся в хорошем диапазоне. Наличие зелёного лабораторного результата не отменяет плохие полевые данные, а отсутствие URL-уровня в полевых данных не доказывает, что страница работает хорошо.
Полевые и лабораторные данные решают разные задачи
Полевые данные показывают опыт реальных пользователей: их устройства, сети, кэш, географию и поведение. Они нужны для оценки фактического состояния и контроля устойчивого изменения. Такие данные накапливаются, поэтому эффект релиза не появляется в отчёте мгновенно.
Лабораторный тест создаёт воспроизводимый запуск в заданных условиях. Он помогает увидеть цепочку загрузки, блокирующие ресурсы, долгие задачи и смещения макета. Это диагностический инструмент, а не замена реальному распределению посещений.
Если поле и лаборатория расходятся, сначала проверяют уровень агрегации, устройство, шаблон, дату и наличие достаточного объёма наблюдений. Только затем делают вывод о причине.
Как провести аудит по шаблонам
Не проверяйте только главную страницу. Разделите сайт на типы: главная, категория, карточка, статья, форма, личный кабинет и другие самостоятельные шаблоны. Для каждого выберите реальные URL, основные устройства и критические действия пользователя.
| Сценарий | Инструмент | Нормальный результат | Ошибка | Следующее действие |
|---|---|---|---|---|
| Карточка с крупным изображением | Полевой отчёт + трассировка загрузки | LCP в хорошем диапазоне, ресурс загружается приоритетно | Изображение обнаруживается поздно или слишком тяжёлое | Исправить разметку изображения, размер и приоритет загрузки |
| Листинг с фильтрами | Полевые данные + профилирование взаимодействия | INP в хорошем диапазоне | Обработчик блокирует основной поток | Разбить долгую работу, сократить DOM и повторные вычисления |
| Статья с рекламным блоком | Запись макета + CLS-диагностика | Зарезервировано место, CLS в хорошем диапазоне | Блок сдвигает текст после загрузки | Задать размеры или стабильный контейнер |
| Страница с веб-шрифтами | Сеть + визуальная проверка | Текст появляется без заметной перестройки | Замена шрифта меняет геометрию | Настроить загрузку и подобрать совместимые метрики шрифта |
| SPA-переход | RUM и тест мягкой навигации | Взаимодействия и смены контента измеряются корректно | Сигнал теряется или накапливается за длинную сессию | Проверить инструментацию и архитектуру навигации |
| Сторонний виджет | Профилирование загрузки и действий | Виджет не блокирует ключевой контент | Скрипт создаёт долгие задачи или сдвиги | Отложить, изолировать или заменить интеграцию |
Что исправлять для каждой метрики
LCP
Сначала найдите фактический LCP-элемент. Если это изображение, проверьте, присутствует ли оно в исходном HTML, подходит ли размер, не скрыта ли загрузка за JavaScript и не применяется ли lazy loading к элементу первого экрана. Если LCP — текстовый блок, проверьте серверный ответ, стили, шрифты и ресурсы, блокирующие отрисовку.
Уменьшение файла не поможет, если браузер узнаёт о ресурсе слишком поздно. И наоборот, высокий приоритет не компенсирует тяжёлое изображение или медленный ответ сервера.
INP
Найдите конкретное действие: открытие меню, применение фильтра, добавление товара, ввод в поле. Затем разделите задержку на ожидание, выполнение обработчика и отрисовку результата. Частые причины — длинная задача JavaScript, слишком большой DOM, синхронная обработка нескольких событий и тяжёлая перерисовка.
Оптимизировать нужно тот код, который блокирует взаимодействие, а не весь JavaScript по размеру. После исправления повторите именно проблемное действие.
CLS
Отследите элемент, который сдвинулся, и элемент, который вызвал смещение. Зарезервируйте место под изображения, видео, баннеры и виджеты; не вставляйте новый контент над уже показанным; контролируйте замену шрифтов и анимации геометрических свойств.
Не каждое визуальное движение ухудшает CLS: смещения, произошедшие сразу после ожидаемого действия пользователя, оцениваются иначе. Поэтому важно смотреть запись и временную связь, а не только итоговое число.
Как принять исправление
До релиза зафиксируйте шаблон, URL, устройство, проблемное действие, полевой сигнал и воспроизводимый лабораторный сценарий. После изменения сравнивайте одинаковые условия. Нормальный результат — причина устранена, функциональность сохранена, соседние шаблоны не ухудшились.
Проверка включает:
повтор лабораторного сценария на нескольких URL шаблона;
просмотр ошибок JavaScript и сетевых ответов;
проверку адаптивных размеров и основных действий;
контроль LCP-элемента, длинных задач и источников сдвига;
наблюдение за полевыми данными после накопления нового периода.
Откат требуется, если ускорение достигнуто ценой пропавшего контента, сломанной формы, недоступной навигации или ухудшения другого критического шаблона.
Как приоритизировать задачи
Сначала исправляйте шаблоны, которые одновременно имеют плохие полевые показатели, значимый пользовательский трафик и повторяемую техническую причину. Следом — общие компоненты, влияющие сразу на несколько типов страниц. Точечную лабораторную аномалию без полевого подтверждения можно оставить в диагностическом бэклоге, если она не ломает пользовательский сценарий.
Итог
Core Web Vitals — не конкурс баллов. Рабочий процесс связывает полевой сигнал, конкретный шаблон, воспроизводимую причину, безопасное исправление и повторную проверку. Только такая цепочка позволяет понять, что именно стало лучше и не сломалось ли что-то ещё.
Получите бесплатный аудит и стратегию роста
Изучим сайт, покажем точки роста и подготовим прогноз до квалифицированных лидов и оборота из SEO/GEO.