Скорость сайта и SEO: Core Web Vitals, LCP, INP, CLS в 2026 году

Почему скорость сайта критична для SEO

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

Но более важным является косвенное влияние: медленный сайт → более высокий показатель отказов → меньше времени на странице → худшие поведенческие сигналы → более низкие позиции. Кроме того, Google выделяет меньший crawl budget медленным сайтам.

Core Web Vitals: три ключевые метрики

LCP — Largest Contentful Paint

Время до появления самого большого видимого элемента (обычно главное изображение или заголовок). Показывает, когда пользователь видит основной контент.

• Хорошо: до 2.5 секунд
• Требует улучшения: 2.5–4 с
• Плохо: более 4 секунд

Основные причины плохого LCP: большие несжатые изображения, медленный сервер, блокирующие ресурсы (JS, CSS), отсутствие CDN.

INP — Interaction to Next Paint

Время отклика на взаимодействие пользователя (клик, тап, ввод). Заменил FID в марте 2024 года.

• Хорошо: до 200 мс
• Требует улучшения: 200–500 мс
• Плохо: более 500 мс

CLS — Cumulative Layout Shift

Суммарное смещение элементов во время загрузки. Контент "прыгает", когда загружаются изображения или реклама.

• Хорошо: до 0.1
• Требует улучшения: 0.1–0.25
• Плохо: более 0.25

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

Изображения — главная причина медленного LCP. Несколько правил:

• Формат WebP — на 25–35% меньше, чем JPEG при том же качестве
• Ленивая загрузка — loading="lazy" для изображений ниже первого экрана
• Размеры в HTML — всегда указывайте width и height, чтобы избежать CLS
• Предварительная загрузка LCP изображения — добавьте <link rel="preload" as="image"> для главного изображения
• CDN для изображений — Cloudflare Images или аналог для глобальной доставки

Скорость сервера и TTFB

TTFB (Time to First Byte) — время до первого байта ответа сервера. Google считает хорошим TTFB до 800мс.

• Кэширование — страницы должны возвращаться из кэша, а не генерироваться каждый раз
• Хостинг — VPS или облачный хостинг значительно быстрее, чем shared
• CDN — Cloudflare бесплатно уменьшает TTFB для посетителей из разных стран
• Базы данных — медленные SQL-запросы — самая частая причина плохого TTFB

Оптимизация JavaScript и CSS

Браузер не может рендерить страницу, пока загружаются и выполняются блокирующие ресурсы:

• Переместите JS в конец body или добавьте defer / async
• Выделите критический CSS (above-the-fold) и встроите его в head
• Минимизируйте и сжимайте JS и CSS файлы
• Удалите неиспользуемый CSS (Coverage tab в DevTools)
• Разбейте большой JS на chunks и загружайте лениво

Шрифты и скорость

• Используйте font-display: swap — текст виден сразу, шрифт загружается в фоновом режиме
• Предварительное соединение с fonts.googleapis.com и fonts.gstatic.com
• Ограничьте варианты шрифтов — только те веса, которые реально используются
• Рассмотрите системные шрифты для критического текста (нулевое время загрузки)

Мобильная оптимизация

Google использует Mobile-First Indexing — индексирует мобильную версию сайта как основную. Поэтому мобильная скорость важнее, чем десктопная.

• Проверьте мобильный PageSpeed отдельно от десктопного
• Тестируйте на реальных устройствах, а не только в DevTools
• Кнопки минимум 48x48px для удобного нажатия
• Избегайте горизонтальной прокрутки
• Попапы не должны перекрывать основной контент (штраф за intrusive interstitials)

Чеклист скорости сайта

• LCP менее 2.5 секунд на мобильном
• INP менее 200мс
• CLS менее 0.1
• Все изображения в формате WebP
• ленивая загрузка для изображений ниже первого экрана
• Подключен CDN (Cloudflare или аналог)
• JS перемещен в конец или добавлен defer
• Кэширование на сервере настроено
• TTFB менее 800мс
• font-display: swap для кастомных шрифтов
• Аудит сторонних скриптов завершен