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

Владелец бизнеса обычно узнаёт о Core Web Vitals одним из двух способов: подрядчик присылает скриншот PageSpeed с красными цифрами и счёт на «оптимизацию», либо в Google Search Console появляется письмо о проблемах с URL. В обоих случаях непонятно главное — сколько это стоит бизнесу и стоит ли вообще тратить на это деньги. Эта статья не про то, как устроены метрики и как их чинить в коде: техническую сторону мы подробно разобрали в материале Core Web Vitals: что это такое и как их починить. Здесь — взгляд руководителя: как скорость связана с позициями и заявками, где она действительно теряет деньги, а где это преувеличение, и как поставить задачу так, чтобы оплатить результат, а не красивый отчёт.

Три цифры, которые стоит понимать без программиста

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

• LCP — через сколько секунд человек видит главное содержимое страницы: первый экран, фото товара, заголовок с предложением. Хорошо — до 2,5 секунды, плохо — больше 4.
• INP — как быстро страница реагирует на нажатие: на кнопку «В корзину», раскрытие меню, выбор даты в форме. Хорошо — до 200 миллисекунд, плохо — больше 500.
• CLS — насколько «прыгает» вёрстка при загрузке. Тот самый момент, когда вы целитесь в кнопку, а она уезжает вниз из-за подгрузившегося баннера. Хорошо — до 0,1, плохо — больше 0,25.
• Оценка ставится по 75-му перцентилю: страница считается хорошей, если уложилась в порог хотя бы у трёх посетителей из четырёх. Иными словами, если сайт летает у вас в офисе, а у четверти клиентов на слабых телефонах тормозит, — он не проходит.

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

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

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

Где медленный сайт теряет деньги на самом деле

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

• Первый экран рекламной посадки. Человек кликнул по объявлению в Директе, а видит белый экран или крутящийся загрузчик. Каждый такой уход — оплаченный клик, который не дал даже шанса продать.
• Карточка товара или услуги. Фото, цена и кнопка появляются последними, потому что раньше грузятся виджеты, счётчики и чат. Покупатель уходит сравнивать к соседу, у которого всё видно сразу.
• Корзина и форма заявки. Здесь работает INP: если нажатие на кнопку «Оформить» ничего не меняет секунду-другую, человек жмёт ещё раз, получает дубль заказа или решает, что сайт сломался.
• Прыгающая вёрстка в форме. Из-за высокого CLS посетитель нажимает не на ту кнопку, попадает на другую страницу и не возвращается.
• Мобильный трафик из соцсетей и мессенджеров. Ссылку открывают на ходу, по мобильному интернету — именно в этих условиях сайт показывает свои худшие цифры.

Условный пример: как посчитать цену медлительности

Ниже — не реальный кейс, а схема расчёта, которую можно повторить на своих цифрах из Метрики. Допустим, рекламная посадка получает 3 000 визитов в месяц, средняя стоимость клика — 60 ₽, бюджет — 180 000 ₽. В отчёте Метрики видно, что доля отказов на мобильных заметно выше, чем на десктопе, а в Search Console эта страница помечена как медленная по LCP. Если после ускорения первого экрана хотя бы на 10% больше посетителей дойдут до формы, при прежней конверсии формы это те же 10% дополнительных заявок без увеличения рекламного бюджета. Дальше умножаете на средний чек и маржу — и получаете потолок, который разумно тратить на оптимизацию этой страницы. Если выходит меньше стоимости работ, оптимизировать её сейчас незачем, и это нормальный вывод.

Такой расчёт полезен ещё и тем, что переводит разговор с подрядчиком из плоскости «у вас 43 балла из 100, надо 90» в плоскость «эта страница приносит столько-то заявок, ускорение должно дать столько-то». Баллы PageSpeed — лабораторная оценка, которая сама по себе ни на что не влияет. Влияют полевые данные и поведение людей.

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

Как самому посмотреть состояние сайта за 15 минут

• Google Search Console → раздел «Основные интернет-показатели». Отдельно для мобильных и для компьютеров. Здесь страницы сгруппированы: «хорошие», «требуют улучшения», «плохие». Это и есть полевые данные, по которым Google оценивает сайт.
• PageSpeed Insights (pagespeed.web.dev) — вставьте адрес ключевой страницы. Смотрите верхний блок «Данные реальных пользователей», а не большой круг с баллом внизу. Если верхнего блока нет, значит, у страницы мало трафика из Chrome и Google оценивает её по группе похожих страниц или по сайту целиком.
• Яндекс Метрика → отчёт «Мониторинг» и сегментация по типу устройства: сравните отказы и глубину просмотра на мобильных и на компьютерах. Большой разрыв — повод проверить скорость именно мобильной версии.
• Свой телефон, мобильный интернет, режим инкогнито. Откройте главную, ключевую услугу и форму заявки. Субъективное «долго» на этом тесте почти всегда подтверждается цифрами.

