Core Web Vitals: как улучшить метрики без переписывания сайта — опыт вебпоиск.рф

Что такое Core Web Vitals и почему они важны для SEO

Core Web Vitals — это набор метрик, которые оценивают пользовательский опыт: скорость загрузки, интерактивность и визуальную стабильность. Google использует их как сигнал ранжирования. Если сайт грузится долго, кнопки не нажимаются или контент прыгает — пользователи уходят, а поисковик это видит.

Метрики делятся на лабораторные (измеряются в момент проверки, например, в Lighthouse) и полевые (реальные данные пользователей из Chrome UX Report). Для SEO важнее полевые, потому что они отражают реальный опыт. Лабораторные помогают диагностировать проблемы.

Три ключевые метрики:

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

Раньше вместо INP была FID (First Input Delay), но с 2024 года Google заменил её на INP, потому что FID не учитывал задержки после первого взаимодействия. Многие сайты, которые считались быстрыми по FID, оказались проблемными по INP.

Почему это важно? Потенциально метрики влияют на позиции. Google не говорит, что это главный фактор, но в кейсах видно: ускорение LCP на 1–2 секунды даёт рост трафика на 5–10% на конкурентных запросах. А ещё это просто хорошо для бизнеса — быстрые сайты конвертят лучше.

Как замерить Core Web Vitals правильно

Прежде чем что-то чинить, нужно понять текущее состояние. Многие сразу лезут в код, но без замеров это гадание. Мы всегда начинаем с трёх инструментов:

1. PageSpeed Insights — показывает и лабораторные, и полевые данные. Если сайт новый и полевых данных нет, ориентируйтесь на лабораторные.

2. Search Console — отчёт «Основные веб-показатели» покажет, сколько URL в красной, жёлтой и зелёной зонах. Это агрегированные данные по группам страниц.

3. Chrome DevTools — вкладка Performance и Lighthouse для детального анализа.

Важный нюанс: полевые данные (CrUX) обновляются раз в 28 дней. Если вы только что что-то исправили, в отчёте это появится не сразу. Не паникуйте и не делайте повторных правок, пока не увидите результат.

Ещё один момент: метрики могут отличаться для мобильных и десктопов. Google ранжирует по мобильной версии, поэтому смотрим в первую очередь на смартфоны. В PageSpeed Insights переключайтесь на вкладку «Мобильные».

Типичные ошибки при замере

• Смотреть только на общую оценку (например, 70 баллов) и не разбираться, какая именно метрика хромает. 70 может быть из-за LCP, а может из-за CLS — лечение разное.
• Игнорировать полевые данные, если они есть. Лабораторные могут показывать 90, а у реальных пользователей всё плохо из-за медленного интернета.
• Замерять только главную страницу. В Search Console смотрите по группам URL: карточки товаров, статьи, категории — у них разные проблемы.

Оптимизация LCP: что реально работает

LCP — это время до отрисовки самого крупного элемента. Обычно это изображение баннера, заголовок или блок с текстом. Чтобы улучшить, нужно понять, что именно является LCP-элементом. В DevTools наведите на элемент — он подсветится.

Основные причины плохого LCP:

• Медленный сервер (TTFB > 600 мс).
• Большие несжатые изображения.
• Блокирующие скрипты и стили в `<head>`.
• Долгая загрузка шрифтов.

Что делать:

1. Ускорить сервер. Если TTFB высокий, никакие оптимизации не помогут. Проверьте хостинг: возможно, он перегружен. Включите кэширование на стороне сервера (например, через Redis или Memcached). Используйте CDN для статики — это снимет нагрузку и ускорит отдачу для удалённых регионов. Мы часто видим, как перенос сайта на VPS с правильной настройкой снижает LCP на 30–40% без единой правки в коде.

2. Оптимизировать изображения. LCP-картинку нужно сжать и отдать в современном формате (WebP или AVIF). Уберите лишние размеры: если изображение отображается 800px, не загружайте 2000px. Используйте атрибуты `width` и `height`, чтобы браузер знал пропорции. Добавьте `fetchpriority="high"` для LCP-изображения — это подскажет браузеру загрузить его в первую очередь.

