Core Web Vitals: как скорость сайта превращается в заявки

Скорость сайта — та редкая вещь, которая одновременно влияет и на позиции в поиске, и на конверсию. Поисковики учитывают её в ранжировании, а посетители просто уходят: каждая лишняя секунда на первом экране стоит примерно 7% конверсии.

Разбираемся, что именно меряют Core Web Vitals и что с этим делать.

Три метрики простыми словами

LCP — когда появилось главное

Largest Contentful Paint: время до отрисовки самого крупного элемента первого экрана — обычно это картинка баннера или заголовок. Норма — до 2,5 секунды. Именно эту метрику чаще всего проваливают сайты с большим фоновым изображением.

INP — насколько сайт отзывчив

Interaction to Next Paint: сколько проходит между действием пользователя (клик, тап, ввод) и видимой реакцией страницы. Норма — до 200 миллисекунд. Метрика заменила устаревшую FID и оценивает не первое взаимодействие, а все подряд.

CLS — не прыгает ли вёрстка

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

Что тормозит чаще всего

Порядок разбора почти всегда одинаковый.

1. Картинки. Фотография 4000×3000 из телефона, которую браузер ужимает до 400 пикселей, — самая частая находка. Лечится сжатием, современными форматами (WebP, AVIF) и атрибутами width/height, которые заодно убирают смещения вёрстки.
2. Сторонние скрипты. Чаты, виджеты обратного звонка, пиксели, карты. Каждый добавляет свою порцию кода. Решение — грузить их отложенно, после основного контента, а карту подключать по клику.
3. Ответ сервера. Если сервер думает больше 600 мс, ускорять фронтенд почти бесполезно. Помогают кэширование, нормальный хостинг и разбор тяжёлых запросов к базе.
4. Шрифты и блокирующий CSS. Подключайте шрифты с font-display: swap и не грузите пять начертаний, если используете два.

План ускорения, который можно отдать разработчику

1. Снять замеры в PageSpeed Insights и в отчёте по реальным пользователям — цифры из лаборатории и из жизни отличаются.
2. Сжать все изображения, перевести в WebP, проставить размеры и loading="lazy" всему, что ниже первого экрана.
3. Первый экран — без сторонних скриптов. Всё остальное грузить после события загрузки.
4. Включить кэширование на сервере и сжатие ответов.
5. Убрать неиспользуемый CSS и JS — в типовых темах его бывает до 60%.
6. Повторить замеры и зафиксировать результат в отчёте.

Важно: оптимизация не заканчивается один раз. Достаточно добавить один тяжёлый виджет — и метрики снова уходят в красную зону. Поэтому скорость стоит проверять хотя бы раз в квартал.

Когда ускорять бессмысленно

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

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