Как ускорить сайт и пройти Core Web Vitals

Что такое Core Web Vitals и почему это важно для SEO

Core Web Vitals (CWV) — набор метрик, разработанных Google для оценки реального пользовательского опыта. Они входят в группу сигналов Page Experience и учитываются при ранжировании в Google (методология описана на web.dev/vitals). Яндекс аналогичные требования не публикует, но скорость и стабильность интерфейса косвенно влияют на поведенческие факторы — а значит, и на позиции в российской выдаче. Подробнее о метриках и их роли можно прочитать в нашем глоссарии Core Web Vitals.

Три ключевых метрики CWV: LCP (Largest Contentful Paint) — время отрисовки крупнейшего видимого элемента, INP (Interaction to Next Paint) — отзывчивость на взаимодействие, CLS (Cumulative Layout Shift) — визуальная стабильность страницы. Хорошие значения: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1. Выход за пороги «хорошо» — это красный флаг в Search Console.

Где смотреть данные: инструменты диагностики

Первый шаг — получить объективные данные, а не ориентироваться на субъективное ощущение скорости. Используйте полевые данные (реальные пользователи) вместо лабораторных тестов — именно они влияют на ранжирование. Базовый набор инструментов для SEO-аудита:

• Google Search Console → отчёт «Основные интернет-показатели» (Core Web Vitals) — полевые данные по вашему сайту, сегментация по URL и типу устройства
• PageSpeed Insights — лабораторные и полевые данные, конкретные рекомендации
• Chrome UX Report (CrUX) — агрегированные полевые данные из Chrome, источник для Search Console
• WebPageTest.org — детальный waterfall-анализ, тест с реальных устройств и локаций
• Lighthouse (встроен в Chrome DevTools) — аудит только лабораторный, хорош для разработки

Важный нюанс: PageSpeed Insights и Lighthouse дают разные числа — Lighthouse запускает лабораторный тест в контролируемой среде, а PSI показывает реальные данные CrUX. Для SEO имеют значение только полевые данные. Если PSI пишет «недостаточно данных» — сайт слишком маленький по трафику, Google не имеет репрезентативной выборки, и метрики не учитываются в ранжировании.

Оптимизация LCP: как ускорить отрисовку главного элемента

LCP — чаще всего главный hero-баннер, крупное изображение или заголовок H1. Самая частая причина плохого LCP — медленная загрузка изображения или блокировка рендеринга скриптами. Для улучшения LCP действуйте в следующем порядке:

1. Определите LCP-элемент в DevTools (вкладка Performance → Timeline → LCP marker) или через PSI
2. Если это изображение — конвертируйте в WebP или AVIF, сожмите без потери качества (TinyPNG, Squoosh)
3. Добавьте атрибут fetchpriority="high" к тегу img LCP-изображения — браузер загрузит его в первую очередь
4. Убедитесь, что изображение не загружается через JavaScript — это критически замедляет LCP
5. Подключите CDN для статики (Cloudflare, BunnyCDN, AWS CloudFront) — сократите TTFB до 200 мс
6. Настройте preload для LCP-ресурса: <link rel="preload" as="image" href="hero.webp">
7. Устраните render-blocking ресурсы: перенесите неключевые JS в defer/async, критический CSS встройте inline

Оптимизация CLS: стабильность макета без сдвигов

CLS выше 0,1 — это прыгающие кнопки и тексты, когда пользователь уже начал читать. Основные виновники: изображения без явно указанных размеров, встраиваемые шрифты без font-display, реклама и виджеты, динамически добавляемые в поток документа. Проверить конкретные элементы можно через вкладку Performance в Chrome DevTools — раздел Layout Shifts показывает каждый сдвиг с анимацией.

• Всегда указывайте width и height для img и video — браузер заранее резервирует место
• Используйте aspect-ratio в CSS вместо padding-hack для responsive-контейнеров
• Для Google Fonts добавьте font-display: swap и preconnect к fonts.googleapis.com
• Рекламные блоки и баннеры размещайте в контейнерах с фиксированной высотой
• Избегайте вставки контента выше видимой области после загрузки — это главный источник высокого CLS
• Анимации делайте только через transform и opacity — они не вызывают layout reflow

Оптимизация INP: отзывчивость интерфейса

INP заменил FID (First Input Delay) в марте 2024 года. Если FID измерял только первое взаимодействие, INP оценивает все клики, нажатия и касания на протяжении всей сессии. Плохой INP (более 500 мс) — признак «тяжёлого» JavaScript, который блокирует основной поток. Это особенно актуально для SPA-приложений на React/Vue с большими бандлами.

