Core Web Vitals — три пользовательские метрики, которые описывают скорость появления основного контента, отзывчивость интерфейса и визуальную стабильность страницы. В текущем наборе это LCP, INP и CLS.
Метрики полезны не как отдельная SEO-галочка. Они помогают находить ситуации, когда человек видит пустой экран, ждёт реакции после нажатия или пытается попасть по кнопке, которая внезапно сдвинулась.
Какие значения считаются хорошими
Google оценивает показатель по 75-му процентилю реальных посещений отдельно для мобильных и настольных устройств.
| Метрика | Хорошо | Нужны улучшения | Плохо |
|---|---|---|---|
| LCP | до 2,5 с | 2,5–4 с | более 4 с |
| INP | до 200 мс | 200–500 мс | более 500 мс |
| CLS | до 0,1 | 0,1–0,25 | более 0,25 |
Порог не означает, что страница с LCP 2,49 секунды идеальна, а с 2,51 секунды бесполезна. Это ориентиры для устойчивого пользовательского опыта.
Полевые и лабораторные данные
Перед оптимизацией важно разделить два типа измерений.
Полевые данные
Они собираются у реальных пользователей. На результат влияют устройство, сеть, кеш, география, состояние процессора и реальные действия человека.
Именно полевые данные отвечают на вопрос: что происходит у аудитории сайта.
Публичным источником таких данных для достаточно посещаемых страниц служит Chrome UX Report. В PageSpeed Insights полевые показатели показаны отдельно от лабораторного теста.
Лабораторные данные
Lighthouse, DevTools и WebPageTest запускают воспроизводимый сценарий в контролируемых условиях. Они полезны для диагностики, сравнения изменений и поиска конкретной причины.
Лабораторный тест не заменяет реальные данные:
- в нём обычно нет полноценного пользовательского взаимодействия для INP;
- один запуск слишком чувствителен к фоновым процессам;
- тестовое устройство и сеть могут не совпадать с аудиторией;
- кеш и сторонние сервисы ведут себя иначе.
Рабочая схема: полевые данные показывают проблему, лабораторные помогают её воспроизвести, а повторные полевые данные подтверждают эффект.
LCP: когда появился главный контент
Largest Contentful Paint измеряет время до отрисовки крупнейшего подходящего элемента в видимой области. На статье это может быть заголовок или обложка, на лендинге — изображение первого экрана.
У LCP есть четыре составляющие:
- TTFB — ожидание первого байта документа.
- Задержка загрузки ресурса — время до начала запроса изображения или шрифта.
- Загрузка ресурса.
- Задержка отрисовки после получения данных.
Оптимизация только файла изображения не поможет, если браузер поздно обнаруживает этот файл или сервер долго формирует HTML.
Как улучшать LCP
- Найдите фактический LCP-элемент в DevTools, а не угадывайте его.
- Сократите TTFB: кешируйте статические страницы, используйте CDN, уберите ненужную серверную работу.
- Поместите важный ресурс в исходный HTML.
- Не применяйте
loading="lazy"к изображению первого экрана. - Для приоритетной картинки используйте
fetchpriority="high", если браузер иначе начинает загрузку слишком поздно. - Укажите корректные
widthиheight. - Отдавайте изображение подходящего размера через
srcsetиsizes. - Удалите блокирующие стили и скрипты, которые не нужны для первого экрана.
- Проверьте загрузку веб-шрифтов: скрытый до загрузки шрифта текст может стать LCP-элементом слишком поздно.
На статическом сайте часто удаётся получить быстрый HTML. Но тяжёлая hero-картинка или сторонний виджет всё равно легко испортят LCP.
INP: насколько быстро интерфейс отвечает
Interaction to Next Paint оценивает задержку пользовательских взаимодействий в течение всего посещения. В расчёт входят нажатия мышью, касания и нажатия клавиш.
Метрика рассматривает полный путь:
- задержку до начала обработчика;
- выполнение обработчиков;
- работу браузера перед следующей отрисовкой.
Поэтому проблема может находиться не только внутри click-функции. Главный поток уже может быть занят аналитикой, большой задачей рендеринга или синхронным вычислением.
Типичные причины плохого INP
- большие клиентские пакеты, которые долго разбираются и выполняются;
- обработчик делает слишком много работы за один кадр;
- массовое изменение DOM;
- синхронное чтение и запись layout-свойств;
- тяжёлая фильтрация или сортировка на основном потоке;
- сторонние скрипты;
- повторный рендер большого дерева компонентов.
Как улучшать INP
- Запишите проблемное взаимодействие в панели Performance.
- Найдите долгие задачи, совпадающие с нажатием.
- Сначала обновите интерфейс минимальным состоянием: покажите нажатие, загрузку или открытый элемент.
- Разбейте остальную работу на меньшие задачи.
- Не выполняйте тяжёлое вычисление, если его можно перенести на сервер или Web Worker.
- Сократите область повторного рендера.
- Загружайте редко используемый код по требованию.
- Проверяйте сторонние скрипты так же строго, как собственный код.
Для простого блога лучший способ улучшить INP — не отправлять JavaScript, который странице не нужен. Именно поэтому архитектура фреймворка рассматривается в материале Astro или Next.js.
CLS: почему элементы прыгают
Cumulative Layout Shift измеряет неожиданные сдвиги видимого содержимого. Пользователь не должен терять строку текста или нажимать не ту кнопку из-за появления баннера над ней.
CLS не штрафует любой сдвиг. Изменение интерфейса после явного действия пользователя может быть ожидаемым. Проблема — движение без понятной причины.
Основные источники CLS
- изображения и видео без зарезервированного места;
- рекламные или встроенные блоки неизвестной высоты;
- баннеры, вставленные над уже показанным контентом;
- замена системного шрифта сильно отличающимся веб-шрифтом;
- анимации свойств, влияющих на layout;
- контент, который появляется после гидрации.
Как улучшать CLS
- Всегда задавайте размеры медиа или используйте
aspect-ratio. - Резервируйте место под виджеты и рекламу.
- Не вставляйте уведомления над текущим контентом без действия пользователя.
- Подбирайте fallback-шрифт с похожими метриками.
- Анимируйте
transformиopacity, а неtop,left,widthилиheight. - Проверяйте страницу не только при загрузке, но и во время длинной сессии.
Практический порядок оптимизации
Шаг 1. Определить шаблон
Не смешивайте главную страницу, статью и каталог. У каждого типа страницы свои LCP-элементы и интерактивные сценарии.
Шаг 2. Зафиксировать исходные данные
Сохраните полевые значения, URL, устройство, дату и лабораторный профиль. Без исходной точки невозможно понять, помогло ли изменение.
Шаг 3. Исправить самый крупный источник
Не начинайте с минификации нескольких килобайт, если изображение первого экрана весит мегабайт или главный поток занят сторонним скриптом.
Шаг 4. Проверить побочные эффекты
Предзагрузка слишком большого числа ресурсов может ухудшить LCP. Агрессивный content-visibility способен изменить поиск по странице. Любая оптимизация проверяется в контексте.
Шаг 5. Наблюдать после релиза
Полевым данным требуется время. При небольшом трафике полезно дополнительно собирать метрики через библиотеку web-vitals в собственную систему наблюдения.
Что не стоит делать
- Не оптимизировать только общий Performance Score.
- Не запускать Lighthouse один раз и не считать результат окончательным.
- Не откладывать все изображения через lazy loading.
- Не удалять полезную функциональность ради зелёного индикатора.
- Не считать Core Web Vitals единственной составляющей качества или ранжирования.
- Не добавлять сложный прелоадер, который скрывает проблему вместо её решения.
Чек-лист перед релизом
- LCP-ресурс присутствует в HTML и начинает загружаться рано.
- Изображения имеют размеры и адаптивные варианты.
- Нет длинных задач после основных нажатий.
- Мобильное меню работает с клавиатуры и закрывается по
Escape. - Динамические блоки резервируют место.
- Проверены мобильный и настольный шаблоны.
- Сравнены минимум несколько лабораторных запусков.
- Зафиксированы полевые показатели для последующего сравнения.
Техническая проверка этих и других пунктов собрана в чек-листе SEO-аудита.