3. Убрать блокирующие ресурсы. CSS и JS в `<head>` блокируют рендеринг. Критический CSS можно встроить инлайном, а остальное загружать асинхронно. Для JS используйте `defer` или `async`. Но осторожно: `async` может нарушить порядок выполнения, если скрипты зависят друг от друга.

4. Предзагрузка шрифтов. Если используете кастомные шрифты, добавьте `<link rel="preload">` для файлов шрифтов. Это сократит время до отрисовки текста. И обязательно `font-display: swap`, чтобы текст не был невидимым.

Пример из практики

На одном интернет-магазине LCP был 4.2 секунды. Оказалось, что баннер на главной весил 1.5 МБ и был в PNG. Сжали в WebP, добавили `fetchpriority`, уменьшили до нужного размера — LCP упал до 2.1 секунды. Никакой переделки сайта, только работа с изображением и одной строкой кода.

Как исправить CLS: пошаговое руководство

CLS измеряет, насколько сильно смещаются элементы при загрузке. Причина всегда одна: браузер не знает заранее размеры элемента и выделяет место под него после загрузки. Пользователь уже начал читать или кликать, а контент прыгнул.

Типичные виновники:

• Изображения без указанных `width` и `height`.
• Рекламные блоки, которые вставляются динамически.
• Шрифты, которые подгружаются и меняют размер текста.
• Всплывающие окна и баннеры, которые появляются сверху.

Что делать:

1. Всегда указывайте размеры изображений. Даже если картинка адаптивная, атрибуты `width` и `height` помогают браузеру зарезервировать место. В CSS можно задать `max-width: 100%; height: auto;` — пропорции сохранятся.

2. Фиксируйте место под рекламу. Если у вас есть рекламные блоки, задайте им фиксированную высоту через CSS. Да, это может быть неудобно, если реклама не загрузилась, но пустое место лучше, чем прыгающий контент.

3. Управляйте шрифтами. Используйте `font-display: optional` или `swap`. `optional` даёт браузеру очень короткое время на загрузку шрифта, и если не успел — использует системный. Это полностью убирает сдвиг, но может быть некрасиво, если брендовый шрифт важен. `swap` показывает текст системным шрифтом сразу, а потом меняет на кастомный — сдвиг возможен, но минимальный.

4. Не вставляйте контент сверху без необходимости. Если нужно показать уведомление, делайте это поверх контента (`position: fixed`), а не сдвигая его.

Распространённая ошибка

Многие ставят `height: auto` для изображений и думают, что этого достаточно. Но без явных `width` и `height` в HTML браузер не знает пропорций, пока не загрузит картинку. Всегда указывайте оба атрибута, даже если они не соответствуют реальному размеру — главное соотношение.

INP: как улучшить отзывчивость

INP заменил FID в 2024 году. Он измеряет задержку между действием пользователя (клик, тап, нажатие клавиши) и визуальной реакцией. Плохой INP обычно из-за тяжёлого JavaScript, который выполняется в основном потоке.

Что вызывает высокий INP:

• Долгие задачи (long tasks) — скрипты, которые занимают больше 50 мс.
• Слишком много сторонних скриптов: аналитика, чаты, виджеты.
• Тяжёлые обработчики событий.

Как улучшить:

1. Разбейте длинные задачи. Если у вас есть скрипт, который выполняется 200 мс, разбейте его на части с помощью `setTimeout` или `requestIdleCallback`. Это позволит браузеру обрабатывать другие события между частями.

2. Оптимизируйте обработчики событий. Не вешайте тяжёлые вычисления на `click` или `scroll`. Используйте делегирование событий и троттлинг. Например, для скролла — `passive: true` в addEventListener.

3. Отложите сторонние скрипты. Все счётчики, чаты и виджеты загружайте после основного контента. Используйте `defer` или динамическую загрузку. Если виджет не критичен, грузите его при взаимодействии.

4. Проверьте свой JS. Уберите неиспользуемый код, минифицируйте, используйте code splitting. Если у вас старая библиотека, возможно, есть более лёгкий аналог.

Как измерить INP

В PageSpeed Insights INP показывается в полевых данных. В лабораторных условиях его сложно воспроизвести, потому что нужны реальные взаимодействия. Для отладки используйте Performance Monitor в DevTools или расширение Web Vitals.

