Шаблон аудита Core Web Vitals и скорости страницы

Проанализируйте и исправьте Core Web Vitals (LCP, INP, CLS) и общую скорость страницы, используя полевые и лабораторные данные, чтобы достичь хороших порогов Google.

Core Web Vitals — это метрики пользовательского опыта, по которым Google измеряет реальную загрузку, интерактивность и визуальную стабильность: LCP (<=2.5 с), INP (<=200 мс) и CLS (<=0.1). Этот шаблон проведёт вас через измерение каждой метрики с помощью полевых и лабораторных данных, диагностику первопричины, применение проверенных исправлений и повторное тестирование, чтобы подтвердить, что улучшения закрепились. Проработайте варианты по порядку или сразу перейдите к метрике, которая не проходит для ваших URL.

6 готовых вариантов

Базовые показатели и полевые данные против лабораторных

Зафиксируйте отправную точку для каждого Core Web Vital, прежде чем что-либо менять, и разберитесь, какому источнику данных доверять для оценки, а какому — для отладки.

Зафиксируйте базовый уровень

Прежде чем что-либо оптимизировать, зафиксируйте, где сегодня находится каждая метрика для [URL страницы]. Google ранжирует по полевым данным (реальные пользователи Chrome, набор данных CrUX, скользящее 28-дневное окно), поэтому именно это число важно для поиска. Лабораторные данные (Lighthouse, одна смоделированная загрузка) предназначены для отладки, потому что они воспроизводимы и дают полезные трассировки.

  • Источник полевых данных: получите данные CrUX из PageSpeed Insights или из отчёта Core Web Vitals в Search Console для [Ресурс].
  • Источник лабораторных данных: запустите Lighthouse (Chrome DevTools или PageSpeed Insights), чтобы воспроизвести и отследить проблемы.
  • Запишите пороги: LCP хорошо <=2.5 с, INP хорошо <=200 мс, CLS хорошо <=0.1; отметьте своё текущее значение и статус прохождения по "75-му процентилю" для каждой.

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

Результат: базовая таблица с каждой метрикой, её текущим полевым значением, лабораторным значением и статусом прохождения на [Дата].

Исправления Largest Contentful Paint (LCP)

Диагностируйте и исправьте медленный LCP, чтобы основной элемент контента отрисовывался в течение 2.5 секунды для большинства посетителей.

Сделайте так, чтобы основной контент появлялся быстро

LCP измеряет, когда самый крупный видимый элемент (обычно главное изображение, постер видео или блок заголовка) завершает отрисовку. Цель — <=2.5s на 75-м процентиле. Определите LCP-элемент в Lighthouse, а затем поработайте над четырьмя фазами, которые его задерживают.

  1. Время до первого байта: сократите ответ сервера для [Источник] с помощью кэширования, более быстрого хостинга или рендеринга на границе сети.
  2. Ресурсы, блокирующие отрисовку: отложите некритичные CSS и JavaScript, чтобы браузер мог отрисовать страницу раньше.
  3. Задержка загрузки ресурса: добавьте preload для LCP-изображения и установите на нём [fetchpriority=high], чтобы браузер загружал его раньше.
  4. Задержка отрисовки ресурса: убедитесь, что LCP-изображение не загружается лениво и подаётся в современном формате и правильном размере.

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

Проверьте: повторно запустите Lighthouse и подтвердите, что LCP-элемент и его временная шкала загрузки для [URL страницы] опустились ниже 2.5 с.

Исправления Interaction to Next Paint (INP)

Повысьте отзывчивость, чтобы страница быстро реагировала на клики, касания и нажатия клавиш, заменив более старую метрику FID.

Сделайте взаимодействия мгновенными

INP заменил FID как Core Web Vital в марте 2024 года. Он измеряет задержку взаимодействий на протяжении всего визита на страницу, сообщая примерно о худшем из них. Цель — <=200ms. Плохой INP почти всегда связан с JavaScript, занимающим главный поток в момент действия пользователя.

  • Найдите длинные задачи: используйте панель Performance в DevTools, чтобы обнаружить задачи главного потока длительностью более 50 мс во время взаимодействия на [URL страницы].
  • Разбейте JavaScript: разделите длинные задачи на меньшие части и уступайте главный поток, чтобы ввод можно было обработать.
  • Сократите работу главного потока: удалите или отложите неиспользуемые скрипты, особенно тяжёлые сторонние теги, такие как [Название тега].
  • Оптимизируйте обработчики событий: применяйте debounce к затратным операциям и откладывайте несрочные обновления до следующей отрисовки.
  • Минимизируйте размер и стоимость макета DOM: большой или глубоко вложенный DOM делает каждое взаимодействие затратнее.

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

