Ускорение сайта: Core Web Vitals и что реально влияет на SEO

Ускорение сайта для SEO сводится к трём метрикам Core Web Vitals: LCP (как быстро появляется основной контент, хорошо — до 2,5 секунды), INP (как быстро страница реагирует на действия, хорошо — до 200 мс) и CLS (насколько «прыгает» вёрстка, хорошо — не выше 0,1). Google прямо использует эти метрики в ранжировании, но как один из сигналов: релевантный контент всё равно важнее. Яндекс официально не раскрывает, влияет ли скорость на позиции, однако измеряет её у реальных посетителей и показывает в Вебмастере. На практике главный выигрыш от ускорения — в поведении пользователей и конверсии, а не в прямом бонусе к позициям.

Что такое LCP, INP и CLS и какие у них пороги

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

• LCP (Largest Contentful Paint) — время отрисовки самого крупного элемента на первом экране: обычно это главное изображение, обложка видео или крупный блок текста. Хорошо — до 2,5 секунды, плохо — больше 4 секунд.
• INP (Interaction to Next Paint) — задержка между действием пользователя (нажатие, клик, ввод с клавиатуры) и следующей отрисовкой. Метрика учитывает взаимодействия за всё время на странице. Хорошо — до 200 мс, плохо — больше 500 мс. INP заменил прежнюю метрику FID 12 марта 2024 года, и многие сайты, которые «проходили» по FID, по INP оказались в жёлтой или красной зоне.
• CLS (Cumulative Layout Shift) — суммарный неожиданный сдвиг макета: когда кнопка уезжает из-под пальца, потому что сверху догрузился баннер. Хорошо — не выше 0,1, плохо — больше 0,25.

Важная деталь, которую часто упускают: оценка считается по 75-му перцентилю визитов отдельно для мобильных и десктопа. Страница проходит проверку, только если все три метрики в зелёной зоне у трёх четвертей реальных посетителей. Быстрый результат на рабочем ноутбуке разработчика ничего не говорит о том, что видит покупатель с бюджетным телефоном и мобильным интернетом.

Как скорость учитывают Google и Яндекс

Google в документации пишет прямо: Core Web Vitals используются системами ранжирования. Там же оговорено, что хорошие показатели не гарантируют высоких позиций, а Google показывает самый релевантный результат, даже если с удобством страницы всё плохо. Скорость начинает играть роль, когда по запросу есть много одинаково полезных страниц — тогда лучший пользовательский опыт помогает выиграть конкуренцию. Гнаться за идеальными 100 баллами ради SEO Google сам не советует.

Яндекс официально не комментирует, как отдельные факторы влияют на ранжирование, и скорость здесь не исключение. При этом в Яндекс Вебмастере есть индекс скорости сайта в разделе показателей качества. Он рассчитывается по реальным переходам из мобильного поиска Яндекса в Яндекс Браузере, на анонимизированных данных, и появляется только у сайтов с достаточным трафиком. Сотрудники Яндекса подчёркивали, что значение имеет скорость, которую видят реальные пользователи, а не результаты синтетических тестов.

Отсюда практический вывод: скорость — не волшебная кнопка для позиций, а условие, без которого остальная работа по SEO даёт меньше. Медленная страница теряет посетителей до того, как они увидят контент, и поведенческие сигналы ухудшаются независимо от того, учитывает ли поисковик скорость напрямую.

Полевые и лабораторные данные: что смотреть

Самая частая путаница в разговорах о скорости — смешение двух типов данных.

• Полевые данные — замеры у реальных посетителей. Для Google это отчёт CrUX (Chrome User Experience Report): данные пользователей Chrome, которые разрешили отправку статистики, за последние 28 дней. В CrUX попадают только достаточно посещаемые страницы и сайты. Для Яндекса аналог — индекс скорости в Вебмастере.
• Лабораторные данные — один синтетический прогон страницы в Lighthouse с эмуляцией среднего телефона и мобильной сети. Это балл от 0 до 100, который все любят показывать на скриншотах.

PageSpeed Insights показывает оба типа на одной странице: сверху — полевые данные CrUX, ниже — лабораторный отчёт Lighthouse. Для поисковиков значение имеют именно полевые данные. Лабораторный балл полезен для диагностики: он показывает, какие ресурсы блокируют отрисовку и что именно тормозит. Ещё один источник полевых данных — отчёт «Основные интернет-показатели» в Google Search Console: он группирует страницы с одинаковыми проблемами и удобен для сайтов с сотнями адресов.

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