Что чинить первым: приоритеты для руководителя

Оптимизировать весь сайт сразу — дорого и не нужно. Разумный порядок выглядит так:

• Страницы, на которые вы покупаете трафик. Рекламные посадки и разделы, куда ведут кампании. Здесь каждый потерянный посетитель уже оплачен.
• Страницы, которые дают больше всего заявок из поиска. Их список есть в Метрике в отчёте по страницам входа с фильтром по целям.
• Шаблоны, а не отдельные страницы. Если медленная карточка товара, чинить надо шаблон карточки — и сразу ускорятся все тысячи товаров.
• Сторонние скрипты. Чаты, виджеты обратного звонка, квизы, несколько систем аналитики одновременно. Часто самая быстрая победа — убрать то, чем никто не пользуется, и это решение руководителя, а не программиста.
• Всё остальное — по мере появления данных, а не по списку из отчёта.

Типичные ошибки при заказе оптимизации

• Платить за баллы PageSpeed. Лабораторный балл легко «нарисовать» трюками, которые не меняют опыт реальных людей. Принимайте работу по полевым данным в Search Console — они обновляются со скользящим окном в 28 дней, так что результат виден не на следующий день, а примерно через месяц.
• Оптимизировать десктоп. На компьютере в офисе почти всё быстро. Проблемы живут на мобильных.
• Убирать то, что продаёт. Ускорить страницу, удалив фотографии товара или отзывы, — плохая сделка. Задача — показать то же самое быстрее, а не показать меньше.
• Добавлять новые виджеты после оптимизации. Через полгода маркетинг подключил ещё два сервиса, и сайт вернулся к прежним цифрам. Нужен контроль: кто и что добавляет на сайт.
• Не связывать работу с цифрами бизнеса. Если до начала не зафиксированы конверсия и отказы на ключевых страницах, после работы нечего будет сравнить.

Когда достаточно доработки, а когда нужен новый сайт

Доработки хватает, если проблемы локальные: тяжёлые картинки, лишние скрипты, медленный хостинг, отсутствие кэширования. Сложнее, когда медлительность заложена в саму платформу: конструктор, который грузит один и тот же тяжёлый код на каждую страницу, тема с десятками плагинов или сайт, где содержимое собирается в браузере и до этого момента экран пустой. В таких случаях каждую неделю оптимизации вы платите за борьбу с архитектурой. Мы в таких ситуациях обычно предлагаем пересборку на Next.js — почему именно этот стек, объясняем в статье Next.js для бизнеса. Зелёная зона Core Web Vitals у нас входит в результат разработки сайта, а не продаётся отдельной услугой.

Что спросить у подрядчика до начала работ

Хороший ответ на эти вопросы отличает работу над скоростью от продажи «пакета оптимизации». Задайте их письменно и сохраните ответы — потом по ним удобно принимать работу.

• По каким данным вы будете оценивать результат — по полевым из Search Console или по лабораторному баллу? Правильный ответ: по полевым, лабораторные — только для диагностики.
• Какие конкретно страницы и шаблоны вы будете трогать и почему именно их? Ответ должен опираться на ваш трафик и заявки, а не на общий список.
• Что из найденного требует вашего решения? Отказ от виджета, замена хостинга, изменение первого экрана — это бизнес-решения, и подрядчик должен вынести их вам, а не принимать молча.
• Что будет с правками при следующем обновлении темы, CMS или плагинов? Если оптимизация слетает после каждого обновления, вы платите за неё снова и снова.
• Как вы проверите, что ничего не сломалось? Формы, оплата, цели в Метрике и коллтрекинг должны работать после ускорения так же, как до него.

Как не потерять скорость после запуска

• Назначьте ответственного, без согласия которого на сайт не добавляется ни один сторонний скрипт.
• Раз в месяц смотрите отчёт «Основные интернет-показатели» в Search Console — это 10 минут.
• Загружайте фото через админку, которая сама сжимает и уменьшает изображения, а не заливайте исходники с камеры.
• После каждого крупного изменения — нового раздела, редизайна, смены хостинга — проверяйте ключевые страницы в PageSpeed Insights.
• Включите скорость в регулярный SEO-отчёт: позиции, трафик, заявки и состояние Core Web Vitals рядом. Так проще видеть связь, если она есть.

Вывод и следующий шаг

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