Скорость загрузки сайта в 2026: новые требования Core Web Vitals и как их пройти

Core Web Vitals — это набор метрик, которыми Google измеряет реальный пользовательский опыт на сайте. Не «как быстро загружается код», а «как быстро пользователь получил то, за чем пришёл, и насколько комфортно ему было взаимодействовать со страницей». С 2021 года эти метрики — официальный фактор ранжирования.

В 2024 году Google провёл революцию: заменил старую метрику FID (First Input Delay) на INP (Interaction to Next Paint). Если FID измерял задержку только при первом взаимодействии, INP — задержку при всех взаимодействиях за всю сессию. Это намного жёстче и реалистичнее. К 2026 году пороги Google ужесточил, и многие сайты, которые «проходили» в 2023, перестали проходить.

Что это означает на практике: если ваш сайт не проходит CWV в реалиях 2026 года, он медленно, но верно теряет позиции в выдаче по высококонкурентным запросам. Контент может быть гениальным, бэклинки — авторитетными, schema.org — идеальной, но если INP больше 500 мс — топ-10 закрыт.

Прежде чем что-то оптимизировать, нужно понять текущее состояние сайта. Главные источники данных:

• PageSpeed Insights (pagespeed.web.dev). Самый популярный инструмент. Показывает «лабораторные» метрики (синтетический тест) и «полевые» (реальные пользователи из CrUX-базы). Полевые важнее — это то, что Google использует для ранжирования.
• Google Search Console → Core Web Vitals. Группирует все страницы вашего сайта по статусу: хорошо / требует улучшения / плохо. Показывает тренды по дням.
• Lighthouse в Chrome DevTools. Детальный технический отчёт с конкретными проблемами и ссылками на исправления.
• WebPageTest (webpagetest.org). Профессиональный инструмент с возможностью симулировать слабый интернет, мобильные устройства, разные геолокации.
• RUM (Real User Monitoring). Сервисы вроде Vercel Speed Insights или Yandex.Метрика собирают метрики реальных пользователей в реальном времени. Лучший способ оценить «полевые» данные.

LCP измеряет, через сколько секунд загрузился самый крупный видимый элемент на первом экране (обычно — главное изображение или заголовок). Это самая «честная» метрика: пользователь действительно ждёт, пока загрузится hero-блок.

Что работает для улучшения LCP:

• Сжатие изображений в WebP/AVIF. WebP даёт сжатие на 25-35% против JPEG, AVIF — на 50%. Современные браузеры поддерживают оба формата.
• Корректные размеры изображений. Не загружайте картинку 4000×3000 для отображения 800×600. Используйте srcset и sizes для разных экранов.
• Lazy-loading для всего ниже первого экрана. loading="lazy" для img, IntersectionObserver для тяжёлых блоков. Но не для hero-картинки!
• Preload для критичных ресурсов. link rel="preload" для hero-картинки и шрифтов первого экрана.
• CDN для статики. Cloudflare (бесплатно), Yandex Cloud CDN, или Vercel/Netlify edge network.
• Inline critical CSS. Стили, нужные для первого экрана, прописываются прямо в head, остальные грузятся отложенно.
• Самохостинг шрифтов. Не подключайте шрифты с Google Fonts — каждый внешний DNS-запрос добавляет 100-300 мс.

INP измеряет, через сколько миллисекунд страница реагирует на взаимодействия пользователя: клики, тапы, нажатия клавиш. Это «отзывчивость», и она напрямую зависит от качества JavaScript.

Что снижает INP:

• Тяжёлые JS-задачи на главном потоке. Если функция выполняется дольше 50 мс, она «блокирует» поток и UI замирает. Решение — yieldToMain pattern: разбивать длинные задачи на чанки и отдавать управление браузеру через scheduler.yield() или await new Promise(r => setTimeout(r, 0)).
• Лишние event-listeners. Подписки на scroll, mousemove, resize без debounce/throttle бьют по производительности. Используйте throttle 16ms (60 FPS) или passive: true.
• Тяжёлые сторонние скрипты. Аналитика (Метрика, GA4), чаты (LiveChat, JivoSite), виджеты соцсетей. Каждый сторонний скрипт — это потенциальный «убийца» INP. Подключайте через async/defer, рассмотрите серверный трекинг.
• Большие React/Vue-приложения. Используйте useMemo, useCallback, virtualization для длинных списков (react-window, react-virtuoso). Code-splitting на уровне маршрутов.
• requestIdleCallback для некритичного. Логирование, prefetch, аналитика с задержкой — всё это можно делать в idle-time.
• Удалить ненужный JS. Tree-shaking, динамические импорты. Lighthouse покажет, какие куски кода не используются.

