Core Web Vitals: как улучшить показатели и поднять сайт в Google
Разбираем метрики LCP, INP и CLS, показываем, как отличить лабораторный тест от данных реальных пользователей и составить план ускорения сайта без бесполезной гонки за максимальным баллом PageSpeed.

Чтобы улучшить Core Web Vitals, сначала проверьте реальные страницы в Search Console и PageSpeed Insights, затем исправьте самые тяжёлые изображения, блокирующие скрипты и сдвиги макета. Хороший результат - не «100 баллов», а быстрый первый экран, отзывчивые формы и стабильная мобильная страница, которая помогает пользователю выполнить нужное действие.
Что такое Core Web Vitals и зачем они бизнесу
Core Web Vitals помогают оценить три свойства страницы: скорость появления основного содержимого, реакцию интерфейса на действия и стабильность макета. Google учитывает эти сигналы вместе с релевантностью, качеством контента и технической исправностью сайта. Для бизнеса показатели важны потому, что задержка мешает человеку найти услугу и отправить заявку.
Посетитель может открыть сайт с телефона в мобильной сети, в дороге или внутри здания с нестабильным соединением. Если первый экран долго пустует, кнопка не реагирует, а форма смещается во время загрузки, человек закрывает вкладку. Причину он обычно не сообщает - просто возвращается к поиску и выбирает другой вариант.
Проверка скорости не заменяет оценку всей страницы. На восприятие влияют HTTPS, мобильная адаптация, понятная навигация и отсутствие элементов, которые перекрывают содержимое. Бесполезно ускорять одну картинку, если на телефоне невозможно прочитать текст, открыть меню или найти номер телефона.
LCP, INP и CLS: какие показатели нужно улучшить
Для первичной оценки ориентируйтесь на три порога: LCP до 2,5 секунды, INP менее 200 миллисекунд и CLS ниже 0,1. Пограничные значения не означают катастрофу, но показывают запас для улучшения. Проверяйте не только главную, а шаблоны услуг, товаров, контактов, корзины и страниц с формами.
| Метрика | Что видит посетитель | Хороший результат | Частая причина проблемы |
|---|---|---|---|
| LCP | Когда появляется самый крупный элемент первого экрана | До 2,5 с | Тяжёлое изображение, медленный сервер, блокирующие стили |
| INP | Как быстро сайт реагирует на клик, нажатие или ввод | До 200 мс | Перегруженный JavaScript, виджеты, сложная логика формы |
| CLS | Сдвигаются ли элементы во время загрузки | Ниже 0,1 | Медиа без размеров, баннеры, шрифты без резерва места |
LCP обычно связан с главным изображением, крупным заголовком или блоком, который занимает большую часть первого экрана. Если баннер весит несколько мегабайт, сервер отвечает медленно, а шрифт ждёт загрузки, содержимое появляется поздно. Главное изображение не стоит бездумно отправлять в lazy loading: для него может потребоваться приоритетная загрузка.
INP оценивает не только первое нажатие, а взаимодействия в течение посещения. В него попадают открытие меню, выбор варианта в форме, фильтрация товаров и работа калькулятора. Страница способна быстро показать текст и при этом медленно реагировать на клик из-за тяжёлого скрипта или длинных задач JavaScript.
CLS возникает, когда уже показанный контент неожиданно сдвигается. Например, пользователь нажимает кнопку, а в этот момент сверху появляется баннер. На мобильном такой сдвиг особенно неприятен: он приводит к ошибочным кликам и создаёт ощущение, что сайт работает ненадёжно.
Как проверить Core Web Vitals своего сайта
Начните с Search Console и PageSpeed Insights, но не делайте вывод по одному лабораторному баллу. Search Console показывает полевые данные по группам страниц, а PageSpeed Insights объединяет данные реальных пользователей с тестом в заданных условиях. Для объективной картины нужны несколько URL, мобильная проверка и повторные измерения.
- Search Console - откройте отчёт «Основные веб-показатели» и посмотрите, какие группы URL имеют статус «плохо» или «требует улучшения». Эти данные отражают реальные устройства, браузеры и соединения посетителей.
- PageSpeed Insights - проверьте мобильную и десктопную версии отдельно. Помимо общей оценки изучите блоки LCP element, render-blocking resources, unused JavaScript и layout shifts.
- Lighthouse в Chrome - удобен после каждой правки на тестовом сайте. Результат зависит от условий запуска, поэтому сравнивайте серию тестов, выполненных по одной схеме.
- WebPageTest или GTmetrix - помогают рассмотреть последовательность запросов: какой файл задерживает страницу, когда приходит шрифт и сколько занимает ответ сервера.
Полевые и лабораторные данные отвечают на разные вопросы. Лабораторный тест показывает поведение страницы в заданном сценарии, а реальные данные отражают разнообразие устройств и сетей. Если в Search Console ещё нет достаточного объёма данных, используйте Lighthouse для поиска проблем, но не называйте его окончательным результатом для всей аудитории.
Проверяйте несколько типов URL. Для магазина это главная, категория, карточка товара и корзина. Для компании услуг - главная, конкретная услуга, контакты и форма заявки. Одна быстрая главная не исправит медленные страницы, на которые люди приходят из поиска или рекламных объявлений.
Почему Core Web Vitals остаются плохими
Плохие показатели обычно появляются из-за цепочки причин: тяжёлый первый экран, медленный ответ сервера, лишние скрипты и неучтённые мобильные сценарии. Исправлять их лучше по влиянию на LCP, INP и CLS, а не подряд включать все рекомендации PageSpeed. Сначала найдите узкое место, затем проверьте результат после конкретного изменения.
- Изображения загружены в исходном размере, хотя блоку нужен файл значительно меньше. Фотографии без сжатия быстро увеличивают вес страницы.
- Главное изображение отправлено в lazy loading. Для контента ниже первого экрана это полезно, но LCP-элемент должен получать подходящий приоритет.
- В шапке одновременно работают чаты, аналитика, карты, пиксели и виджеты обратного звонка. Каждый скрипт расходует процессорное время на смартфоне.
- Сайт на CMS годами обрастал расширениями. Неиспользуемый модуль может продолжать подключать CSS или JavaScript на всех страницах.
- У изображений, видео, iframe и баннеров не задано соотношение сторон или резервируемая высота. Браузер не знает, сколько места оставить до загрузки.
- Сервер отвечает медленно. В этом случае сжатие картинок не устранит задержку до первого байта, поэтому нужно отдельно проверять хостинг, кеширование и серверную логику.
- CSS и JavaScript блокируют построение страницы. Браузер ждёт тяжёлые файлы вместо того, чтобы показать готовый текст и структуру.
Отдельная проблема - неверная цель оптимизации. Требование получить «зелёный» PageSpeed на каждой странице может привести к удалению полезного функционала. Если на сайте есть каталог, калькулятор или форма, важнее проверить конкретный сценарий: человек должен увидеть услугу, открыть меню, выбрать вариант и отправить заявку без заметной задержки.
Как улучшить показатели Core Web Vitals на практике
Начинайте с изменений, которые уменьшают вес и задержки без перестройки всего сайта. Сожмите медиа, задайте размеры, уберите лишние подключения и проверьте кеширование. Если причина в монолитном JavaScript, старой CMS или серверном рендеринге, потребуется разработчик. После каждой группы изменений повторяйте тест и проверяйте, не пострадали ли формы и аналитика.
- Конвертируйте фотографии в WebP или AVIF, отдавайте подходящий размер через responsive images и не загружайте файл шириной 4000 пикселей для блока на 500 пикселей.
- Оставьте lazy loading для изображений ниже первого экрана. Для LCP-элемента задайте приоритетную загрузку только после проверки, что это действительно главный визуальный блок.
- Пропишите width и height либо aspect-ratio для изображений, видео, iframe и рекламных мест. Браузер заранее зарезервирует пространство, и CLS снизится.
- Настройте кеширование браузера, сжатие Brotli или GZIP и корректные заголовки для статических файлов. Проверяйте результат в браузере, а не только в панели хостинга.
- Перенесите некритичные скрипты из блокирующей части загрузки, используйте defer там, где это безопасно, и удалите функции, которыми никто не пользуется.
- Ограничьте сторонние сервисы. Карта, чат и рекламные пиксели должны загружаться в нужном сценарии, а не одновременно на каждой странице.
- Оставьте минимум начертаний шрифта, используйте font-display: swap и не подключайте несколько файлов ради одного заголовка.
- Проверьте серверный рендеринг, статическую генерацию и размер JavaScript-бандлов. В новых проектах на Next.js и React такие решения лучше предусмотреть до публикации, а не добавлять после жалоб на скорость.
CDN может сократить задержку доставки для пользователей из разных городов, но не исправит тяжёлый код и лишние запросы. Для аудитории в Казахстане проверьте, где расположен сервер, как он отвечает из разных регионов и не ломается ли кеширование динамических страниц.
После изменений сохраняйте исходные показатели и список правок. Иначе через месяц будет трудно понять, помогло ли сжатие изображений или новый виджет одновременно ухудшил INP. На рабочем сайте не стоит в один день менять сервер, тему, расширения и рекламные скрипты: при проблеме не останется понятной причины.
Почему мобильная версия важнее идеального десктопа
Мобильную версию стоит проверять первой, если клиенты ищут компанию с телефона, открывают карту, звонят или пишут в мессенджер. Хороший десктопный результат не компенсирует мелкий текст, горизонтальную прокрутку, перекрытую кнопку и тяжёлый первый экран. Именно мобильный сценарий часто показывает, где скорость превращается в потерянное обращение.
Проверяйте не только загрузку, но и путь до контакта. На телефоне пользователь должен быстро увидеть город работы, адрес, режим, номер и понятную кнопку. Если компания продвигается в Алматы, сведения на сайте должны совпадать с профилями на локальных площадках, иначе скорость не устранит недоверие к данным.
Для магазина добавляются фильтры, варианты товара, корзина и онлайн-оплата. Платёжный элемент не должен появляться с задержкой или сдвигать содержимое. Скрипт оплаты можно загружать в момент, когда он нужен, но после этого нужно проверить сам сценарий покупки на реальном телефоне.
Не жертвуйте понятностью ради лабораторной оценки. Удаление всех фотографий, карты или пояснений может улучшить тест, но снизить доверие и число обращений. Хорошая оптимизация уменьшает технический вес страницы, а не полезную информацию для клиента.
Сколько стоит улучшить Core Web Vitals и когда ждать эффект
Стоимость зависит от причины: иногда достаточно точечных технических изменений, а иногда разумнее переработать шаблон или сайт. До сметы нужны URL, используемая CMS, доступ к Search Console и список проблем. Без диагностики нельзя честно обещать фиксированную цену или назвать срок, за который изменятся позиции в Google.
| Вариант работы | Ориентир по стоимости | Срок или формат |
|---|---|---|
| Поддержка и точечные доработки | От 50 000 ₸ в месяц | Ежемесячная услуга; подходит для постепенной оптимизации |
| SEO-продвижение с техническими задачами | От 250 000 ₸ в месяц | Ежемесячная работа; объём определяется после аудита |
| Редизайн сайта | От 350 000 ₸ | От 14 дней; нужен при проблемах интерфейса и шаблонов |
| Новый корпоративный сайт | От 500 000 ₸ | От 21 дня; SEO-структура и скорость закладываются при разработке |
Лабораторные показатели могут измениться в тот же день после правок и очистки кеша. Данные реальных пользователей в Search Console обновляются постепенно, поскольку системе нужно собрать новые посещения. Позиции зависят не только от Core Web Vitals, поэтому обещание роста через конкретное число дней было бы некорректным.
Если сайт построен на устаревшей теме, содержит много расширений и работает на нестабильном сервере, отдельная оптимизация может превратиться в исправление симптомов. В такой ситуации редизайн или новая разработка иногда рациональнее. При разработке нового проекта домен .kz, хостинг и SSL на первый год входят в стоимость; мы рекомендуем hoster.kz.
Перед заказом работ запросите не обещание «вывести PageSpeed в зелёную зону», а план измерений. В нём должны быть URL, исходные значения, список изменений, критерии приёмки и способ проверки после релиза. Такой документ помогает отделить реальное улучшение сайта от случайного удачного запуска теста.
- Какие страницы и устройства будут проверяться до и после работ?
- Какая причина ухудшает LCP, INP или CLS и чем это подтверждено?
- Какие сторонние скрипты останутся, а какие будут удалены или отложены?
- Как изменения повлияют на формы, оплату, аналитику, карты и рекламные пиксели?
- Кто будет следить за показателями после обновления CMS или дизайна?
- Что входит в цену, а что считается отдельной разработкой?
Частые вопросы
Ниже - короткие ответы на вопросы, которые чаще всего возникают при проверке скорости. Они помогают выбрать правильную цель, понять ограничения инструментов и не тратить бюджет на изменения, которые улучшают только лабораторную цифру, но не делают страницу удобнее для реального посетителя.
- Нужно ли добиваться 100 баллов в PageSpeed? Нет. Цель - хорошие полевые показатели и удобный путь пользователя, а не максимальная цифра в лабораторном тесте.
- Может ли высокая скорость сама по себе поднять сайт в Google? Нет. Core Web Vitals - один из сигналов. Нужны релевантный контент, понятная структура, мобильная адаптация и техническая исправность.
- Почему PageSpeed показывает разные результаты утром и вечером? Лабораторный тест зависит от нагрузки, сети, сервера и сторонних сервисов. Смотрите серию тестов и сравнивайте одинаковые условия.
- Нужно ли менять сайт, если в Search Console пока нет данных? Не обязательно. Начните с Lighthouse и полевых проверок, а после накопления трафика сопоставьте результат с реальными данными.
- Поможет ли CDN старому сайту? Иногда он сокращает задержку доставки, но не убирает лишний JavaScript, тяжёлую тему или ошибки CLS. Сначала найдите причину, затем выбирайте инфраструктурное решение.
- Можно ли исправить Core Web Vitals без разработчика? Сжать изображения и убрать лишний виджет иногда получится самостоятельно. Изменения в сборке, сервере, рендеринге и платёжных сценариях лучше поручить специалисту.
С чего начать оптимизацию сайта
Соберите список важных URL, проверьте мобильную версию в PageSpeed Insights и откройте отчёт Core Web Vitals в Search Console. Зафиксируйте LCP, INP, CLS, время ответа сервера и вес страницы. Затем расставьте задачи по влиянию на заявки: сначала исправляйте задержки, которые мешают увидеть услугу, нажать кнопку и отправить форму.
Мы в Pozhidayev проводим техническую оценку, помогаем с поддержкой от 50 000 ₸ в месяц и закладываем скорость в новые сайты на Next.js и React. Работаем из Алматы с компаниями по всему Казахстану удалённо. После брифа фиксируем цену, даём гарантию на проект 12 месяцев и два бесплатных круга правок.



