Core Web Vitals: как улучшить LCP, FID и CLS и поднять позиции

Core Web Vitals не поднимают сайт в поиске одной настройкой. Они помогают убрать технические проблемы, из-за которых страница медленно появляется, долго реагирует или сдвигается во время загрузки. Для улучшения LCP, INP и CLS нужно ускорить первый экран, сократить работу JavaScript и заранее зарезервировать место под изображения, шрифты и виджеты.

Что такое Core Web Vitals и как они влияют на SEO

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

Раньше в таких материалах писали «LCP, FID и CLS». С марта 2024 года основной метрикой интерактивности стал INP, а FID убрали из набора Core Web Vitals. Старые рекомендации по FID объясняют похожую проблему, но для текущей проверки нужно смотреть именно INP.

Google использует лабораторные тесты и полевые данные реальных пользователей Chrome. В Search Console показатели формируются по накопленным посещениям, поэтому исправление сегодня не обязательно изменит отчёт завтра. Для коммерческого сайта нужно смотреть не только на оценку, но и на жалобы: медленно открывается каталог, прыгает кнопка заказа, не срабатывает форма.

Мобильная версия особенно важна для сайтов в Алматы, Астане и других городах Казахстана. Посетитель может прийти из поиска, 2GIS, рекламы или чата WhatsApp через нестабильную мобильную сеть. Тяжёлый баннер и несколько сторонних виджетов на телефоне часто создают больше проблем, чем объём текста на странице.

Как улучшить LCP и ускорить первый экран

Чтобы улучшить LCP, найдите крупнейший элемент первого экрана - изображение, заголовок, видео или текстовый блок. Чаще всего задержку создают баннеры, фоновые изображения, медленный сервер и CSS, блокирующий отрисовку. Цель для хорошего результата - показать главный контент не позднее 2,5 секунды в типичном мобильном сценарии.

LCP начинается с навигации и заканчивается появлением видимого крупнейшего элемента. Картинка может быть сжатой, но загружаться поздно: браузер сначала получает HTML, затем CSS, а изображение вставляется только после выполнения скрипта. Поэтому нужно проверять не один размер файла, а всю цепочку его появления.

• Сохраните изображения первого экрана в WebP или AVIF. Формат выбирайте после проверки качества: чрезмерное сжатие уменьшает файл, но портит фотографии и изображения товаров.
• Для главной картинки задайте width и height, подходящий srcset и приоритет fetchpriority="high", если именно этот элемент становится LCP.
• Не ставьте изображение первого экрана в lazy loading. Отложенная загрузка нужна для контента ниже первого экрана, а не для главного баннера.
• Уберите автозапуск видео на мобильных устройствах или замените его лёгким превью. Видео конкурирует с HTML, стилями и главным изображением за ресурсы.
• Проверьте время ответа сервера. Если HTML приходит медленно, одной оптимизацией изображений проблему не решить: понадобятся кэширование, настройка базы данных, серверного рендера или хостинга.

Отдельную проверку требуют фоновые изображения в CSS. Браузеру сложнее определить их приоритет, чем обычному img. Если картинка содержит смысл, лучше вывести её как элемент с заданными размерами. Если это только декор, его можно загрузить позже или заменить цветом на мобильном экране.

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

FID, INP и интерактивность: почему сайт тормозит после загрузки

FID больше не входит в основной набор Core Web Vitals, но проблема задержки интерфейса сохранилась. Сейчас её оценивают через INP - время между действием пользователя и следующим визуальным обновлением. Хорошим считается результат до 200 миллисекунд; тяжёлый JavaScript легко ухудшает его на недорогом телефоне.

Сайт может выглядеть загруженным, но не реагировать на меню, фильтр или кнопку «Купить». Главный поток браузера в это время занят длинной задачей: разбирает большой JavaScript-файл, строит DOM, пересчитывает стили или выполняет код стороннего сервиса.

• Разделите длинные задачи JavaScript на короткие части, чтобы браузер мог обработать действие пользователя между ними.
• Загружайте код фильтров, корзины и сложных компонентов только на страницах, где они нужны. Главной странице не нужно отправлять весь функционал магазина.
• Отложите чаты, пиксели рекламы, карты, аналитические виджеты и обратный звонок. Сначала должны стать доступными навигация и основная кнопка.
• Удалите неиспользуемые библиотеки, плагины и обработчики. Старые формы и трекеры нередко остаются в коде после смены маркетинговых инструментов.
• Не запускайте тяжёлые вычисления в главном потоке. Web Workers подходят для отдельных задач после профилирования, но не заменяют поиск причины.

Для интернет-магазина отдельно проверьте поиск, сортировку, фильтры, изменение количества товара и открытие корзины. Для лендинга - меню, форму заявки, маску телефона, калькулятор и переход в мессенджер. Kaspi, WhatsApp, 2GIS и системы аналитики нужно оценивать по пользе и нагрузке, а не подключать без проверки.

Тестируйте INP не только на мощном ноутбуке. В Chrome DevTools можно ограничить производительность и скорость сети. Ручная проверка на недорогом Android-смартфоне часто показывает задержки, которых не видно на рабочем компьютере.

Как убрать CLS и остановить скачки вёрстки

Чтобы улучшить CLS, браузеру нужно заранее знать размеры элементов, которые появятся после открытия страницы. Задайте размеры изображений, зарезервируйте место под рекламу и виджеты, настройте шрифты и не вставляйте новые блоки над уже читаемым контентом. Для хорошего результата CLS должен оставаться не выше 0,1.

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