CLS измеряет, как сильно «прыгает» макет страницы во время загрузки. Высокий CLS означает: пользователь хочет нажать на кнопку, а в этот момент над ней появилась реклама, и он по ошибке кликнул на неё. Раздражает.

Что вызывает высокий CLS:

• Изображения без явных width и height — браузер не знает, сколько места зарезервировать
• Реклама, виджеты и iframe, которые «подгружаются» уже после первого рендера
• Веб-шрифты, которые меняют размеры текста при загрузке (FOIT/FOUT)
• Динамический контент, который вставляется выше уже загруженного (например, баннер cookie-согласия наверху страницы)
• Анимации, использующие width/height/top/left вместо transform

Решения:

• Всегда задавайте width и height для img и video (или aspect-ratio в CSS)
• Резервируйте место под рекламные блоки фиксированной высотой контейнера
• Используйте font-display: optional или swap с правильной настройкой fallback-шрифтов
• Размещайте динамический контент (cookie-баннеры, чаты) внизу страницы, а не сверху
• Анимации только через transform и opacity

Никакая фронт-оптимизация не поможет, если сервер отвечает 2 секунды на каждый запрос. TTFB должен быть менее 600 мс.

Что улучшает TTFB:

• Хостинг. Дешёвый shared-хостинг с PHP 7.x и без OPcache — это автоматический TTFB 1-3 секунды. Минимум — VPS с PHP 8.2+ и OPcache в 256 МБ.
• Серверный рендеринг с кешем. Для WordPress — WP Rocket / LiteSpeed Cache. Для Битрикса — встроенный композитный кеш. Для headless — ISR (Incremental Static Regeneration) Next.js.
• База данных. Индексы на часто запрашиваемых полях, медленные запросы — переписывать. Slow query log показывает проблемы.
• Geo-расположение сервера. Сервер в Москве отдаёт страницу московскому пользователю за 30 мс, тому же пользователю из США — за 200 мс. Используйте CDN для глобальной аудитории.
• HTTP/2 и HTTP/3. Включены ли они на сервере? HTTP/3 (QUIC) ещё быстрее на мобильных сетях.
• Compression. Brotli или gzip для всех текстовых ответов. Brotli даёт сжатие на 15-20% лучше gzip.

Дано: сайт на WordPress + WooCommerce, каталог 800 SKU. PageSpeed на старте: мобильный 38, десктоп 67. LCP 4,8 сек, INP 480 мс, CLS 0,3.

Что сделали:

1. Перевели хостинг с shared на VPS с PHP 8.2 + OPcache. TTFB упал с 1,2 сек до 380 мс.
2. Установили WP Rocket для кеширования + LiteSpeed Cache для критичного CSS. Включили Brotli.
3. Сжали все изображения каталога в WebP. Подключили Cloudflare CDN для статики.
4. Перенесли счётчики Метрики и пикселей в загрузку через requestIdleCallback после полного рендера.
5. Удалили 12 неиспользуемых плагинов, 3 заменили на более лёгкие альтернативы.
6. Добавили aspect-ratio всем изображениям и тематическим обложкам.
7. Настроили шрифт Inter с font-display: swap и preload.

Результат через 3 недели: PageSpeed мобильный 86, десктоп 96. LCP 2,1 сек, INP 165 мс, CLS 0,06. Все три метрики Core Web Vitals в зелёной зоне. Стоимость работ — 95 000 ₽.

Типичные диапазоны для разных уровней работ:

• Базовая оптимизация. 30-50 тыс. ₽, срок 1 неделя. Подключение CDN, базовое кеширование, сжатие изображений. Поднимет PageSpeed с 40 до 70-75.
• Стандартная оптимизация. 70-120 тыс. ₽, срок 2-3 недели. Полная работа над CWV: переход на WebP/AVIF, оптимизация JS, исправление CLS. PageSpeed с 40 до 85-90.
• Глубокая оптимизация. 150-300 тыс. ₽, срок 3-6 недель. Архитектурные изменения, переход на Headless или SSG, ручная оптимизация компонентов. PageSpeed 95-100.

Важно: оптимизация — не разовое мероприятие. Через 6-12 месяцев с обновлениями плагинов, добавлением новых страниц, ростом каталога производительность снова деградирует. Минимум — раз в год нужен «чек-ап».