Скорость сайта и Core Web Vitals: как проверить и что чинить

Что такое Core Web Vitals и почему это важно для бизнеса

Core Web Vitals - это три метрики скорости, которые Google считает критичными для удобства посетителя: LCP (как быстро загружается главный контент), INP (как быстро сайт реагирует на клики), CLS (прыгают ли элементы во время загрузки). Они встроены в алгоритм ранжирования с 2021 года.

Для бизнеса это значит две вещи. Первая: если метрики в красной зоне, сайт теряет позиции в поиске - конкуренты с такими же текстами, но быстрее, окажутся выше. Вторая: медленный сайт прямо режет конверсию. По данным Google, каждая лишняя секунда загрузки снижает вероятность покупки на 20%. Посетитель не будет ждать - он уйдёт к тем, у кого открылось быстрее.

Хорошая новость: Core Web Vitals можно измерить бесплатными инструментами, а большинство проблем чинится без переписывания сайта с нуля. Плохая: если разработчик говорит «у меня всё быстро», но цифр не показывает - это не аргумент. Нужны конкретные замеры.

Три метрики Core Web Vitals: что измеряет каждая

LCP (Largest Contentful Paint) - время, за которое на экране появляется самый крупный видимый элемент: картинка, заголовок, блок текста. Норма - меньше 2,5 секунды. Если 4 секунды и больше - это красная зона, посетитель видит пустой экран и уходит.

INP (Interaction to Next Paint) - задержка между кликом и реакцией интерфейса. Нажали кнопку - сколько миллисекунд пройдёт, пока сайт отреагирует. Норма - меньше 200 миллисекунд. Если больше 500 - сайт тормозит, кажется зависшим. Эта метрика заменила старый FID в марте 2024 года.

CLS (Cumulative Layout Shift) - насколько элементы страницы прыгают во время загрузки. Открыли сайт, начали читать, вдруг подгрузилась картинка, текст уехал вниз, вы промахнулись мимо кнопки и попали в рекламу. CLS измеряет именно это. Норма - меньше 0,1. Всё, что выше 0,25, раздражает пользователя.

Как проверить сайт: три бесплатных инструмента

PageSpeed Insights (pagespeed.web.dev) - вставляете URL, получаете оценку от 0 до 100 и конкретные цифры по каждой метрике. Инструмент показывает две колонки: лабораторные данные (замер прямо сейчас) и полевые данные (усреднённая статистика с реальных устройств посетителей за последние 28 дней). Полевые важнее - это то, что видят ваши клиенты.

Google Search Console, раздел «Скорость» - показывает, какие страницы сайта в красной, жёлтой и зелёной зоне. Если там сотни URL в красном, проблема не в одной странице, а в шаблоне или хостинге. Данные обновляются раз в сутки.

Lighthouse (встроен в Chrome) - открываете DevTools (F12), вкладка Lighthouse, жмёте «Анализ». Этот инструмент даёт подробный список проблем с приоритетами: что чинить первым, какой выигрыш в миллисекундах даст каждая правка. Удобно для разработчика, но цифры будут отличаться от PageSpeed, потому что замер идёт с вашего компьютера, а не с телефона посетителя из региона.

Как улучшить Core Web Vitals: что чинить первым

Если LCP больше 4 секунд, проблема чаще всего в картинках или хостинге. Первое - проверьте вес главного изображения. Если оно весит 3 МБ, сожмите до 150-300 КБ через TinyPNG или Squoosh, переведите в формат WebP. Второе - убедитесь, что картинка не ждёт загрузки шрифтов или скриптов. Атрибут fetchpriority='high' на главном изображении говорит браузеру грузить его первым. Третье - если хостинг дешёвый, сервер может отвечать по 2 секунды. Замерьте TTFB (Time to First Byte) в PageSpeed: если больше 600 мс, переезжайте на нормальный хостинг или подключите CDN.

INP растёт от тяжёлого JavaScript. Если на странице висят счётчики аналитики, чаты, карты, пиксели ретаргетинга - всё это выполняется в одном потоке и блокирует интерфейс. Отложите загрузку скриптов через атрибут defer или async. Уберите лишние виджеты: если чат не приносит заявок, он просто крадёт миллисекунды. Попросите разработчика показать Performance-профиль в Chrome - там видно, какой скрипт тормозит сильнее всего.

CLS возникает, когда у картинок, баннеров и iframe нет заданных размеров. Браузер резервирует место под контент, только если знает его высоту и ширину заранее. Пропишите атрибуты width и height для каждого изображения. Если на сайте есть баннер вверху страницы - зарезервируйте под него фиксированную высоту в CSS, даже если он подгружается с задержкой. То же с embed-блоками: YouTube, карты, формы - всё должно иметь контейнер с фиксированным aspect-ratio.

Частые ошибки, которые убивают скорость сайта

Неоптимизированные шрифты. Если шрифт весит 400 КБ и загружается с Google Fonts без preconnect, страница провисает на секунду. Решение: подключите только нужные начертания (regular и bold, не все девять), добавьте &display=swap в URL шрифта, пропишите <link rel='preconnect'> для fonts.googleapis.com.

Слайдеры и карусели. Они красивые, но жрут ресурсы: тяжёлые библиотеки, автопроигрывание, предзагрузка всех слайдов сразу. Если слайдер на главном экране, он съедает LCP. Если он вообще не нужен - уберите. Один статичный экран с сильным оффером работает лучше пяти крутящихся.

Блокирующий CSS. Если стили лежат в огромном файле, браузер не начнёт рисовать страницу, пока не скачает всё. Критичные стили (шрифты, раскладка первого экрана) можно встроить inline в <head>, остальное - подгружать отдельным файлом.

Редиректы. Каждый редирект добавляет 200-400 мс. Если посетитель попадает на http://site.ru, оттуда летит на https://site.ru, затем на https://www.site.ru - это три круга ожидания. Настройте редирект в один прыжок на финальный URL.

Что делать, если Core Web Vitals не чинятся

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

В этом случае выбор простой: либо мириться с низкой скоростью и терять позиции, либо переписывать сайт на быстром стеке. Мы в EFIMOV DEV делаем сайты на React - он позволяет грузить только нужные компоненты, рендерить страницы на сервере и держать метрики в зелёной зоне даже на сложных проектах. Это дороже готового шаблона, зато сайт не тормозит, Google его любит, а конверсия не сливается на старте.

Если полностью переписывать не готовы - начните с аудита. Попросите разработчика снять профиль загрузки в Lighthouse и показать, где именно теряются секунды. Может оказаться, что 80% времени съедает один виджет, который можно заменить лёгким аналогом или вообще убрать.

Как поддерживать скорость сайта после запуска

Core Web Vitals - это не разовая задача. Добавили новый блок, поставили плагин, сменили баннер - метрики могут упасть. Настройте еженедельный мониторинг через Google Search Console или сторонний сервис вроде Calibre, SpeedCurve. Если метрика ушла из зелёной зоны в жёлтую - ищите, что изменилось за последнюю неделю.

Вторая точка контроля - перед каждым крупным обновлением. Добавляете новый раздел, интеграцию, форму - прогоните страницу через PageSpeed до и после. Если LCP вырос на секунду, правка требует оптимизации, прежде чем выкатывать её на всех посетителей.

Третье: если сайт на WordPress или другой CMS - обновления плагинов и темы тоже могут сломать скорость. После обновления всегда проверяйте метрики. Один «безобидный» плагин может добавить три новых запроса к базе данных на каждую страницу.