Термин Core Web Vitals пугает нетехнического владельца бизнеса больше, чем должен. По сути это три конкретных вопроса, которые Google задаёт про любую страницу: быстро ли она показывает главный контент, быстро ли отвечает на действия пользователя и не «прыгает» ли вёрстка во время загрузки. Для каждого вопроса есть измеримая метрика, и все три вместе формируют то, что Google называет «page experience» — часть сигналов ранжирования, работающая как своеобразный тай-брейкер между сайтами примерно одинакового качества по содержанию.
Идея простая: если два сайта отвечают на запрос примерно одинаково хорошо по содержанию, но один открывается за секунду, а другой — за восемь, с прыгающей вёрсткой и подвисающими кнопками, то с точки зрения пользователя это два очень разных опыта, даже если тексты на них написаны одинаково грамотно. Google формализовал это ощущение в три измеримые метрики, чтобы у него — и у владельцев сайтов — был не субъективный, а конкретный, воспроизводимый способ оценить, насколько комфортно пользоваться страницей.
Largest Contentful Paint измеряет время, за которое в области видимости отрисовывается самый крупный элемент — обычно это hero-изображение, баннер или заголовок первого экрана. Хорошим считается результат до 2,5 секунды. Типичные причины плохого LCP:
На практике LCP почти всегда лечится комбинацией: сжатие и конвертация изображений, правильный порядок загрузки ресурсов (критический CSS — инлайном, остальное — асинхронно) и включённое серверное кэширование.
Interaction to Next Paint в 2024 году заменил метрику FID и оценивает, сколько времени проходит между действием пользователя (клик, тап, ввод текста) и видимой реакцией интерфейса на протяжении всего визита, а не только при первом взаимодействии. Хороший результат — до 200 миллисекунд. Плохой INP почти всегда означает, что главный поток браузера занят выполнением тяжёлого JavaScript — часто это сторонние виджеты (чаты, счётчики, рекламные скрипты) или неоптимизированные обработчики событий в самом шаблоне сайта. Здесь же тесно связана метрика TBT (Total Blocking Time) из лабораторных тестов — она показывает суммарное время, когда главный поток был заблокирован длинными задачами дольше 50 мс, и хорошо предсказывает будущий INP ещё до того, как у сайта накопится реальная пользовательская статистика. На практике высокий TBT почти всегда означает, что на странице одновременно инициализируется слишком много independent-скриптов — от чат-виджета до нескольких разных счётчиков аналитики, каждый из которых блокирует поток на десятки миллисекунд.
Cumulative Layout Shift измеряет суммарное смещение видимых элементов на странице во время загрузки — тот самый неприятный эффект, когда пользователь уже начал читать текст или тянется нажать на кнопку, а страница вдруг «прыгает» из-за подгрузившейся картинки или рекламного блока. Хороший показатель — до 0,1. Главные причины: изображения и видео без явно заданных width/height (браузер не может заранее зарезервировать место), шрифты, которые заменяют системный шрифт после загрузки и меняют размеры текста, и динамически вставляемые баннеры без зарезервированного контейнера.
Здесь часто возникает путаница: почему в PageSpeed Insights одни цифры, а в Google Search Console — другие? PageSpeed Insights и Lighthouse показывают лабораторные данные — результат одного контролируемого замера на эмулированном устройстве и сети в конкретный момент. Search Console и сам CrUX (Chrome User Experience Report) показывают полевые данные — агрегированную статистику реальных визитов настоящих пользователей Chrome за последние 28 дней. Именно полевые данные, а не лабораторные, использует Google как фактический сигнал ранжирования: сайт может показывать отличный результат в разовом лабораторном тесте и при этом иметь плохие полевые метрики, если у значительной части аудитории медленный мобильный интернет или старые устройства. Проверять стоит оба источника, но ориентироваться в первую очередь на отчёт Core Web Vitals в Search Console — там метрики сгруппированы по типам страниц (шаблонам), что сразу показывает, какая именно группа URL проседает.
Важно понимать границы влияния: Core Web Vitals — это не решающий фактор ранжирования, который перевесит слабый контент или отсутствие релевантности запросу. Но при прочих равных — среди страниц с похожим по качеству контентом, отвечающих на один и тот же запрос — Google действительно отдаёт предпочтение странице с лучшим пользовательским опытом. Кроме того, плохие показатели напрямую бьют по поведенческим метрикам: медленная загрузка и «прыгающая» вёрстка увеличивают отказы и снижают время на сайте, а это уже вторичный, но вполне реальный сигнал.
На практике улучшение Core Web Vitals на Битрикс почти всегда начинается с одних и тех же шагов:
srcset для разных размеров экрана, а также loading="lazy" для всего, что не попадает в первый экран;font-display: swap для шрифтов;Все эти изменения не требуют переписывания сайта с нуля — это точечная, но требующая аккуратности работа с шаблонами и настройками кэширования, и именно так строится услуга ускорения сайта у нас в TruWeb: сначала измеряем текущие показатели по ключевым шаблонам страниц, потом устраняем конкретные узкие места, а не «оптимизируем на глаз».