Сравнение методов оптимизации: что даёт эффект, а что нет

Как видите, некоторые методы влияют только на одну метрику. Начинайте с низкой сложности — они часто дают наибольший эффект при минимальных трудозатратах.

Пошаговый чек-лист: улучшаем Core Web Vitals без переписывания сайта

Этот чек-лист мы используем на проектах. Он помогает быстро пройтись по основным точкам и не упустить важное.

Шаг 1. Замер и аудит

• Откройте Search Console → «Основные веб-показатели». Запишите, сколько URL в красной зоне.
• Запустите PageSpeed Insights для мобильной версии главной и 2–3 типовых страниц.
• В DevTools определите LCP-элемент для каждой страницы.

Шаг 2. Работа с изображениями

• Сожмите все изображения (TinyPNG, Squoosh). Конвертируйте в WebP.
• Проверьте, что у всех `<img>` есть `width` и `height`.
• Для LCP-изображения добавьте `fetchpriority="high"` и `loading="eager"`.
• Для остальных — `loading="lazy"`.

Шаг 3. Сервер и кэширование

• Проверьте TTFB. Если > 600 мс, обратитесь к хостингу.
• Включите кэширование браузера для статики (заголовки `Cache-Control`).
• Настройте серверное кэширование (Redis, Memcached) или используйте плагины для CMS.
• Подключите CDN, если аудитория географически распределена.

Шаг 4. Шрифты

• Добавьте `font-display: swap` в `@font-face`.
• Предзагрузите основные шрифты через `<link rel="preload">`.
• Если возможно, используйте системные шрифты — это самый быстрый вариант.

Шаг 5. JavaScript

• Найдите все скрипты в `<head>`. Перенесите их в конец `<body>` или добавьте `defer`.
• Проверьте сторонние скрипты: чаты, аналитика, виджеты. Загружайте их асинхронно или после взаимодействия.
• Разбейте длинные задачи: если скрипт выполняется > 50 мс, оптимизируйте или раздробите.

Шаг 6. CSS

• Выделите критический CSS и встройте его инлайном.
• Остальной CSS загружайте асинхронно (например, через `preload` с `onload`).
• Уберите неиспользуемые стили.

Шаг 7. Проверка и мониторинг

• После правок снова запустите PageSpeed Insights.
• Через 28 дней проверьте полевые данные в Search Console.
• Настройте уведомления об изменениях в отчёте Core Web Vitals.

Частые ошибки и как их избежать

Даже опытные разработчики наступают на одни и те же грабли. Вот что мы видим чаще всего:

Ошибка 1. Оптимизация только главной страницы. Google оценивает весь сайт. Если главная зелёная, а карточки товаров красные, общий статус будет плохим. Проверяйте все типы страниц.

Ошибка 2. Игнорирование мобильных. Мобильный трафик часто превышает десктопный, а метрики на смартфонах хуже из-за слабого железа и медленного интернета. Всегда тестируйте на мобильных.

Ошибка 3. Слишком агрессивная ленивая загрузка. Если поставить `loading="lazy"` на LCP-изображение, оно загрузится с задержкой, и LCP ухудшится. Ленивая загрузка — только для контента ниже первого экрана.

Ошибка 4. Надежда на плагины. Плагины для кэширования и оптимизации могут помочь, но они не решают всех проблем. Иногда они сами создают новые: например, объединяют скрипты так, что порядок нарушается, и сайт ломается.

Ошибка 5. Отсутствие мониторинга. Один раз исправили и забыли. Но сайт обновляется, добавляются новые скрипты и картинки. Метрики могут снова упасть. Нужен регулярный контроль.

Заключение

Core Web Vitals — это не страшно. Большинство проблем решается без переписывания сайта: сжатием картинок, правильными атрибутами, настройкой кэширования и порядком загрузки скриптов. Начните с замера, выберите самую проблемную метрику и действуйте по чек-листу. Уже через месяц вы увидите улучшения в Search Console, а пользователи — более быстрый и стабильный сайт. Помните: скорость — это не разовая акция, а процесс. Удачи!