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

Скорость загрузки сайта в SEO обсуждают в двух крайностях. Одни говорят, что это решающий фактор и без «зелёной зоны» в тестах ранжирования не будет. Другие — что Яндексу всё равно, и достаточно нормального контента. Правда, как обычно, посередине, и она прагматичнее обеих версий: скорость редко поднимает позиции сама по себе, но медленный сайт стабильно теряет деньги — и в органике, и в рекламе.

В моей практике это выглядит так. Приходит клиент с жалобой «реклама не окупается». Смотрю Метрику: с мобильных отказы за 60%, среднее время загрузки — пять-шесть секунд. Человек кликнул по объявлению, клиент заплатил за клик, а посетитель увидел белый экран и вернулся в выдачу. Деньги списаны, заявки нет. И эта же страница в органике собирает мизерный CTR и плохие поведенческие сигналы.

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

Что такое Core Web Vitals

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

Метрика	Что измеряет	Хорошо	Требует улучшения	Плохо
LCP	Время отрисовки самого крупного элемента первого экрана	до 2,5 с	2,5–4,0 с	более 4,0 с
INP	Отзывчивость: задержка реакции на действия пользователя	до 200 мс	200–500 мс	более 500 мс
CLS	Визуальная стабильность: смещения вёрстки при загрузке	до 0,1	0,1–0,25	более 0,25

LCP — Largest Contentful Paint

Момент, когда отрисовался самый большой видимый элемент первого экрана: обычно это главная картинка, баннер или крупный заголовок. По сути LCP отвечает на вопрос «когда человек увидел, что страница загрузилась». Если ваш LCP шесть секунд — половина посетителей с мобильного не дождётся.

INP — Interaction to Next Paint

Метрика отзывчивости, которая с 2024 года заменила прежний FID. Измеряет, сколько проходит от действия пользователя (клик, тап, нажатие клавиши) до видимого отклика интерфейса. Плохой INP — это когда человек нажал на кнопку меню, ничего не произошло, он нажал ещё раз, и открылось-закрылось. Чаще всего виноват тяжёлый JavaScript, который занял основной поток браузера.

CLS — Cumulative Layout Shift

Сумма смещений элементов во время загрузки. Классика: человек тянется пальцем к кнопке «Заказать», в этот момент дозагружается баннер, всё уезжает вниз, и палец попадает в другую ссылку. Для коммерческого сайта CLS особенно вреден, потому что бьёт прямо по конверсии.

Важная оговорка про Яндекс

Core Web Vitals — это метрики Google, и именно Google использует их как фактор ранжирования. Яндекс не публикует такого же формализованного набора порогов, но скорость учитывает: и напрямую, и косвенно — через поведение пользователей. Медленная страница даёт больше отказов и возвратов в выдачу, а это алгоритмы считывают уверенно. Плюс у Яндекса есть собственные отчёты по скорости в Вебмастере и подробный отчёт «Время загрузки страниц» в Метрике.

Поэтому я использую Core Web Vitals не как «требования Яндекса», а как удобный и общепринятый язык для постановки задач разработчикам. Пороги там разумные, и сайт, укладывающийся в них, объективно комфортен для пользователя.

Как скорость влияет на позиции и на заявки

Прямое влияние на ранжирование

Оно есть, но переоценено. Скорость работает скорее как пороговый фактор: критически медленный сайт проигрывает, а разница между «быстро» и «очень быстро» на позиции почти не влияет. Если ваша страница грузится за 1,8 секунды, а конкурента — за 1,2, это не объяснит, почему он выше. А вот 7 секунд против 2 — объяснит.

Косвенное влияние — то, что важнее

• Поведенческие сигналы. Отказы, короткие сессии, возвраты в выдачу. Для поисковика это признак, что документ не решил задачу пользователя.
• Глубина просмотра. На медленном сайте люди не переходят на вторую и третью страницу, а значит, не доходят до формы заявки.
• Мобильный трафик. Основная доля визитов идёт с телефонов, часто на нестабильной сети. Там разница между 2 и 6 секундами решает всё.

Влияние на деньги

Это самая понятная часть. Каждая лишняя секунда загрузки отнимает часть посетителей, которые просто не дождались. На органическом трафике вы теряете потенциальные заявки; на рекламном — теряете уже оплаченные клики. Я не буду называть «универсальный процент», потому что он сильно зависит от ниши и устройства, но порядок такой: на мобильных при загрузке дольше пяти секунд отказы вырастают в полтора-два раза по сравнению с той же страницей, ускоренной до двух секунд. Это то, что я вижу в Метрике по своим проектам.

Считается это легко: возьмите число визитов, долю отказов до и после ускорения, конверсию в заявку и среднюю выручку с заявки. Даже консервативная оценка обычно показывает, что работа по ускорению окупается за месяц-два.

Чем измерять: лаборатория и поле

Ключевое различие, которое стоит усвоить: есть лабораторные данные (синтетический тест в контролируемых условиях) и полевые (реальные измерения у реальных пользователей). Они почти никогда не совпадают, и это нормально.

