Как медленный сайт тихо отбирает у вас заказы

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

Что такое Core Web Vitals, если без маркетинга

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

Сегодня в наборе три метрики: LCP, CLS и INP. До 12 марта 2024 года вместо INP была FID, которая мерила только первое касание. Google её выкинул — слишком лукавая метрика получалась: страница бодро отвечала на первый клик, а потом залипала на каждом следующем.

Три метрики и их пороги

LCP — Largest Contentful Paint

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

CLS — Cumulative Layout Shift

Насколько сильно страница «едет» во время загрузки. Подгрузился шрифт — текст подпрыгнул. Приехал баннер — кнопка уехала вниз. Порог — 0,1. Выше — значит, пользователь регулярно жмёт не туда, куда целился. Знаете это чувство, когда хочешь нажать «Оформить», а попадаешь в рекламу? Вот это оно.

INP — Interaction to Next Paint

Как быстро интерфейс отвечает на действие — клик, тап, ввод — в течение всей сессии, а не только в первую секунду. Порог — 200 миллисекунд. Эту метрику Google ввёл вместо FID именно потому, что она ловит «подвисания» на протяжении всего визита. Открылась страница шустро, а фильтр в каталоге думает полсекунды на каждый чекбокс? INP это увидит. Вы — нет.

Таблица: пороги, которые нужно запомнить

Важная деталь, которую типичный ИТ-подрядчик упускает: Google оценивает не среднее, а 75-й процентиль реальных посещений за последние 28 дней. Перевожу на человеческий. Три четверти ваших пользователей должны укладываться в порог. Если у четверти посетителей LCP пять секунд — всё, страница в жёлтой или красной зоне, и никакие красивые цифры из лаборатории не спасут.

Яндекс тоже смотрит на секундомер

Вопрос, который мне задают постоянно: «У нас основной трафик из Яндекса, зачем нам метрики Google?» Ответ короткий. Яндекс тоже учитывает скорость загрузки как сигнал качества сайта. Пороги у него не опубликованы с такой же точностью, но физика та же: медленный сайт раздражает человека, человек уходит, поведенческие факторы проседают, позиции едут вниз. Ориентироваться на пороги Google — разумный минимум для обоих поисковиков. Делать быстро для Google и медленно для Яндекса технически невозможно, так что вопрос снимается сам собой.

Двойной удар: позиции и продажи одновременно

Ранжирование — только половина беды. Вторая половина — конверсия. Данные исследований сходятся: рост времени загрузки с одной до трёх секунд поднимает вероятность отказа примерно на треть. Человек не дождался — человек ушёл. Он не узнал, что у вас дешевле. Не увидел ваши отзывы. Не позвонил. Он просто исчез из вашей воронки, и в аналитике это выглядит как «пришёл и сразу вышел».

Получается петля. Медленный сайт хуже ранжируется — трафика меньше. Тот трафик, что дошёл, хуже конвертируется — заявок ещё меньше. Вы при этом платите за рекламу по полной: клик оплачен, а посетитель даже не увидел предложение.

Каждый лишний мегабайт на главной — это рекламный бюджет, который вы сожгли до того, как человек прочитал первое слово.

Почему сайт тормозит: типичные причины

• Картинки в полном разрешении с фотоаппарата, без сжатия и без современных форматов
• Десяток скриптов аналитики, чатов и виджетов, которые грузятся раньше контента
• Хостинг, который держит сайт на одном ядре вместе с сотней соседей
• Отключённое или ненастроенное кеширование статики в браузере
• Сторонние блоки — отзывы, карты, реклама, — которые приезжают с опозданием и сдвигают вёрстку
• Веб-шрифты без зарезервированного места под текст: страница «моргает» и прыгает
• Тема или шаблон CMS, которая тянет библиотеки «на все случаи жизни», из которых вы используете две кнопки

Заметьте: половина пунктов — про сервер и инфраструктуру, половина — про фронтенд. Чинить только одну половину — как менять резину на одном колесе.

Виджет онлайн-чата, который грузится раньше вашего предложения, продаёт только одно — скорость конкурента.

Как мерить честно, а не «на глаз»

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

Поэтому смотрите на две вещи. Первая — отчёт Core Web Vitals в Search Console: это полевые данные, собранные с реальных людей. Вторая — лабораторный тест в PageSpeed Insights или аналогичном инструменте: он показывает, что конкретно тормозит, но в стерильных условиях. Лаборатория говорит «почему». Поле говорит «насколько плохо». Нужны обе, и ориентироваться поисковик будет на второе.

Отдельный момент: если на сайте мало трафика, полевых данных может просто не хватить, и в отчёте будет пусто. Это не значит, что всё хорошо. Это значит, что вас пока никто не измерил.

Что будет, если ничего не делать

Ничего драматичного. И это самое страшное.

