Посетитель пришёл на сайт, но страница не открылась; нажал кнопку — реакции нет; начал читать — и текст уехал вниз. У каждого из этих трёх маленьких разочарований в Google есть название: Core Web Vitals. Самый понятный способ измерить и улучшить скорость сайта лежит через эти три метрики.
В этой статье мы рассказываем, что такое Core Web Vitals, каковы актуальные «хорошие» пороги метрик LCP, INP и CLS, какими инструментами и как правильно их измерять и какие улучшения дают наибольший эффект для каждой из них.
Даже без технической команды к концу статьи вы сможете сами проверить состояние сайта и задать правильные вопросы агентству или разработчику.
Почему скорость сайта важна и для клиентов, и для SEO?
Медленный сайт прежде всего теряет пользователя. Посетитель, который несколько секунд смотрит на пустой экран при мобильном соединении, возвращается к поиску и кликает на следующий результат. Для трафика, привлечённого рекламой, это прямая потеря денег.
Со стороны Google Core Web Vitals входят в число сигналов, которые системы ранжирования учитывают в рамках «удобства страницы». Google Search Central говорит об этом прямо, но в том же документе подчёркивает, что релевантность контента по-прежнему гораздо важнее. То есть быстрая страница со слабым контентом наверх не поднимется, а вот между двумя страницами схожего качества удобство может стать решающим.
Скорость сама по себе не сделает вас первым, но медлительность легко отбросит вас назад.
Метрики Core Web Vitals и пороговые значения 2026 года
Core Web Vitals состоят из трёх метрик. Каждая измеряет свою сторону пользовательского опыта: загрузку, интерактивность и визуальную стабильность.
| Метрика | Что измеряет? | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Время появления на экране самого большого изображения или текстового блока страницы | ≤ 2,5 с | 2,5–4 с | > 4 с |
| INP (Interaction to Next Paint) | Время визуального отклика страницы на клики, касания и нажатия клавиш | ≤ 200 мс | 200–500 мс | > 500 мс |
| CLS (Cumulative Layout Shift) | Неожиданные сдвиги элементов при загрузке и использовании страницы | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Важная деталь: Google оценивает эти значения по 75-му процентилю реальных пользователей. То есть не менее 75 процентов посещений должны укладываться в «хороший» порог. Чтобы страница прошла Core Web Vitals, все три метрики должны быть хорошими; если одна плохая, среднее не считается.
Как измерять Core Web Vitals: полевые и лабораторные данные
Самая частая ошибка — принимать решение по одному баллу PageSpeed. Существует два типа данных, и они говорят о разном:
- Полевые данные (field data): данные Chrome UX Report (CrUX), собранные из реального опыта пользователей Chrome. Именно их Google учитывает при ранжировании; они отражают среднее за последние 28 дней.
- Лабораторные данные (lab data): тест Lighthouse на одном смоделированном устройстве и соединении. Идеален для диагностики проблем, но не отражает реальный пользовательский опыт один в один. INP он измерить напрямую не может; вместо неё смотрят на Total Blocking Time (TBT).
Какой инструмент для чего использовать?
- PageSpeed Insights: показывает для одного адреса и полевые, и лабораторные данные. Ориентируйтесь на верхний раздел «реальный опыт пользователей».
- Search Console — отчёт Core Web Vitals: делит весь сайт на группы похожих страниц и показывает, какие URL слабые на мобильных и десктопе.
- Chrome DevTools (панель Performance): инструмент разработчиков, чтобы построчно находить причины медленных взаимодействий и сдвигов.
- Библиотека web-vitals: небольшая JavaScript-библиотека от Google для отправки замеров реальных пользователей в вашу систему аналитики.
Как улучшить LCP: показывайте основной контент быстрее
На большинстве корпоративных сайтов элемент LCP — это большое изображение в верхней части страницы (hero) или главный заголовок. Время LCP складывается из четырёх частей: первый ответ сервера (TTFB), обнаружение ресурса, загрузка ресурса и отрисовка на экране. Улучшать нужно в том же порядке.
- Ускорьте ответ сервера: web.dev считает хорошим TTFB 0,8 секунды и меньше. Кеширование страниц, качественный хостинг и CDN заметно сокращают это время.
- Дайте браузеру рано обнаружить изображение LCP: указывайте его прямо в HTML, а не через фон CSS или JavaScript; повышайте приоритет с помощью fetchpriority="high".
- Не применяйте lazy loading к верхнему изображению: ленивая загрузка предназначена для изображений ниже первого экрана; для главного изображения она задерживает LCP.
- Уменьшите изображение: форматы WebP или AVIF, правильный размер и srcset избавят от загрузки лишне больших файлов на мобильных.
- Сократите ресурсы, блокирующие отрисовку: выносите критический CSS вперёд, удаляйте неиспользуемый CSS и синхронно загружаемые скрипты, используйте font-display: swap для шрифтов.
О влиянии решений по хостингу на скорость мы рассказали в статье о выборе домена и хостинга.
Как улучшить INP: мгновенно реагируйте на клики
Проблема с INP обычно возникает из-за того, что основной поток браузера (main thread) занят JavaScript. Пользователь касается меню, но браузер в этот момент выполняет скрипт аналитики или громоздкий код слайдера, и отклик задерживается.
- Разбивайте длинные задачи: делите задачи JavaScript длиннее 50 мс на части; сначала дайте пользователю визуальный отклик, а тяжёлую работу выполните потом.
- Проверьте сторонние скрипты: чат-виджеты, инструменты тепловых карт, несколько рекламных и аналитических тегов — самые частые виновники плохого INP. Оставьте то, чем действительно пользуетесь, остальное загружайте отложенно.
- Держите DOM небольшим: на страницах с тысячами элементов перерисовка после каждого взаимодействия обходится дорого.
- Уменьшите нагрузку от плагинов и тем: неиспользуемый код, который готовые темы подгружают на каждой странице, замедляет взаимодействие, особенно на слабых телефонах.
Здесь решающим становится выбор платформы. О разнице между сайтом, разрастающимся за счёт плагинов, и лёгким сайтом, написанным под конкретные задачи, читайте в статье WordPress или заказная разработка.
Как улучшить CLS: не допускайте сдвигов страницы
Строка, которую вы читаете, внезапно уезжает вниз, или кнопка смещается в момент нажатия — именно это измеряет CLS. К счастью, решения обычно простые:
- Задавайте размеры изображениям и видео: с атрибутами width и height или CSS aspect-ratio браузер заранее резервирует место.
- Резервируйте фиксированное место под рекламу, баннеры и встраиваемый контент: подгружаемое позже уведомление о cookie или акционная полоса не должны сдвигать контент; пусть открываются поверх (overlay).
- Смягчите смену шрифта: предзагружайте веб-шрифт и подбирайте метрики запасного шрифта близкими к нему.
- Используйте transform в анимациях: анимируйте через transform и opacity, а не свойства, влияющие на макет, вроде top, left, height.
Самые частые проблемы со скоростью по типам сайтов
Не каждый сайт тормозит по одной и той же причине. Если обобщить картину, которую мы видим в проектах, по типам сайтов:
| Тип сайта | Самая частая проблема | С чего начать проверку |
|---|---|---|
| Корпоративный сайт на готовой теме | Тяжёлая тема, множество плагинов, большие изображения слайдера | Неиспользуемые плагины, размер главного изображения, кеширование страниц |
| Интернет-магазин | Фото товаров, фильтры, множество трекинговых и маркетинговых тегов | LCP страницы категории, сторонние скрипты, INP взаимодействий с корзиной |
| Одностраничное приложение (React, Vue и т. п.) | Большие JavaScript-бандлы, поздняя сборка контента в браузере | Серверный рендеринг или пре-рендеринг, разделение кода |
| Новостной сайт и блог | Рекламные блоки подгружаются позже и сдвигают контент | Фиксированные области под рекламные слоты, CLS |
Эта таблица — отправная точка; точный диагноз всегда ставится по замерам. Тем не менее, понимание того, где вероятнее всего проблема, экономит время в разговоре с разработчиком. Например, если в интернет-магазине карточка товара быстрая, а страница категории медленная, проблема чаще всего в том, что десятки изображений в списке загружаются одновременно и в полном размере.
Если вы стремитесь к быстрому и лёгкому опыту, похожему на мобильное приложение, это нужно обсуждать на этапе дизайна. Каждая «маленькая» функция, добавленная на страницу позже, отнимает долю бюджета скорости.
Пошаговый план ускорения сайта
Вместо того чтобы исправлять всё сразу, начните с того, что даст наибольший эффект:
- Шаг 1 — откройте отчёт Core Web Vitals в Search Console и выпишите группы страниц со статусом «плохо» на мобильных.
- Шаг 2 — протестируйте по одному адресу из каждой группы в PageSpeed Insights и отметьте, какая метрика проваливается.
- Шаг 3 — сначала решайте проблемы на уровне шаблона: сотни страниц на одном шаблоне улучшатся одним исправлением.
- Шаг 4 — примените быстрые улучшения: изображения, кеширование, CDN; затем переходите к JavaScript и сторонним скриптам.
- Шаг 5 — нажмите «Проверить исправление» в Search Console и подождите, пока полевые данные обновятся в течение 28 дней.
Скорость — не разовый проект, а бюджет, который нужно постоянно беречь. Новый плагин, большое изображение или дополнительный код отслеживания могут свести достижения на нет за несколько недель. Поэтому перед добавлением каждой новой функции спрашивайте: «Насколько это замедлит страницу?» Если хотите увидеть место скорости в поисковой видимости в более широком контексте, загляните также в наш чек-лист по техническому SEO.
- LCP на мобильных меньше 2,5 секунды?
- INP меньше 200 мс, лишние сторонние скрипты удалены?
- CLS меньше 0,1, у всех изображений заданы размеры?
- Главное изображение загружается приоритетно и без lazy loading?
- Изображения в WebP/AVIF и правильного размера?
- Включены ли кеширование страниц, сжатие и CDN?
- Регулярно ли отслеживается отчёт Core Web Vitals в Search Console?
Частые вопросы
Что такое Core Web Vitals?
Core Web Vitals — три метрики, которые Google определил для измерения реального пользовательского опыта: LCP для скорости загрузки, INP для отклика на взаимодействие и CLS для визуальной стабильности. Эти метрики используются в оценке удобства страниц Google.
Какое значение LCP считается хорошим?
По Google, LCP 2,5 секунды и меньше считается хорошим, более 4 секунд — плохим. Оценка проводится по 75-му процентилю реальных посещений пользователей.
Почему INP заменила FID?
FID измеряла только задержку первого взаимодействия на странице, и большинство сайтов легко проходили этот тест. INP отслеживает все взаимодействия на странице и сообщает об одном из самых медленных, поэтому лучше отражает реальный опыт пользователя. Изменение вступило в силу в марте 2024 года.
Если балл PageSpeed не 100, моё SEO будет плохим?
Нет. Балл Lighthouse — это лабораторный тест и не прямой сигнал ранжирования. Важно, чтобы в данных реальных пользователей значения LCP, INP и CLS укладывались в хорошие пороги. Страница с баллом 85, но хорошими полевыми данными значит больше, чем тест со 100 баллами.
Когда отражаются исправления Core Web Vitals?
Поскольку полевые данные основаны на опыте пользователей за последние 28 дней, полное отражение исправлений в отчётах занимает около четырёх недель. В лабораторных тестах улучшение видно сразу.
В заключение
Core Web Vitals сводят ощущения посетителя от сайта к трём числам: основной контент появляется за 2,5 секунды, каждый клик получает отклик за 200 миллисекунд, сдвиг страницы меньше 0,1. Эти цели чаще всего требуют не дорогой переделки, а правильной диагностики и дисциплинированных небольших исправлений.
В CYF Tech мы с самого начала проектируем сайты и веб-приложения с учётом бюджета скорости, а для существующих сайтов проводим анализ и улучшение Core Web Vitals. Если хотите вместе выяснить, почему ваш сайт медленный, свяжитесь с нами.
- web.dev — Web Vitals
- web.dev — How the Core Web Vitals metrics thresholds were defined
- web.dev — Largest Contentful Paint (LCP)
- web.dev — Interaction to Next Paint (INP)
- web.dev — Cumulative Layout Shift (CLS)
- web.dev — Time to First Byte (TTFB)
- Google Search Central — Understanding Core Web Vitals and Google search results
- Google Search Central — Understanding page experience