Core Web Vitals — это метрики производительности сайта, которые влияют на ранжирование в Google. В 2026 году цели стали жёстче, и большинство сайтов в Казахстане их не выполняют.
LCP (Largest Contentful Paint)
Цель: <1.5 секунды на mobile. Оптимизация: критический CSS inline, preload hero image в WebP/AVIF, удалить блокирующие скрипты, использовать CDN.
LCP раскладывается на четыре части, и лечить нужно ту, которая доминирует. Первая — время до первого байта: сервер думает над ответом. Вторая — задержка загрузки ресурса: браузер узнал о картинке слишком поздно. Третья — сама загрузка файла: картинка весит два мегабайта. Четвёртая — отрисовка.
На практике у сайтов в регионе чаще всего виноваты первая и третья. Медленный отклик хостинга лечится кэшированием на стороне сервера, а не оптимизацией фронтенда — если TTFB держится около секунды, никакой inline-CSS ситуацию не спасёт. Тяжёлая картинка лечится конвертацией в AVIF или WebP и нарезкой под реальные размеры показа: hero-изображение шириной 1920 px, отдаваемое на телефон с шириной вьюпорта 390 px, — это в разы больше трафика, чем нужно.
Отдельный убийца LCP — шрифты и анимации появления. Текст, скрытый до загрузки шрифта, и блоки с opacity: 0, которые проявляются по скроллу или таймеру, откладывают момент отрисовки главного элемента. Асинхронно подключённый CSS даёт тот же эффект и вдобавок портит CLS.
INP (Interaction to Next Paint)
Цель: <100ms. Оптимизация: дробить JS на чанки, использовать requestIdleCallback, debounce input handlers, удалить heavy GSAP animations с UI потока.
INP заменил FID и измеряет не задержку до начала обработки, а полное время до отрисовки результата взаимодействия. Поэтому обмануть его нельзя: если после нажатия на кнопку меню открывается через 400 мс, метрика это увидит, даже если обработчик сработал мгновенно.
Главные источники проблем: длинные синхронные задачи в основном потоке, тяжёлые обработчики на input и scroll, а также сторонние скрипты — виджеты чатов, пиксели аналитики, карты. Практический приём — выносить всё, что не нужно для первого экрана, в загрузку после взаимодействия или по появлению элемента в области видимости. Карта в футере не должна грузиться вместе со страницей.
Второй приём — разбивать длинные задачи явно, уступая браузеру управление между кусками работы. Обработка списка из тысячи элементов одним циклом блокирует поток на сотни миллисекунд; та же обработка порциями с уступкой потока даёт то же время в сумме, но отзывчивый интерфейс.
CLS (Cumulative Layout Shift)
Цель: <0.05. Оптимизация: указывать width/height у изображений, резервировать место под рекламу, font-display: swap с fallback метриками.
CLS — самая дешёвая в исправлении метрика и самая раздражающая для пользователя: контент прыгает, человек промахивается мимо кнопки. Помимо изображений и рекламы, типичные источники сдвигов — баннеры cookie и промо, вставляемые в начало DOM; блоки, подгружаемые аяксом без зарезервированной высоты; и подмена шрифта, когда fallback и основной шрифт имеют разную метрику.
Со шрифтами работает связка: size-adjust и ascent-override у fallback-шрифта, чтобы резервный и основной занимали одинаковое место. Тогда переключение проходит незаметно.
Важный нюанс: сдвиги в течение 500 мс после действия пользователя не засчитываются. То есть раскрытие аккордеона по клику — это нормально, а самопроизвольное появление баннера через две секунды после загрузки — нет.
Чем измеряем
- PageSpeed Insights — лабораторные данные
- Search Console → Core Web Vitals — реальные данные пользователей
- CrUX Dashboard — 28-дневная статистика
Принципиально различать лабораторные и полевые данные. Лаборатория — это один прогон на эмулированном устройстве с эмулированной сетью, она нужна для отладки: показывает конкретные ресурсы и конкретные задачи, которые тормозят. Полевые данные — это 75-й перцентиль по реальным пользователям за 28 дней, и именно они учитываются в ранжировании.
Отсюда два практических следствия. Первое: зелёный результат PageSpeed Insights не означает, что в Search Console будет зелено, — у реальных пользователей телефоны слабее и сеть хуже. Второе: после исправлений полевые данные обновляются постепенно, и полную картину вы увидите не раньше чем через месяц. Не откатывайте изменения на второй неделе.
С чего начинать на реальном сайте
Порядок работ, который даёт результат быстрее всего: сначала измерить TTFB и включить серверное кэширование, потом привести в порядок изображения (форматы, размеры, атрибуты width/height, lazy-loading для всего ниже первого экрана), потом убрать блокирующие скрипты и отложить сторонние виджеты, и только после этого заниматься тонкой оптимизацией JS.
Отдельно проверьте, что оптимизация не сделана «на демо-странице». Замерять надо типовые шаблоны: главную, карточку товара, страницу категории, форму оформления. У интернет-магазина самая проблемная обычно категория с фильтрами, а не главная.
Если сайт делается с нуля, дешевле заложить требования к скорости в техзадание — форматы изображений, лимит на вес страницы, запрет на подключение произвольных сторонних скриптов. Переделывать потом дороже: на этапе создания сайта это часть работы, а не отдельный проект. Для одностраничников критерий особенно жёсткий: лендинг с медленным первым экраном теряет часть трафика ещё до того, как человек увидит предложение.
Практический вывод: не гонитесь за сотней баллов в PageSpeed Insights. Смотрите в Search Console на долю URL в зелёной зоне по каждой метрике, находите шаблон страниц, который проваливается сильнее всего, и чините его. Один исправленный шаблон обычно закрывает тысячи URL сразу, а комплексная работа со скоростью и индексацией входит в SEO-продвижение от 180 000 ₸.