Скорость не ломает сайт разом. Она подтачивает его месяцами. Позиции сползают на строчку-две ниже конкурента с таким же контентом. Доля отказов на мобильных подрастает на пару процентов. Конверсия в заявку теряет десятые доли. В ежемесячном отчёте каждое из этих движений — шум. За год они складываются в сумму, за которую можно было нанять ещё одного продавца, а вы её даже не заметили.

Падение сайта вы увидите за минуту. Падение скорости — за год, по годовому отчёту, когда уже поздно.

Нет триггера. Нет аварии, нет красного экрана, нет звонка «у нас всё упало». Потому скорость в списке приоритетов владельца всегда «после праздников». А конкуренты, у которых есть кто-то с секундомером, в это время тихо собирают ваших клиентов.

Сценарий: как это выглядит в жизни

Компания оказывает услуги с высоким чеком. Реклама льёт трафик стабильно, бюджет приличный, а заявок вдвое меньше плана. Владелец открывает сайт — летает. Маркетолог открывает — летает. Все пожимают плечами и ругают рекламу.

Смотрим метрики. На мобильных, откуда приходит две трети трафика, LCP за четыре секунды: на главной карусель из пяти фотографий по три мегабайта каждая. CLS в красной зоне: блок отзывов подгружается через пару секунд после контента и сдвигает кнопку «Оставить заявку» вниз ровно в тот момент, когда палец уже над ней. Человек попадает в отзывы, думает «что за ерунда» и закрывает вкладку. На офисном компьютере этого не воспроизвести никогда. Для реального клиента это разница между заявкой и уходом.

Второй случай встречается не реже. Сайт вылизан под десктоп: красиво, быстро, менеджеры гордятся. Но Google индексирует и ранжирует прежде всего мобильную версию — так работает mobile-first индексация. А на мобильной версии тот же сайт тянет полный десктопный набор скриптов и картинок, только на экране в шесть дюймов. Итог: отличные показатели там, где их никто не измеряет, и провал там, где решается судьба позиций.

Что делаем мы и чем это отличается

Когда к нам приходят с «реклама не работает» или «позиции едут», мы в АйТи Фреш первым делом снимаем фактические Core Web Vitals по мобильной версии. Не слушаем впечатления. Не открываем сайт «посмотреть». Смотрим цифры за 28 дней и список URL в жёлтой и красной зоне. Потом — раскладка причин по двум слоям: сервер и фронтенд. Только после этого разговор о том, что делать.

Теперь про то, как это обычно делают другие. Типичный ИТ-подрядчик отвечает на жалобу про скорость фразой «сожмите картинки» и считает вопрос закрытым. Картинки сжали — сайт по-прежнему в красной зоне, потому что хостинг отдаёт первый байт за секунду, а восемь сторонних виджетов блокируют отрисовку. Дешёвый конструктор сайтов вообще не даёт доступа к серверу и к порядку загрузки ресурсов: там потолок скорости задан платформой, и вы в него упираетесь, сколько бы ни старались. Штатный «ответственный за сайт» на полставки чаще всего даже не знает, где лежит отчёт Core Web Vitals, — и это не его вина, у него ещё тридцать задач. Все эти варианты объединяет одно: никто не отвечает за цифру. А если за цифру никто не отвечает, она не меняется.

Мы отвечаем. За цифру, а не за «сделали что смогли». Если причина упирается в инфраструктуру — слабый сервер, нет кеширования, нет сжатия, нет нормального веб-сервера впереди приложения, — берём сервер на обслуживание от 7 000 ₽ в месяц и доводим серверную часть до состояния, в котором она перестаёт быть узким местом. Если причина во фронтенде — чистим скрипты, резервируем место под медиа и шрифты, переводим картинки в современные форматы, выносим тяжёлые блоки ниже первого экрана. И главное: мониторим после каждого изменения на сайте. Новый виджет чата, баннер к акции, обновление темы — любое из этого способно за один день вернуть вас в красную зону. Проверка один раз в год — это не контроль, а ритуал.

Чек-лист: самопроверка за полчаса

• Открыть отчёт Core Web Vitals в Search Console и посмотреть именно мобильную вкладку
• Прогнать главную и три ключевые страницы через PageSpeed Insights с телефона, а не с офисного компьютера
• Проверить вес картинок первого экрана: больше 200–300 КБ на одно изображение — повод задуматься
• Пересчитать сторонние скрипты: чаты, аналитика, пиксели, карты — и спросить себя, какие из них реально нужны
• Убедиться, что у изображений и рекламных блоков задан размер заранее, чтобы вёрстка не прыгала
• Замерить время ответа сервера (TTFB): больше 600–800 мс — проблема на стороне хостинга
• Пощёлкать фильтры и формы на телефоне: подвисает ли интерфейс на каждом касании
• Записать результаты и повторить проверку после любого обновления сайта

Не уверены, что видят ваши клиенты с телефона? Не гадайте. Напишите нам в АйТи Фреш — снимем реальные Core Web Vitals вашего сайта по мобильной версии, покажем, где именно утекают позиции и заявки, и скажем честно, что чинить первым.

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