Проверьте: протестируйте реальные взаимодействия и подтвердите, что полевой INP движется к хорошему для [Ресурс].

Исправления Cumulative Layout Shift (CLS)

Остановите скачки контента во время загрузки, чтобы макет оставался визуально стабильным ниже CLS 0.1.

Остановите скачки макета

CLS измеряет неожиданные сдвиги макета видимого контента в течение жизни страницы. Цель — <=0.1. Сдвиги раздражают пользователей и вызывают ошибочные клики, и почти всегда они происходят от элементов, загружающихся без зарезервированного места.

  • Задавайте размеры медиа: всегда устанавливайте атрибуты width и height (или CSS aspect-ratio) для изображений, видео и iframe, чтобы браузер резервировал место до их загрузки.
  • Резервируйте место для встраиваний и рекламы: дайте слотам для [Реклама или встраиваемый элемент] контейнер с фиксированной min-height, чтобы они не сдвигали контент вниз.
  • Никогда не вставляйте контент над существующим: избегайте внедрения баннеров, уведомлений или cookie-панелей, которые толкают страницу вниз после отрисовки.
  • Предотвращайте сдвиги из-за подмены шрифтов: предзагружайте ключевые шрифты и разумно используйте [font-display], чтобы ограничить перекомпоновку.
  • Резервируйте место для динамического интерфейса: держите место для элементов, добавляемых через JavaScript, чтобы они разворачивались в заранее выделенное пространство.

Относитесь к любому "скачку", который вы видите во время загрузки, как к дефекту, который нужно устранить.

Проверьте: просмотрите кинопленку загрузки и подтвердите отсутствие видимых сдвигов на [URL страницы].

Оптимизация ресурсов и доставки

Сократите и ускорьте ресурсы, которые отправляет страница — изображения, JavaScript, CSS, кэширование и CDN — чтобы поднять все метрики сразу.

Отправляйте меньше, доставляйте быстрее

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

  • Изображения: подавайте современные форматы (например, WebP или AVIF), масштабируйте их до отображаемых размеров и сжимайте; применяйте ленивую загрузку только к изображениям вне видимой области, никогда — к LCP-изображению.
  • JavaScript: минифицируйте, применяйте tree-shaking и code-splitting, чтобы каждая страница загружала только необходимое; откладывайте или делайте async некритичные скрипты.
  • CSS: минифицируйте, удаляйте неиспользуемые правила и встраивайте критический CSS для контента в видимой области на [Шаблон].
  • Кэширование: устанавливайте долгое время жизни кэша для статических ресурсов и используйте имена файлов с отпечатком (fingerprint), чтобы обновления безопасно сбрасывали кэш.
  • CDN: подавайте ресурсы с граничных узлов рядом с пользователями и включайте сжатие (Brotli или gzip) у [Провайдер CDN].

Безжалостно проверяйте сторонние скрипты, так как они — распространённая скрытая причина медленных загрузок и плохой отзывчивости.

Проверьте: сравните общий объём переданных данных и число запросов до и после для [URL страницы].

Повторное тестирование и мониторинг

Подтвердите, что исправления сработали в полевых данных, и настройте постоянный мониторинг, чтобы регрессии выявлялись рано.

Подтвердите победу и удержите её

Исправление не завершено, пока полевые данные его не подтвердят. Поскольку CrUX использует скользящее 28-дневное окно, улучшения для реальных пользователей появляются не сразу, поэтому проверяйте в два этапа: сначала лабораторно для мгновенной обратной связи, затем полево в течение следующих недель.

  1. Повторите лабораторные тесты: используйте Lighthouse или PageSpeed Insights, чтобы подтвердить, что проблема уровня трассировки на [URL страницы] устранена.
  2. Следите за полевыми данными: отслеживайте CrUX в отчёте Core Web Vitals в Search Console и дождитесь обновления 28-дневного окна, прежде чем объявлять успех.
  3. Задайте цели: держите каждую группу URL на уровне LCP <=2.5s, INP <=200ms, CLS <=0.1 на 75-м процентиле.
  4. Мониторьте непрерывно: добавьте мониторинг реальных пользователей (RUM) или запланированные аудиты для [Ресурс], чтобы регрессии выявлялись быстро.
  5. Защищайтесь от дрейфа: проводите повторный аудит после крупных релизов, новых сторонних тегов или изменений шаблона.