Лабораторные инструменты

• PageSpeed Insights и Lighthouse. Дают детальный разбор: что грузится, что блокирует отрисовку, какие ресурсы лишние. Главная ценность — не в цифре балла, а в списке конкретных проблем.
• Панель разработчика в браузере. Вкладка со списком запросов показывает, какие файлы тормозят и сколько весит страница целиком.
• Режим замедленной сети. Обязательный тест: откройте сайт с эмуляцией медленного мобильного интернета и посмотрите, что происходит в первые три секунды.

Полевые данные

• Яндекс Метрика, отчёт по времени загрузки. Самый честный источник: реальные посетители, разбивка по устройствам, браузерам, регионам и страницам. Обязательно смотрите отдельно мобильные — общая цифра прячет проблему.
• Отчёт по скорости в Вебмастере. Показывает динамику по сайту и по группам страниц.
• Собственные события. Если важен конкретный сценарий (например, время до открытия формы заявки), его можно измерять отдельно.

Почему не надо гнаться за баллом 100

Балл в синтетическом тесте — не цель. Я видел сайты с 95 баллами, которые у реальных пользователей грузились по четыре секунды, и сайты с 60 баллами, где люди спокойно оформляли заказы. Ориентируйтесь на полевые данные и на пороги метрик, а синтетику используйте как список задач. Разумная цель для коммерческого сайта услуг: LCP до 2,5 секунды на мобильных у 75% пользователей и отсутствие заметных смещений вёрстки.

Что тормозит сайты чаще всего

За годы аудитов набор причин почти не меняется. Вот топ, отсортированный по тому, как часто я это встречаю.

1. Неоптимизированные изображения

Абсолютный лидер. Фотография с телефона весом 4 МБ, вставленная в блок 400×300 пикселей. На странице таких двадцать — и вот вам 30 МБ трафика. Лечится конвертацией в современные форматы, правильными размерами под контейнер, адаптивной выдачей разных размеров под разные экраны и отложенной загрузкой всего, что ниже первого экрана.

2. Избыток скриптов и внешних сервисов

Счётчики аналитики, онлайн-чат, виджет обратного звонка, карта, попап с акцией, калькулятор, квиз, пиксели рекламных систем. Каждый сам по себе небольшой, вместе — несколько мегабайт JavaScript, который блокирует основной поток и портит INP. Я всегда начинаю с ревизии: что из этого реально используется и приносит пользу.

3. Тяжёлый шаблон и «универсальная» тема

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

4. Медленный ответ сервера

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

5. Шрифты

Подключённые с внешнего домена веб-шрифты, да ещё в нескольких начертаниях, задерживают отрисовку текста. Плюс дают скачок вёрстки при подмене шрифта.

6. Отсутствие кеширования и сжатия

Базовые вещи, которые настраиваются один раз: сжатие текстовых ресурсов, заголовки кеширования для статики, HTTP/2. Удивительно часто они просто не включены.

7. Реклама и баннеры без зарезервированного места

Главный источник плохого CLS. Блок подгружается и раздвигает содержимое.

Как чинить: конкретные задачи по метрикам

Улучшаем LCP

1. Определите, какой именно элемент является LCP на мобильном — чаще всего это первое крупное изображение или заголовок.
2. Сожмите и правильно отмасштабируйте это изображение; отдайте его в современном формате.
3. Не ставьте на него отложенную загрузку. Частая ошибка: lazy-load навесили на все картинки скопом, включая главную, — и LCP стал хуже.
4. Уберите ресурсы, блокирующие отрисовку: критические стили встройте, остальные загрузите асинхронно.
5. Ускорьте ответ сервера: кеширование страниц, нормальный хостинг, CDN для статики.
6. Проверьте, не рисуется ли первый экран скриптом. Если контент появляется только после выполнения JavaScript, LCP будет плохим почти всегда.

Улучшаем INP

1. Проведите ревизию сторонних скриптов и удалите неиспользуемые.
2. Всё, что не нужно в первые секунды, загружайте отложенно: чат, карту, виджеты, попапы. Чат может подключаться через 5 секунд после загрузки или по первому скроллу — пользователь разницы не заметит.
3. Разбейте длинные задачи JavaScript на короткие, чтобы браузер успевал реагировать на действия.
4. Уберите анимации и эффекты, которые пересчитывают вёрстку при прокрутке.
5. Проверьте отзывчивость на реальном недорогом телефоне, а не только на своём рабочем ноутбуке.

Улучшаем CLS

1. Задайте явные размеры всем изображениям и видео — это снимает большую часть смещений.
2. Зарезервируйте место под баннеры, рекламные блоки и динамические вставки.
3. Настройте показ шрифтов так, чтобы текст отображался запасным шрифтом сразу, а подмена не сдвигала блоки.
4. Не вставляйте элементы над уже отрисованным контентом — плашки про cookie, акционные полосы и уведомления лучше выводить поверх или снизу.
5. Проверьте поведение при повороте экрана и на узких экранах.

