Core Web Vitals: измеряем и улучшаем веб-производительность
Вы создали быстрый сайт, но пользователи все еще жалуются на медленную работу. Или, возможно, ваши позиции в SEO упали после обновления Google. Виноваты могут быть Core Web Vitals — набор метрик, которые Google использует для оценки реального пользовательского опыта. Игнорирование их может навредить как удовлетворенности пользователей, так и видимости в поиске.
В этом руководстве вы узнаете, что такое Core Web Vitals, как их точно измерять и какие практические шаги предпринять для улучшения каждой метрики. Мы сосредоточимся на трех текущих метриках: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) и Cumulative Layout Shift (CLS).
Что такое Core Web Vitals?
Core Web Vitals — это подмножество Web Vitals, которые Google считает важными для обеспечения отличного пользовательского опыта. Они количественно оценивают, как быстро загружается контент, насколько отзывчива страница на взаимодействия и насколько она визуально стабильна.
Google использует эти метрики как сигнал ранжирования, но что важнее, они отражают реальные проблемы пользователей. Медленный LCP раздражает пользователей, ожидающих контент; высокий INP заставляет страницу казаться «тормозной»; высокий CLS вызывает ошибочные клики и раздражение.
Три основные метрики Core Web Vitals
- Largest Contentful Paint (LCP): Измеряет производительность загрузки. Он отмечает время, когда самый большой элемент контента (изображение, видео или текстовый блок) становится видимым. Хороший LCP — 2,5 секунды или меньше.
- Interaction to Next Paint (INP): Измеряет отзывчивость. Он фиксирует задержку всех взаимодействий (клики, касания, нажатия клавиш) и выдает одно значение. Хороший INP — 200 миллисекунд или меньше.
- Cumulative Layout Shift (CLS): Измеряет визуальную стабильность. Он количественно оценивает неожиданные сдвиги макета во время загрузки. Хороший CLS — 0,1 или меньше.
Эти пороги основаны на полевых данных реальных пользователей, а не на лабораторных тестах. Google оценивает их на 75-м процентиле загрузок страниц, то есть 75% пользовательского опыта должны соответствовать порогу «хорошо».
Как измерять Core Web Vitals
Вам нужны как лабораторные, так и полевые данные. Лабораторные инструменты имитируют одну загрузку страницы в контролируемых условиях, в то время как полевые данные (Real User Monitoring, RUM) фиксируют реальный пользовательский опыт на разных устройствах и сетях.
Лабораторные инструменты
- Lighthouse: Встроен в Chrome DevTools, он проверяет производительность и предоставляет оценки для LCP, CLS и общего времени блокировки (TBT), которое коррелирует с INP. Запускайте его в режиме инкогнито, чтобы расширения не искажали результаты.
- PageSpeed Insights: Объединяет лабораторные (Lighthouse) и полевые (CrUX) данные. Используйте его, чтобы увидеть как ваши лабораторные оценки, так и метрики реальных пользователей.
- WebPageTest: Предлагает расширенное тестирование из нескольких мест и на разных устройствах. Он предоставляет раскадровки и диаграммы водопада для диагностики проблем загрузки.
Полевые инструменты
- Chrome User Experience Report (CrUX): Публичный набор данных о метриках реальных пользователей из Chrome. Доступен через PageSpeed Insights, CrUX Dashboard или BigQuery.
- Google Search Console: Показывает статус Core Web Vitals для вашего сайта на основе данных CrUX. Он группирует URL-адреса по производительности.
- Библиотека web-vitals JavaScript: Небольшая библиотека для измерения метрик в вашем собственном RUM. Вы можете отправлять данные на вашу аналитическую платформу.
Вот как использовать библиотеку web-vitals для вывода метрик в консоль:
import {onLCP, onINP, onCLS} from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify(metric);
// Используйте navigator.sendBeacon() или fetch() для отправки данных
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
Для быстрой проверки без программирования вы можете использовать онлайн-инструменты, которые анализируют данные о производительности. Например, если у вас есть логи сервера, Nginx Log Analyzer поможет выявить медленные ответы, которые могут влиять на LCP.
Улучшение Largest Contentful Paint (LCP)
LCP часто является наиболее важной метрикой для оптимизации. На него влияют время ответа сервера, время загрузки ресурсов и клиентский рендеринг.
Оптимизация ответа сервера
- Используйте CDN для доставки контента из мест, более близких к пользователям.
- Включите кэширование (браузерное и серверное) для статических ресурсов.
- Оптимизируйте запросы к базе данных и серверный код, чтобы сократить TTFB (Time to First Byte).
- Перейдите на HTTP/2 или HTTP/3 для мультиплексирования и более быстрых соединений.
Оптимизация ресурсов
- Предзагрузка критических ресурсов: Используйте
<link rel="preload">для LCP-изображения или шрифта. - Сжатие и правильный размер изображений: Используйте современные форматы, такие как WebP или AVIF, и предоставляйте адаптивные изображения с
srcset. - Минификация CSS и JavaScript: Удалите ненужные символы и комментарии.
- Отложите некритический JavaScript: Используйте атрибуты
asyncилиdefer. - Встроенный критический CSS: Поместите стили для видимой области прямо в HTML, чтобы избежать блокирующих рендеринг запросов.
Устранение ресурсов, блокирующих рендеринг
CSS и JavaScript в <head> блокируют рендеринг. Встройте критический CSS и загружайте остальное асинхронно. Для JavaScript используйте defer или async.
Улучшение Interaction to Next Paint (INP)
INP измеряет время от взаимодействия пользователя до следующей отрисовки. На него влияют выполнение JavaScript, обработка событий и работа по рендерингу.
Сокращение времени выполнения JavaScript
- Разбивайте длинные задачи (более 50 мс) с помощью
setTimeoutилиrequestIdleCallback. - Используйте веб-воркеры для тяжелых вычислений.
- Применяйте debounce или throttle для обработчиков событий прокрутки, изменения размера и ввода.
- Избегайте больших синхронных скриптов; разделяйте код и лениво загружайте модули.
Оптимизация обработки событий
- Используйте пассивные слушатели событий для touch и wheel, чтобы улучшить производительность прокрутки.
- Минимизируйте манипуляции с DOM; группируйте обновления и используйте
requestAnimationFrame. - Сократите область пересчета стилей, избегая сложных селекторов.
Улучшение производительности рендеринга
- Используйте CSS
will-changeилиtransformдля анимаций, чтобы задействовать GPU-ускорение. - Избегайте «дрожания» макета, читая и записывая стили в разные фазы.
Улучшение Cumulative Layout Shift (CLS)
CLS измеряет неожиданные сдвиги макета. Они вызваны изменением положения элементов во время загрузки, часто из-за изображений без размеров, рекламы или динамически вставляемого контента.
Всегда указывайте атрибуты размера
Для изображений и видео задавайте атрибуты width и height или используйте CSS aspect-ratio. Это резервирует место и предотвращает сдвиги.
<img src="#" width="800" height="600" alt="Hero">
Резервируйте место для динамического контента
- Используйте CSS
min-heightдля контейнеров, которые загружают контент асинхронно (например, реклама, встраиваемые элементы). - Не вставляйте контент выше существующего, если это не вызвано взаимодействием с пользователем.
Используйте font-display swap
Пользовательские шрифты могут вызывать невидимый текст (FOIT) или сдвиги макета при загрузке. Используйте font-display: swap, чтобы сразу показывать запасной текст, и предзагружайте шрифты, чтобы сократить время подмены.
Собираем все вместе: практический рабочий процесс
- Измерьте: Начните с PageSpeed Insights, чтобы получить как лабораторные, так и полевые данные. Определите, какую метрику нужно улучшить.
- Диагностируйте: Используйте Lighthouse и панель Performance в Chrome DevTools, чтобы найти узкие места. Посмотрите на диаграмму водопада, активность главного потока и сдвиги макета.
- Оптимизируйте: Примените описанные выше методы, уделяя приоритет изменениям, влияющим на худшую метрику.
- Тестируйте: Повторно запустите лабораторные тесты, чтобы подтвердить улучшения. Разверните на промежуточной среде и используйте RUM для мониторинга полевых данных.
- Мониторьте: Настройте постоянный RUM с библиотекой web-vitals и оповещения о регрессиях. Используйте Search Console для отслеживания статуса Core Web Vitals.
Помните, что оптимизации могут иметь компромиссы. Например, ленивая загрузка изображений может улучшить начальную загрузку, но навредить LCP, если LCP-изображение загружается лениво. Всегда тестируйте с реальными пользователями.
FAQ
Каковы текущие пороги для Core Web Vitals?
Для LCP: хорошо — ≤2,5 с, требует улучшения — ≤4,0 с, плохо — >4,0 с. Для INP: хорошо — ≤200 мс, требует улучшения — ≤500 мс, плохо — >500 мс. Для CLS: хорошо — ≤0,1, требует улучшения — ≤0,25, плохо — >0,25. Эти пороги оцениваются на 75-м процентиле загрузок страниц.
Как часто нужно проверять Core Web Vitals?
Непрерывно мониторьте полевые данные с помощью RUM. Проверяйте Search Console ежемесячно для общих тенденций. Запускайте лабораторные тесты после значительных изменений кода или развертываний. Core Web Vitals могут меняться при обновлениях вашего сайта или сторонних скриптов.
Можно ли улучшить Core Web Vitals без разработчика?
Некоторые улучшения возможны с помощью плагинов или настроек (например, включение кэширования, оптимизация изображений). Однако значительные улучшения часто требуют изменений в коде, таких как встраивание критического CSS, отложенная загрузка JavaScript или реструктуризация загрузки ресурсов. Для INP и продвинутых оптимизаций LCP обычно нужна помощь разработчика.
Готовы проанализировать производительность вашего сервера? Попробуйте наш Nginx Log Analyzer, чтобы выявить медленные запросы, которые могут влиять на ваши Core Web Vitals.