Типичные причины медленного сайта

В проектах мы обычно находим одни и те же причины, и почти всегда их несколько одновременно.

• Изображения. Фотографии весом в несколько мегабайт, форматы JPEG и PNG вместо WebP или AVIF, отсутствие адаптивных размеров, ленивая загрузка главного изображения первого экрана — которое, наоборот, нужно загружать с приоритетом.
• Шрифты. Несколько начертаний с полным набором символов, загрузка с внешнего сервера без предварительного подключения, текст, скрытый до загрузки шрифта. Подмена шрифта без подобранных метрик даёт заметный сдвиг макета.
• Сторонние скрипты. Онлайн-чаты, виджеты обратного звонка, пиксели, карты, A/B-тесты, несколько систем аналитики сразу. Каждый по отдельности «весит немного», вместе они занимают основной поток браузера и ухудшают INP.
• Хостинг и время ответа сервера (TTFB). Дешёвый виртуальный хостинг, отсутствие кеширования, сервер далеко от аудитории. Если сервер отвечает больше секунды, уложить LCP в 2,5 секунды на мобильном почти невозможно.
• Тяжёлые CMS и конструкторы. WordPress с десятками плагинов и визуальным конструктором страниц подгружает стили и скрипты всех модулей на каждой странице. У Tilda и похожих конструкторов похожая история: платформа подключает свою библиотеку блоков и анимаций, а контроль над порядком загрузки ресурсов у владельца сайта ограничен.
• Баннеры и блоки без зарезервированного места. Главный источник плохого CLS — плашки cookie, промо-полосы, встроенные видео и рекламные блоки, которые раздвигают контент после загрузки.

Проблема, метрика и решение: сводная таблица

Что исправлять в первую очередь

Порядок работ определяют данные, а не список из сорока пунктов Lighthouse. Мы начинаем так:

• Смотрим полевые данные в Search Console, PageSpeed Insights и Яндекс Вебмастере: какая метрика в красной зоне и на каких типах страниц — главная, карточки, статьи.
• Берём шаблоны с наибольшим трафиком. Ускорение одного шаблона карточки товара или статьи сразу улучшает сотни страниц.
• Сначала дешёвые исправления с большим эффектом: сжатие и правильная загрузка главного изображения, размеры у медиа, ревизия сторонних скриптов. Часто именно они переводят LCP и CLS в зелёную зону.
• Затем сервер: кеширование страниц, CDN, обновление версии PHP или переезд на другой хостинг.
• В конце — JavaScript и архитектура: пересборка тяжёлых компонентов, отказ от лишних библиотек, работа над INP.

После каждого этапа ждём, пока обновятся полевые данные: окно CrUX — 28 дней, поэтому результат в отчётах Google виден не сразу. Чтобы не ждать вслепую, полезно собирать метрики собственных посетителей через библиотеку web-vitals и отправлять их в систему аналитики.

Ускорять текущий сайт или переезжать на новый стек

Не каждый сайт стоит ускорять до последнего миллисекундного выигрыша. Иногда оптимизация упирается в саму платформу, и деньги разумнее вложить в переезд.

Ускорять текущий сайт имеет смысл, если проблемы локальные: тяжёлые картинки, лишние виджеты, слабый хостинг. Такие вещи исправляются за недели без смены движка, и именно с этого начинается наша работа по ускорению и переносу сайтов: сначала аудит и быстрые исправления, затем решение, нужен ли переезд.

Переезд оправдан, когда ограничение заложено в платформе:

• конструктор не даёт управлять загрузкой ресурсов, а метрики стабильно в красной зоне после всех доступных настроек — тогда разумен перенос с Tilda на собственную вёрстку с сохранением адресов и SEO;
• WordPress перегружен плагинами и визуальным конструктором, но команда привыкла к его админке — в этом случае помогает headless WordPress: редакторы работают в знакомом интерфейсе, а посетители получают быстрый статический фронтенд;
• каждая оптимизация ломает что-то в другом месте, а разработка дорожает с каждым месяцем.

Наше правило простое: если после устранения очевидных причин — изображений, скриптов, хостинга — метрики всё ещё в красной зоне на ключевых шаблонах, дальнейшая оптимизация на той же платформе обычно стоит дороже переезда. Если же после первого этапа сайт выходит в зелёную зону, менять стек ради скорости не нужно. Переезд в любом случае планируется с картой адресов и 301-редиректами, иначе выигрыш в скорости съест потеря позиций.