Порядок работ

Если ресурсов мало, делайте в таком порядке: ответ сервера → изображения первого экрана → ревизия скриптов → CLS → всё остальное. Первые три пункта обычно дают 80% результата и не требуют переписывать сайт.

Скорость и реклама: где это бьёт по карману

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

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

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

Скорость и обход сайта роботом

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

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

План работ: что делать по шагам

1. Зафиксируйте текущие показатели. Полевые данные из Метрики отдельно по мобильным и десктопам, по ключевым типам страниц: главная, услуга, каталог, карточка, страница контактов.
2. Определите проблемные шаблоны. Обычно тормозит не «сайт», а конкретный тип страниц. Чините шаблон — исправляются сотни страниц сразу.
3. Проверьте ответ сервера. Если время до первого байта больше 600–800 мс, начинайте отсюда.
4. Проведите ревизию изображений на проблемных шаблонах: вес, формат, размеры, отложенная загрузка.
5. Соберите список всех внешних скриптов и по каждому ответьте: нужен ли, можно ли отложить, можно ли заменить на более лёгкий.
6. Поставьте задачи разработчику в терминах метрик и порогов, а не «сделайте сайт быстрее». Формулировка «LCP на мобильных на шаблоне карточки — до 2,5 с по полевым данным» проверяема, «ускорьте» — нет.
7. Внедряйте по одной группе изменений и замеряйте после каждой. Иначе вы не узнаете, что сработало.
8. Через 4 недели сравните полевые данные, отказы и конверсию в заявку.
9. Поставьте регулярный контроль. Скорость деградирует: добавили виджет, залили тяжёлые фото в новый кейс — и всё вернулось. Проверять раз в квартал достаточно.

Чек-лист быстрых побед

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

1. Пересохранить изображения первого экрана. Одна главная картинка весом 3 МБ вместо 150 КБ — это две-три секунды на мобильном интернете.
2. Снять lazy-load с картинки первого экрана, если он там стоит. Одна строчка, а LCP улучшается сразу.
3. Отложить виджет чата и обратного звонка. Подключать через несколько секунд после загрузки или по первому действию пользователя.
4. Выключить неиспользуемые пиксели и счётчики. На сайтах, которые вели разные подрядчики, их накапливается по пять-семь штук, и половина уже никому не нужна.
5. Заменить встроенную карту на статичную картинку с переходом на карту по клику. Интерактивная карта — один из самых тяжёлых элементов страницы контактов.
6. Включить сжатие текстовых ресурсов и кеширование статики на сервере, если они не включены.
7. Задать размеры всем изображениям в вёрстке — снимает большую часть смещений вёрстки.
8. Убрать лишние начертания шрифтов. Обычно реально используются два-три, а подключены шесть.
9. Отключить автовоспроизведение видео в шапке. Фоновое видео на первом экране — красиво и дорого во всех смыслах.
10. Проверить результат в Метрике через неделю, отдельно по мобильным.

Как ставить задачу разработчику

Формулировка решает половину дела. «Ускорьте сайт» — это не задача, её невозможно ни выполнить, ни принять. Рабочая постановка выглядит так: указан конкретный шаблон страниц, конкретная метрика, конкретный порог и способ проверки. Например: «На шаблоне карточки услуги добиться LCP не более 2,5 с на мобильных по данным Метрики за две недели после внедрения; время ответа сервера — не более 600 мс». К задаче прикладываются текущие замеры, чтобы было с чем сравнивать. Такую задачу исполнитель либо выполняет, либо аргументированно объясняет, почему порог недостижим — и то и другое полезно.

Чего скорость не сделает

Отдельно скажу о границах. Ускорение сайта не выведет в топ документ, который не отвечает на запрос, не заменит структуру, тексты и коммерческие факторы. Если страница не ранжируется вообще, дело не в LCP. Порядок приоритетов в продвижении я разбирал в статье про SEO-продвижение сайта в Яндексе, и скорость там — важный гигиенический пункт, но не первый в очереди.

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

Вывод

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

Практический минимум выглядит так: LCP на мобильных до 2,5 секунды, отзывчивость без подвисаний интерфейса, вёрстка, которая не прыгает при загрузке. Достигается это обычно тремя действиями — нормальным сервером, оптимизацией изображений первого экрана и ревизией сторонних скриптов. Всё остальное — тонкая настройка, к которой имеет смысл переходить, когда базовые вещи уже сделаны.

Если нужно понять, теряет ли ваш сайт посетителей на скорости и что именно чинить в первую очередь, я делаю технический разбор в рамках SEO-аудита сайта — от 30 000 ₽, а аудит посадочной страницы перед запуском рекламы — от 15 000 ₽. Экспресс-проверку основных проблем провожу бесплатно: пишите, если нужен взгляд со стороны на сайт и настройку Яндекс Директ.

Частые вопросы