• Профилируйте JavaScript в Chrome DevTools вкладка Performance → Long Tasks (>50 мс)
• Разбейте длинные задачи через scheduler.yield() или setTimeout(fn, 0) — это освобождает главный поток
• Используйте code splitting: загружайте JS только для того компонента, который нужен сейчас
• Минимизируйте сторонние скрипты (чаты, пиксели, аналитика) — они часто главная причина плохого INP
• Используйте Web Workers для вычислительно тяжёлых задач вне основного потока
• Внедрите Virtual List для длинных списков вместо рендеринга всех элементов DOM

Серверная оптимизация: TTFB и кэширование

Time to First Byte (TTFB) не входит в Core Web Vitals напрямую, но плохой TTFB (более 800 мс) делает невозможным хороший LCP. TTFB — это время от запроса браузера до получения первого байта ответа сервера. Причины: медленный хостинг, отсутствие кэширования, тяжёлые запросы к базе данных, географически удалённый сервер. Если вы проводите технический SEO-аудит, TTFB — первая проверка после CWV.

1. Переедьте на хостинг с NVMe SSD и PHP 8.x — разница с устаревшим shared-хостингом может быть 5–10x по TTFB
2. Включите Full Page Cache: для WordPress — WP Rocket или LiteSpeed Cache, для кастомных CMS — Redis/Varnish
3. Настройте HTTP/2 или HTTP/3 (QUIC) — сервер должен поддерживать мультиплексирование запросов
4. Включите Brotli-сжатие (эффективнее gzip на 15–25% для текстовых ресурсов)
5. Настройте правильные Cache-Control заголовки: статика — max-age=31536000 immutable, HTML — no-cache с ETag
6. Используйте Database Query Optimization: индексы, кэш запросов, исключите N+1 проблемы

Оптимизация изображений и шрифтов: быстрый выигрыш

Изображения — обычно крупнейшая статья расходов по весу страницы. Медианный вес страницы, по данным HTTP Archive, составляет порядка 2,5 МБ, и примерно половина приходится на изображения. Это самое очевидное место для экономии: правильная оптимизация изображений даёт 30–60% снижения веса страницы без видимых потерь качества.

• Конвертируйте PNG и JPEG в WebP (поддержка 96% браузеров) или AVIF (лучшее сжатие, поддержка 90%+)
• Используйте srcset и sizes для адаптивных изображений — мобильный пользователь не должен грузить 1920px
• Добавьте loading="lazy" для всех изображений ниже первого экрана
• Для иконок используйте SVG вместо PNG — они масштабируются без потерь и весят меньше
• Шрифты: загружайте только нужные начертания (не весь семейство), используйте font-display: swap
• Рассмотрите системные шрифты (-apple-system, Segoe UI) — нулевая задержка загрузки

JavaScript и CSS: устраняем блокировку рендеринга

Браузер не может отображать страницу, пока парсит и исполняет синхронный JavaScript в теге <head>. Это называется render-blocking. Каждый такой скрипт добавляет время к FCP и LCP. Аналогично работают неиспользуемые CSS: браузер должен загрузить весь файл перед рендерингом, даже если на текущей странице применяется 5% правил.

1. Добавьте defer или async ко всем скриптам, не критичным для первого рендеринга
2. Встройте Critical CSS inline в <head> (инструменты: Critical, Penthouse, Critters)
3. Остальной CSS загружайте асинхронно через media="print" onload-трюк или через preload
4. Удалите неиспользуемый CSS (PurgeCSS, UnCSS) — особенно актуально при использовании Bootstrap/Tailwind
5. Разбейте JavaScript-бандл на чанки по маршрутам (webpack code splitting, Vite dynamic import)
6. Проверьте сторонние скрипты: Google Tag Manager, пиксели соцсетей, чаты — загружайте их через Partytown или с задержкой

Технический SEO и скорость: как это связано

Скорость сайта — не изолированная техническая задача, а часть комплексного технического SEO. Медленный сайт снижает crawl budget: Googlebot тратит больше времени на ожидание ответа и обходит меньше страниц за сессию. Для крупных сайтов с тысячами страниц это прямо влияет на индексацию. Хорошая скорость — базовое условие, без которого контентное продвижение и работа со ссылочным профилем работают вполсилы.

Для интернет-магазинов и новостных сайтов с большим количеством страниц особенно важно настроить серверное кэширование и CDN — это снижает нагрузку на сервер и позволяет Googlebot эффективнее обходить сайт. Если вы занимаетесь продвижением в Google, прохождение CWV в зелёную зону по всем страницам — обязательный технический минимум, с которого начинается любая серьёзная работа.