• Указывайте width и height у img либо используйте CSS aspect-ratio. Браузер заранее выделит место и не сдвинет текст после загрузки файла.
• Подключайте шрифты с понятной стратегией отображения. font-display: swap уменьшает период невидимого текста, но может изменить начертание, поэтому проверяйте итоговый CLS.
• Резервируйте высоту рекламных блоков, баннеров, отзывов и рекомендаций. Пустое место обычно лучше, чем внезапный сдвиг всей страницы.
• Не вставляйте уведомление, чат или форму над уже загруженным контентом. Для фиксированных элементов заранее определите положение и размер.
• Для анимаций используйте transform и opacity, а не свойства, вызывающие постоянный перерасчёт разметки, например width, height, top и margin.

CLS может ухудшаться не только при первом открытии страницы. Сдвиг появляется после нажатия «Показать ещё», открытия фильтра или вывода сообщения об ошибке формы. Проверяйте реальные сценарии взаимодействия, а не только пустую загрузку главной страницы.

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

Как проверить Core Web Vitals на своём сайте

Начните с PageSpeed Insights и Search Console, затем подтвердите выводы в Chrome DevTools. PageSpeed разделяет лабораторные результаты и данные реальных пользователей, Search Console группирует URL по проблемам, а DevTools помогает найти конкретный файл, элемент или скрипт. Один инструмент показывает симптом, но не всегда объясняет причину.

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

• В поле данных смотрите LCP, INP и CLS за реальные посещения, а не только итоговый балл Lighthouse.
• В разделе возможностей проверяйте размер изображений, неиспользуемый JavaScript, блокирующие ресурсы и время ответа сервера.
• В Search Console откройте отчёт «Основные интернет-показатели» и найдите группы URL со статусами «Плохо» и «Требует улучшения».
• В DevTools включите Performance и Network, ограничьте скорость соединения, затем запишите сценарий загрузки и взаимодействия.
• После изменений очистите кэш, повторите тест на тех же шаблонах и запишите дату. Полевые данные обновляются не мгновенно.

Лабораторные данные удобны для поиска причины: они воспроизводимы и меняются вскоре после исправления. Полевые данные ближе к реальности, но требуют времени и достаточного числа посещений. Нельзя обещать, что отчёт Search Console улучшится на следующий день.

Зелёная оценка Lighthouse тоже не даёт полной картины. Страница может хорошо пройти лабораторный тест, но получить слабый INP у пользователей со старыми смартфонами, тяжёлыми рекламными скриптами или нестабильным соединением. Для оценки сайта нужны оба источника.

Что исправлять первым и сколько это может стоить

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

Цена отдельных технических работ зависит от CMS, количества шаблонов, доступа к серверу и состояния кода. Оптимизация изображений и удаление лишнего скрипта обычно проще, чем исправление архитектуры магазина с множеством конфликтующих плагинов. Точную стоимость мы фиксируем после брифа.

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

Если сайт создаётся с нуля, скорость лучше учитывать в архитектуре. Мы используем Next.js и React, планируем SEO-структуру до разработки шаблонов и учитываем мобильные сценарии. Домен .kz, хостинг и SSL на первый год входят в стоимость разработки; для хостинга обычно рекомендуем hoster.kz.

Хорошие Core Web Vitals не заменяют полезный контент, понятную услугу и удобную заявку. Они убирают технические препятствия, из-за которых посетитель не успевает увидеть предложение или нажать нужную кнопку.

Частые вопросы

Ниже собраны вопросы, которые возникают после проверки PageSpeed Insights и Search Console. Ответы помогают понять, когда достаточно точечной оптимизации, а когда проблема связана с архитектурой сайта, сторонними сервисами или особенностями полевых данных пользователей.

• Нужно ли улучшать Core Web Vitals, если сайт уже находится в топе? Да, особенно при близких показателях конкурентов. Метрики не обнуляют SEO, но плохой опыт может снижать удобство и конверсию.
• FID исчез, или его всё ещё нужно измерять? В текущем наборе Google основной метрикой интерактивности стал INP. Старые рекомендации по FID объясняют проблему, но ориентироваться нужно на INP.
• Можно ли улучшить LCP только сжатием картинок? Иногда, но не всегда. Если медленно отвечает сервер, изображение вставляется JavaScript или CSS блокирует загрузку, одного WebP будет недостаточно.
• Почему в PageSpeed хороший результат, а в Search Console плохой? Lighthouse показывает лабораторный сценарий, а Search Console использует полевые данные. У этих источников разные устройства, сети и история посещений.
• Мешают ли Core Web Vitals виджеты Kaspi, WhatsApp, 2GIS и онлайн-чат? Могут мешать, если загружаются рано или выполняют тяжёлый JavaScript. Их нужно отложить и проверить влияние на LCP, INP и CLS.
• Как часто проверять показатели? После крупного обновления, установки плагина или добавления виджета проведите лабораторный тест. Полевые данные и Search Console отслеживайте регулярно на коммерческих страницах.

С чего начать улучшение сайта

Соберите пять URL: главную, важную услугу, контакты, каталог или карточку товара и страницу с формой. Проверьте их на мобильном сценарии, запишите LCP, INP, CLS, причины проблем и число затронутых страниц. Не меняйте всё сразу: иначе будет трудно понять, какое исправление дало результат.

Сначала исправляйте повторяющиеся причины: размеры и форматы изображений, блокирующие ресурсы, лишние скрипты, отсутствие резервного места и медленный ответ сервера. Техническая поддержка у нас начинается от 50 000 ₸ в месяц. Для нового или устаревшего сайта можно обсудить редизайн либо разработку с гарантией 12 месяцев и двумя бесплатными кругами правок.