Как улучшить Core Web Vitals: порядок действий, который действительно помогает

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

Три показателя — по одному предложению на каждый

Отсюда следует порядок: сначала изображения, потом скрипты, потом макет. Кеширование влияет прежде всего на время ответа сервера — то есть на часть LCP, а на INP почти не влияет.

Шаг 1: самое большое изображение

На большинстве страниц кандидатом на LCP является hero-изображение. Сразу помогают три вещи, в таком порядке:

1. Уменьшить до реально нужного размера: фотография шириной 4000 пикселей в области шириной 1200 пикселей — самая частая отдельная причина.
2. Преобразовать в современный формат (WebP или AVIF) с запасным вариантом для старых браузеров.
3. НЕ загружать лениво. Изображение в самом верху должно загружаться сразу — Lazy-Load здесь ухудшает показатель, а не улучшает его.

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

Шаг 2: JavaScript

INP — это показатель, с которым кеширование не помогает. Он измеряет, сколько времени нужно браузеру, чтобы отреагировать на клик, — а блокируют браузер скрипты, которые работают именно в этот момент.

Самый действенный рычаг — убрать лишнее: слайдер, которым никто не пользуется; окно чата на каждой странице; три семейства шрифтов, два из которых никто не замечает. Только после этого имеет смысл браться за defer, объединение и отложенную загрузку до первого взаимодействия.

Шаг 3: убрать скачки

• Каждому изображению нужны width и height в разметке — тогда браузер резервирует для него место
• Помещать встроенный контент в контейнер с фиксированной высотой
• Раздавать шрифты локально и управлять ими через font-display, а не подгружать их извне
• Встраивать баннеры о файлах cookie и информационные полосы так, чтобы они перекрывали контент, а не сдвигали его

Только потом: кеширование, Minify, Preload

Кеш страниц экономит время на построении страницы — это много, если сервер медленный, и мало, если он быстрый. Minify экономит байты и чаще всего становится причиной сломанных страниц после оптимизации. Preload — это указание, а не просьба: слишком много таких указаний вытесняют именно то, что нужно в первую очередь.

Включай Minify по одному переключателю и каждый раз проверяй страницу с формой, корзину и страницу с видео. Кто включает всё сразу, при ошибке ищет её среди десяти переключателей.

Правильное измерение

Два вида измерений нужно различать. Лабораторный тест измеряет в фиксированных условиях и хорошо подходит для сравнения «до» и «после». Полевые данные поступают от реальных посетителей с реальными устройствами и соединениями — именно они определяют, как Google оценивает страницу.

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

Когда плагин уже не поможет

Есть предел, за которым ни один плагин кеширования уже ничего не сделает: перегруженный конструктор страниц с тридцатью скриптами, хостинг с высокой базовой нагрузкой, тема, которая загружает всё на каждой странице. Если сервер отвечает медленно даже без контента, дело не в плагине.

Часто задаваемые вопросы