Core Web Vitals — три метрики Google, которыми он оценивает, насколько сайтом комфортно пользоваться. Они входят в факторы ранжирования, но важнее другое: это единственные метрики скорости, которые измеряются на реальных посетителях, а не в лаборатории.
Ниже — что означает каждая, какие пороги считаются нормой и почему типовой совет «сожмите картинки» часто не решает проблему. С замерами нашего собственного сайта, включая то, что у нас самих сделано плохо.
Три метрики
LCP — Largest Contentful Paint
Время до отрисовки самого крупного элемента в видимой области: обычно это главная картинка или заголовок. Отвечает на вопрос «когда посетитель увидел то, за чем пришёл».
Норма — до 2,5 секунды. От 2,5 до 4 — «требует улучшения», больше 4 — плохо.
INP — Interaction to Next Paint
Задержка между действием посетителя и реакцией страницы: нажал кнопку — через сколько что-то произошло. Заменил прежнюю метрику FID в 2024 году и оценивает не первое взаимодействие, а все за сессию.
Норма — до 200 миллисекунд. Хуже 500 — плохо.
CLS — Cumulative Layout Shift
Насколько скачет вёрстка при загрузке. Классический случай: человек целится в ссылку, сверху догружается баннер, страница уезжает вниз, палец попадает не туда.
Норма — до 0,1. Больше 0,25 — плохо.
Где смотреть свои цифры
Разделяйте два типа данных.
Лабораторные — PageSpeed Insights, Lighthouse в браузере. Синтетический прогон на эмулированном устройстве. Удобно для отладки: показывает конкретные проблемы и что чинить.
Полевые — отчёт Chrome UX Report (CrUX) в том же PageSpeed Insights и в Google Search Console. Это данные реальных посетителей за 28 дней. Именно они учитываются в ранжировании.
Расхождение между ними — норма. Лаборатория гоняет тест на быстром канале, а к вам могут приходить с телефона в метро. Ориентироваться в итоге надо на полевые данные, а лабораторные использовать как инструмент диагностики.
Наши замеры: где узкое место на самом деле
Мы измерили собственный сайт — статический, собранный генератором Hugo, без CMS и базы данных. Вот что получилось.
| Что | Сколько |
|---|---|
| HTML главной (сжатый) | 14 КБ |
| CSS, оба файла | 12 КБ |
| JavaScript | 1,2 КБ |
| Главное изображение (webp) | 48 КБ |
| Время до первого байта | около 1 секунды |
Обратите внимание на разрыв. Весь код страницы — 27 килобайт, это очень мало: типичный сайт на популярной CMS с набором плагинов легко отдаёт 300–500 килобайт одного только JavaScript. Изображения переведены в webp и сжаты автоматически при сборке, главное изображение предзагружается директивой preload, чтобы браузер начал качать его сразу.
И при всём этом время до первого байта — около секунды. Из них примерно четверть секунды уходит на установку соединения, ещё четверть на TLS-рукопожатие, остальное сервер тратит на то, чтобы начать отдавать готовый HTML-файл.
Для статики это много. Секунда TTFB съедает больше времени, чем загрузка всего кода страницы. Иными словами: мы можем сжать оставшиеся 27 килобайт хоть вдвое — на восприятие скорости это повлияет меньше, чем перенос сайта на более быстрый хостинг или подключение CDN.
Оговорка: это замеры curl с одной географической точки, а не полевые данные CrUX. Они показывают порядок величин и структуру задержки, но не заменяют отчёт по реальным посетителям.
Что из этого следует
Главный вывод не про наш сайт, а про порядок действий.
Прежде чем оптимизировать картинки и скрипты, посмотрите на TTFB. Если сервер начинает отвечать через секунду, то любые улучшения фронтенда упираются в этот потолок: посетитель уже потратил секунду, ещё ничего не увидев.
Типичные причины медленного ответа сервера:
- дешёвый shared-хостинг, где ресурсы делятся между сотнями сайтов;
- отсутствие кэширования — страница собирается из базы при каждом заходе;
- географическая удалённость сервера от аудитории;
- тяжёлые плагины и запросы к базе на каждой странице.
Первые три решаются переездом, кэшированием или CDN. Четвёртая — ревизией того, что установлено на сайте.
Как ускорять по порядку
- Замерьте TTFB. Если он больше половины секунды — начинайте с сервера, а не с картинок.
- Включите кэширование и сжатие. Статическая выдача готовых страниц вместо сборки при каждом запросе; gzip или brotli для текстовых файлов.
- Разберитесь с изображениями. Современные форматы (webp, avif), правильные размеры под контейнер, отложенная загрузка для всего, что ниже первого экрана.
- Предзагрузите то, что формирует LCP. Главное изображение первого экрана и шрифты — через
preload, чтобы браузер не ждал разбора CSS. - Уберите лишний JavaScript. Самый тяжёлый ресурс страницы: его нужно скачать, разобрать и выполнить. Всё, что не нужно в первом экране, — с атрибутом
deferили вовсе прочь. - Зарезервируйте место под элементы. Явные размеры изображений и контейнеров под баннеры убирают скачки вёрстки и чинят CLS.
Шрифты: тихий источник обеих проблем
Шрифты бьют сразу по двум метрикам, и про них часто забывают.
По LCP: если заголовок первого экрана набран нестандартным шрифтом, браузер не покажет текст, пока файл не загрузится, — или покажет системным, а потом переверстает. По CLS: подмена шрифта меняет ширину букв, строки перетекают, блоки уезжают.
Что с этим делать:
- Раздавайте шрифты со своего домена, а не подключайте со стороннего сервиса. Внешний источник — это лишний DNS-запрос, лишнее соединение и лишнее TLS-рукопожатие до того, как начнётся скачивание.
- Берите только нужные начертания и алфавиты. Кириллический поднабор одного начертания весит около 16–18 килобайт, полный набор со всеми языками и толщинами — сотни.
- Предзагружайте те, что участвуют в первом экране. Без
preloadбраузер узнает о шрифте только после разбора CSS, то есть с заметной задержкой. - Задайте
font-display: swap, чтобы текст показывался сразу системным шрифтом и заменялся, когда загрузится основной.
У нас на сайте два предзагруженных начертания по 16 и 18 килобайт, остальные подгружаются по мере надобности через unicode-range. В сумме шрифты весят больше, чем весь CSS и JavaScript вместе взятые, — это нормальный расклад для сайта с типографикой, но именно поэтому их стоит считать частью бюджета скорости, а не мелочью.
Стоит ли гнаться за сотней баллов
Нет. Балл PageSpeed Insights — производная от лабораторного прогона, и последние проценты обычно даются ценой архитектурных жертв.
Практичная цель — уложиться в пороги по полевым данным: LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1. Этого достаточно, чтобы скорость перестала быть проблемой и для посетителей, и для поисковика. Дальнейшая шлифовка ради цифры в отчёте почти никогда не окупается.
Скорость — часть технического аудита сайта наравне с индексацией и мобильной версией: смотреть их по отдельности бессмысленно, потому что проблемы обычно связаны.
Коротко о главном
- Три метрики: LCP до 2,5 с, INP до 200 мс, CLS до 0,1 — по полевым данным, а не по лабораторному прогону.
- Начинайте диагностику с TTFB: медленный сервер обесценивает любую оптимизацию фронтенда.
- Наш пример: 27 КБ кода на страницу и при этом секунда до первого байта — узкое место оказалось не в весе страницы.
- Гнаться за сотней баллов не нужно, нужно уложиться в пороги.
Проверяем скорость, индексацию и техническую базу сайта в рамках аудита — показываем, что именно тормозит и в каком порядке это чинить. Оставьте заявку на бесплатный экспресс-аудит.