Производительность — это не разовый проект; относитесь к ней как к постоянному бюджету, который вы защищаете с каждым деплоем.

Результат: отчёт «до/после» и отмеченная периодичность мониторинга на [Дата].

Как использовать этот шаблон

  1. Запустите PageSpeed Insights для ключевых URL и запишите значения как полевых данных (CrUX), так и лабораторных (Lighthouse) для LCP, INP и CLS.
  2. Сравните каждую метрику с хорошими порогами Google: LCP <=2.5 с, INP <=200 мс, CLS <=0.1 на 75-м процентиле, и отметьте каждую метрику, которая не проходит.
  3. Для не проходящего LCP определите LCP-элемент, затем сделайте его preload, задайте высокий приоритет загрузки, уберите ленивую загрузку и сократите ресурсы, блокирующие отрисовку, и время ответа сервера.
  4. Для не проходящего INP откройте панель Performance в DevTools во время взаимодействия, найдите длинные задачи главного потока более 50 мс и разбейте или отложите JavaScript, вызывающий их.
  5. Для не проходящего CLS добавьте width и height (или aspect-ratio) ко всем изображениям и встраиваниям, зарезервируйте место для рекламы и динамического контента и прекратите вставлять контент над существующим.
  6. Оптимизируйте доставку ресурсов: подавайте современные форматы изображений, минифицируйте и разделяйте JS и CSS, включайте сжатие и CDN и задавайте долгое время жизни кэша.
  7. Повторно запустите Lighthouse, чтобы подтвердить исправление каждой проблемы лабораторного уровня, затем мониторьте полевые данные CrUX в Search Console, учитывая обновление скользящего 28-дневного окна.
  8. Настройте постоянный мониторинг с помощью RUM или запланированных аудитов и проводите повторное тестирование после каждого крупного релиза, чтобы выявлять регрессии до того, как они дойдут до пользователей.

Советы

  • Доверяйте полевым данным (CrUX) в вопросе того, проходите ли вы, и лабораторным (Lighthouse) — чтобы диагностировать почему; ожидайте, что эти два числа будут различаться.
  • Никогда не загружайте лениво своё LCP-изображение и никогда не загружайте его через CSS-фон или JavaScript, потому что браузер обнаруживает его слишком поздно.
  • Проблемы с INP почти всегда — это JavaScript в главном потоке; аудит и откладывание тяжёлых сторонних тегов часто дают самый большой выигрыш.
  • Устраняйте любой видимый скачок во время загрузки, резервируя место заранее; если вы видите, как контент движется, ваш CLS пострадает.

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

Какие три Core Web Vitals и их хорошие пороги?

Largest Contentful Paint (LCP) должен быть 2.5 секунды или меньше, Interaction to Next Paint (INP) — 200 миллисекунд или меньше, а Cumulative Layout Shift (CLS) — 0.1 или меньше. Каждый порог должен достигаться на 75-м процентиле визитов реальных пользователей, чтобы считаться хорошим.

Что случилось с First Input Delay (FID)?

INP заменил FID как Core Web Vital в марте 2024 года. FID измерял только задержку до обработки первого взаимодействия, тогда как INP измеряет полную задержку взаимодействий на протяжении всего визита на страницу, давая более полную картину отзывчивости.

В чём разница между полевыми и лабораторными данными?

Полевые данные поступают от реальных пользователей Chrome в наборе данных CrUX за скользящее 28-дневное окно, и именно их Google использует для ранжирования. Лабораторные данные поступают от одной смоделированной загрузки в инструменте вроде Lighthouse; они воспроизводимы и идеальны для отладки, но не отражают того, что испытывают реальные пользователи.

Почему мой показатель Lighthouse отличается от полевого показателя CrUX?

Lighthouse выполняет одну загрузку на конкретном смоделированном устройстве и сети, тогда как CrUX агрегирует множество реальных пользователей на разных устройствах, соединениях и состояниях кэша. Расхождение — это нормально. Используйте лабораторные данные, чтобы найти и устранить причину, а полевые — чтобы подтвердить, что исправление сработало для реальных пользователей.

Почему мои Core Web Vitals не улучшились сразу после деплоя исправления?

Полевые данные обновляются медленно, потому что CrUX использует скользящее 28-дневное окно, поэтому улучшения проявляются полностью за недели. Подтвердите исправление в лабораторных инструментах вроде Lighthouse для мгновенной обратной связи, затем следите за полевым отчётом в Search Console, пока окно постепенно обновляется данными после исправления.

Какова самая распространённая причина плохого INP?

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