Скорость страниц стала прямым фактором ранжирования Google в 2018 году для мобильных (Speed Update) и теперь глубоко встроена в Core Web Vitals — метрики пользовательского опыта, формирующие часть сигналов ранжирования Google. Но связь между оптимизацией скорости и позициями более тонкая, чем «быстрее = выше позиции». Понимание того, что именно измеряет Google, где реальный потенциал оптимизации, и как отличить лабораторные данные от полевых — это точка входа в SEO скорости страниц.
Что Google реально измеряет
Core Web Vitals Google — сигналы page experience, используемые в ранжировании — состоят из трёх метрик:
Largest Contentful Paint (LCP): Время от начала загрузки страницы до момента, когда наибольший видимый контентный элемент (обычно главное изображение или основной заголовок) становится видимым. Пороговые значения Google: Хорошо ≤ 2,5с, Требует улучшения ≤ 4с, Плохо > 4с.
Interaction to Next Paint (INP): Измеряет отзывчивость страницы на взаимодействия пользователя — насколько быстро страница реагирует на клики, нажатия и ввод с клавиатуры на протяжении всего жизненного цикла страницы. Заменил First Input Delay в марте 2024 года. Хорошо ≤ 200мс, Требует улучшения ≤ 500мс, Плохо > 500мс.
Cumulative Layout Shift (CLS): Измеряет визуальную стабильность — насколько неожиданно смещается разметка страницы при загрузке. Вызывается изображениями без указания размеров, динамически встраиваемым контентом, загружаемыми веб-шрифтами. Хорошо ≤ 0,1.
Google ранжирует на основе полевых данных — реальных пользовательских измерений, собранных от пользователей Chrome через Chrome User Experience Report (CrUX). Лабораторные данные (оценки Lighthouse, PageSpeed Insights) полезны для диагностики проблем, но не напрямую определяют позиции.
LCP: здесь сосредоточена большая часть работы по скорости
LCP — как правило, наиболее высокоприоритетный Core Web Vital с точки зрения позиций. Наибольший контентный элемент на большинстве страниц — это либо главное изображение, либо заголовок над сгибом. Оптимизация LCP фокусируется на том, чтобы этот элемент стал видимым как можно быстрее.
Оптимизация LCP изображений:
- Предзагрузка LCP-изображения: Добавьте
<link rel="preload" as="image" href="/hero.webp">в<head>. Это заставляет браузер загружать LCP-изображение раньше, до того как оно встретится в HTML. - Форматы следующего поколения: WebP и AVIF сжимаются лучше, чем JPEG/PNG при эквивалентном качестве. Отдавайте WebP с JPEG-резервом через элемент
<picture>. - Правильные размеры изображений: Не отдавайте изображение шириной 2000px для контекста отображения 600px. Используйте
srcsetдля отдачи изображений нужного размера под каждый viewport. - Уберите ленивую загрузку с LCP-изображения: Атрибут
loading="lazy"задерживает изображения до их приближения к viewport — неверно для LCP-элемента, который должен загружаться немедленно. - Оптимизируйте время ответа origin-сервера (TTFB): LCP отсчитывается от начала навигации, включая время ответа сервера. Медленный TTFB (> 600мс) обречает LCP на провал ещё до начала рендеринга браузера.
Блокирующие рендеринг ресурсы, влияющие на LCP:
CSS в <link rel="stylesheet"> блокирует рендеринг до загрузки и парсинга. Большие CSS-файлы задерживают видимость чего-либо на экране. Решения: минификация CSS, удаление неиспользуемого CSS (PurgeCSS), инлайн критического CSS для контента над сгибом в тегах <style>.
INP: выполнение JavaScript и отзывчивость взаимодействий
INP больше всего зависит от выполнения JavaScript в основном потоке. Когда JavaScript запущен, он блокирует реакцию на взаимодействия пользователя.
Длинные задачи: Задачи JavaScript, занимающие более 50мс в основном потоке, создают «длинные задачи», задерживающие ответы на взаимодействия. Chrome DevTools Performance panel и Lighthouse выявляют длинные задачи.
Сокращение INP:
- Разбивайте длинные задачи JavaScript на меньшие фрагменты, используя
scheduler.yield()илиsetTimeoutдля передачи управления обратно браузеру - Откладывайте некритичный JavaScript через атрибуты
deferилиasyncв тегах script - Переносите тяжёлые вычисления в Web Workers (вне основного потока)
- Сокращайте общий объём загружаемого страницей JavaScript
CLS: стабильность разметки
CLS обычно устраняется конкретными исправлениями:
- Всегда указывайте размеры изображений: Атрибуты
widthиheightна тегах<img>позволяют браузеру резервировать пространство разметки до загрузки изображения. Без них страница прыгает при загрузке изображений. - Резервируйте место для динамического контента: Реклама, встраиваемые элементы и динамически добавляемый контент, появляющийся после загрузки страницы, вызывают смещения разметки при отсутствии зарезервированного пространства.
- Используйте
font-display: optionalили предзагрузку веб-шрифтов: Замена шрифта вызывает FOIT/FOUT, которые могут смещать текстовую разметку.
Полевые данные против лабораторных
Лабораторные данные (Lighthouse, режим лаборатории PageSpeed Insights): контролируемая тестовая среда, стабильное железо и симуляция сети. Быстрый запуск, полезны для диагностики, зависят от тестовой среды, а не реальных условий.
Полевые данные (CrUX, отчёт Core Web Vitals в GSC): агрегированные реальные пользовательские измерения за 28 дней. То, что Google использует для ранжирования. Требует реального трафика на URL.
Когда лабораторные данные показывают хорошие оценки, а полевые — плохие, проблема обычно в: (1) реальных пользователях на более медленных устройствах/соединениях, чем симулируемая среда, или (2) поведениях JavaScript, запускаемых реальными взаимодействиями пользователей, которые не происходят в лабораторных тестах.
Измерение реального прогресса
Оптимизации должны измеряться по данным CrUX, а не только по оценкам Lighthouse. Данные CrUX обновляются ежемесячно (скользящее среднее за 28 дней), поэтому изменения отображаются с задержкой. Используйте отчёт Core Web Vitals в GSC и CrUX dashboard для отслеживания трендов полевых данных.
Для сайтов без достаточного количества данных CrUX полагайтесь на Lighthouse и измеряйте стабильность результатов на различных устройствах и условиях сети для приближения к реальному пользовательскому опыту.