Core Web Vitals и SEO:
как скорость сайта влияет на позиции в Google

Почему стоит беспокоиться о скорости сайта?

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

В 2026 году планка продолжает расти. Методология измерения Interaction to Next Paint (INP) от Google значительно ужесточилась. То, что проходило проверку в прошлом году, может не пройти сегодня. Сайты, перепроверившие свои показатели в 2026 году, увидели регрессию p75 INP на 18-25% — не потому что их производительность ухудшилась, а потому что измерение стало строже.

Core Web Vitals простыми словами

Core Web Vitals (CWV) — это три метрики, которыми Google измеряет пользовательский опыт на веб-странице. Представьте их как табель успеваемости вашего сайта:

1. Largest Contentful Paint (LCP) — Скорость загрузки

Что измеряет: Как долго самый крупный видимый элемент появляется на экране — обычно это hero-изображение, заголовок или видео.

Хороший показатель: Меньше 2,5 секунд.

Почему это важно: Если пользователи видят пустой экран или индикатор загрузки дольше 2,5 секунд, они воспринимают сайт как медленный. Google считает это плохим опытом.

Типичные причины плохого LCP: Неоптимизированные hero-изображения (загружаются в полном разрешении), медленное время ответа сервера (TTFB выше 800 мс), render-blocking JavaScript и CSS, большие HTML-документы со сложными компонентами.

2. Interaction to Next Paint (INP) — Отзывчивость

Что измеряет: Как быстро страница реагирует на действия пользователя — клики, нажатия на экран, нажатия клавиш. INP заменил First Input Delay (FID) в 2024 году и измеряет ВСЕ взаимодействия, а не только первое.

Хороший показатель: Меньше 200 миллисекунд.

Почему это важно: Это метрика, которая упала сильнее всего в 2026 году. Google расширил поддержку soft-навигаций в CrUX для одностраничных приложений (SPA) — теперь отслеживается каждый переход между маршрутами. Сайт с тяжёлым JavaScript или избыточными сторонними скриптами провалит INP, даже если всё остальное в порядке.

Типичные причины плохого INP: Раздутые JavaScript-бандлы, блокирующие главный поток, избыточные сторонние скрипты (аналитика, чаты, пиксели отслеживания), тяжёлые обработчики событий, длинные задачи (>50 мс), задерживающие отклик, гидратация фреймворков в SPA-приложениях.

3. Cumulative Layout Shift (CLS) — Визуальная стабильность

Что измеряет: Насколько неожиданно элементы страницы смещаются во время загрузки. Тот момент, когда вы собираетесь нажать на кнопку, а загружается реклама и сдвигает всё вниз — это и есть layout shift.

Хороший показатель: Оценка ниже 0,1.

Почему это важно: Смещения не просто раздражают — они наносят реальный вред. Пользователи случайно нажимают не ту ссылку, бросают корзину или закрывают вкладку в раздражении. Google отслеживает неожиданные смещения и понижает сайты с плохим CLS.

Типичные причины плохого CLS: Изображения без явных атрибутов ширины и высоты, реклама и встраиваемые элементы, загружающиеся без зарезервированного места, пользовательские шрифты, вызывающие мерцание невидимого текста (FOIT/FOUT), динамически вставляемый контент, сдвигающий существующие элементы.

Что изменилось в Core Web Vitals в 2026 году

Методология измерения Core Web Vitals от Google обновляется каждый год. Обновление 2026 года принесло три значительных изменения:

Более строгое измерение INP

INP теперь измеряется для каждого взаимодействия во время посещения страницы — а не только для самого длинного. Для одностраничных приложений на React, Angular или Vue это означает, что отслеживается каждый переход между маршрутами. Сайты, которые раньше проходили INP за счёт быстрого первого взаимодействия, теперь проваливают его, потому что последующие взаимодействия тоже учитываются.

Расширенная поддержка soft-навигаций в CrUX

Chrome User Experience Report (CrUX) теперь распознаёт soft-навигации в SPA — клиентские переходы между маршрутами без загрузки нового URL. Это значит, что производительность всего SPA-приложения теперь измеряется на всех его маршрутах, а не только при начальной загрузке. SPA-сайты показали самое большое падение в наборе данных CrUX за 2026 год.

TTFB как диагностический сигнал

Time to First Byte (TTFB) — время между запросом и получением первого байта ответа — стал более заметным диагностическим сигналом. Хотя он пока не является прямым фактором ранжирования, Google использует TTFB как показатель качества сервера. Сайты с TTFB выше 800 мс почти всегда проваливают LCP. Обновление 2026 года сделало TTFB более сильным сигналом в разбивке LCP, помогая разработчикам определить, где узкое место — на сервере или на клиенте.

Как скорость сайта напрямую влияет на ваш бизнес

Помимо ранжирования Google, скорость загрузки влияет на прибыль измеримыми способами:

• Конверсия: Задержка в 1 секунду снижает конверсию в среднем на 7%. Для сайта с оборотом $100,000 в месяц это $84,000 потерянной выручки в год.
• Отказы: Страницы, загружающиеся за 2 секунды, имеют 9% отказов. При 5 секундах — уже 38%. При 10 секундах более 50% посетителей уходят.
• Мобильный трафик: Более 60% веб-трафика — мобильный. Медленные мобильные страницы теряют в 3 раза больше пользователей, чем медленные десктопные. Google ранжирует в первую очередь мобильную версию.
• Доверие пользователей: 79% онлайн-покупателей, столкнувшихся с проблемами производительности, говорят, что вряд ли купят на этом сайте снова.

Почему готовые темы проваливают Core Web Vitals

Если вы используете готовый шаблон WordPress, конструктор сайтов (Wix, Tilda, Squarespace) или CMS-решение, велика вероятность, что ваш сайт не проходит Core Web Vitals. Вот почему:

• Избыточность: Коммерческие темы включают функции, которые вы не используете — слайдеры, мега-меню, библиотеки анимаций, наборы шрифтов — всё загружается независимо от того, нужно вам это или нет.
• Перегрузка плагинами: Каждый плагин добавляет JavaScript, CSS и часто внешние API-вызовы. Десять плагинов = десять неизвестных нагрузок на производительность. Многие бизнес-сайты используют 20-30 плагинов.
• Отсутствие контроля: Конструкторы и билдеры страниц добавляют render-blocking ресурсы, которые опытный разработчик никогда бы не включил.
• Дешёвый хостинг: Обычный shared hosting ограничивает время ответа сервера. Тариф за $5/мес означает медленный TTFB, что автоматически ведёт к провалу LCP.

Здесь и проявляется разница с профессиональным веб-разработчиком. Сайт, построенный с нуля с чистым стеком технологий, избегает этих проблем — потому что производительность закладывается с первой строки кода, а не приклеивается заплатками потом.

Что делает профессиональный разработчик иначе

Когда сайт строит опытный разработчик, Core Web Vitals — не послесловие, а требование с первой строки кода. Вот что оптимизируется:

Производительность на стороне сервера (TTFB)

Разработчик настраивает стратегии кэширования (CDN, Redis, браузерное кэширование), оптимизирует запросы к базе данных и настраивает серверный рендеринг там, где это уместно. Результат: TTFB ниже 200 мс, что даёт LCP хороший старт.

Оптимизация JavaScript (INP)

Code splitting, tree shaking и lazy loading гарантируют, что загружается и выполняется только тот JavaScript, который нужен текущей странице. Сторонние скрипты (аналитика, чаты) загружаются асинхронно или отложенно. Главный поток остаётся отзывчивым.

Оптимизация изображений (LCP)

Изображения отдаются в современных форматах (WebP, AVIF), настраиваются responsive srcset, hero-изображения предзагружаются с правильными приоритетами. Шрифты подмножествуются и предзагружаются. Каждый актив имеет точные размеры для предотвращения смещения.

Стабильность макета (CLS)

Каждое изображение, iframe и рекламный блок имеют явные атрибуты ширины и высоты. Font-display настроен на swap с запасным шрифтом. Динамический контент (баннеры, уведомления) вставляется с зарезервированным местом или позиционируется абсолютно. Никаких сюрпризов для пользователя.

Чек-лист оптимизации Core Web Vitals

Если вы оцениваете текущий сайт или планируете новый, вот что стоит проверить:

1. Протестируйте сайт: Запустите Google PageSpeed Insights или откройте отчёт в Search Console. Запишите показатели LCP, INP и CLS.
2. Определите самую проблемную метрику: У каждой метрики свои методы исправления. Знайте, что именно проваливается, прежде чем тратить деньги на решения.
3. Аудит сторонних скриптов: Составьте список всех внешних скриптов (аналитика, чат, отслеживание, реклама). Удалите ненужные. Отложите оставшиеся.
4. Проверьте оптимизацию изображений: Используются ли современные форматы? Предзагружены ли hero-изображения? Есть ли размеры у всех картинок?
5. Оцените хостинг: TTFB ниже 200 мс? Если нет, дешёвый хостинг может быть корнем проблемы.
6. Рассмотрите кастомную разработку: Если CMS или тема — первопричина проблем, заказное решение может оказаться выгоднее постоянных заплаток.

FAQ

Нужен аудит производительности?

Если вы не уверены, в каком состоянии Core Web Vitals вашего сайта, я проведу бесплатную консультацию — прогоню сайт через диагностические инструменты, выявлю ключевые проблемы и предоставлю сроки и стоимость исправлений. Без давления и обязательств.

Я — full-stack веб-разработчик с опытом более 20 лет. Строю высокопроизводительные сайты и веб-приложения, которые проходят Core Web Vitals с первого дня. Работаю удалённо с клиентами по всему миру. Нахожусь в Минске. Свяжитесь со мной.