Скорость сайта и Core Web Vitals по‑человечески

Core Web Vitals — это три метрики, которыми поисковики измеряют, насколько сайтом неприятно пользоваться. LCP отвечает на вопрос «когда я наконец увижу главное», INP — «сайт вообще реагирует на мои нажатия», CLS — «почему кнопка уехала в момент клика». Всё. Никакой магии там нет, и чинятся они конечным списком работ, который почти всегда один и тот же.

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

LCP — когда появился главный элемент

Largest Contentful Paint засекает момент, когда в видимой части экрана отрисовался самый крупный элемент: обычно это баннер на первом экране, фото товара или большой заголовок. Не когда начал загружаться сайт и не когда догрузился последний скрипт, а когда человек увидел то, ради чего пришёл. Это метрика, которую чаще всего и имеют в виду, когда говорят «сайт тормозит».

INP — как быстро сайт отвечает на действия

Interaction to Next Paint измеряет задержку между нажатием и видимой реакцией: развернулось меню, открылся фильтр, подсветилась вкладка. Плохой INP — это когда человек тыкает в кнопку три раза, потому что не понял, сработало ли. На лендингах он обычно в порядке, а вот в каталогах с фильтрами и в личных кабинетах ломается регулярно.

CLS — насколько прыгает вёрстка

Cumulative Layout Shift считает, сколько содержимого страницы съехало уже после отрисовки. Классика жанра: человек целится в «Купить», сверху догружается баннер, всё уезжает вниз, палец попадает в «Удалить». Это самая дешёвая в починке метрика из трёх и самая обидная, если её не чинить.

На что скорость влияет на самом деле

Вокруг Core Web Vitals много мифов в обе стороны. Честная позиция такая: как фактор ранжирования скорость слабая. Медленный сайт с уникальным товаром и нормальными текстами обгонит быстрый пустой. Но как фактор конверсии скорость очень сильная, и вот тут цифры заметные.

• Каждая лишняя секунда до появления первого экрана на мобильных стабильно съедает от 5 до 10% людей, которые просто не дожидаются.
• Больше всего страдает мобильный трафик из рекламы: человек пришёл по объявлению, ему некомфортно ждать, он возвращается в выдачу. Вы заплатили за клик и не получили ничего.
• На промо-странице, которую мы собирали за 9 дней, скорость была не украшением, а обязательным условием: трафик шёл платный, и каждая секунда стоила деньгами.
• В каталогах медленная фильтрация бьёт по глубине просмотра: люди перестают перебирать варианты и уходят с первой страницы выдачи товаров.

Из чего складывается медленная загрузка

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

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

Что даёт наибольший выигрыш

Порядок работ по соотношению «эффект к трудозатратам» за последние годы почти не меняется. Мы идём сверху вниз и обычно останавливаемся, когда метрики зелёные, а не когда закончился список.

1. Картинки. Пережать в WebP или AVIF, отдавать под нужный размер экрана, проставить width и height, всё ниже первого экрана — ленивой загрузкой. Самый скучный пункт и самый прибыльный: типовой выигрыш по LCP — 1–2 секунды за 6–10 часов работы.
2. Серверный рендеринг и кэш. Отдавать готовый HTML вместо белого экрана с последующей дорисовкой. На Next.js это архитектурное решение, которое принимается один раз и снимает целый класс проблем.
3. Ревизия сторонних скриптов. Выкинуть то, чем никто не пользуется, остальное грузить отложенно. Обычно с сайта уезжает два-три виджета, про которые все забыли.
4. Шрифты. Два начертания вместо пяти, локальная раздача вместо внешнего сервиса, font-display со свопом, чтобы текст был виден сразу.
5. Разделение кода. Не тащить в первый экран JavaScript всего сайта — каталог, кабинет и калькулятор грузятся, когда нужны.
6. База данных. Индексы в MongoDB под реальные запросы, агрегации вместо перебора в коде. Здесь эффект точечный, но на каталогах он решает.

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

Как измерять, чтобы не обманывать себя

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

• PageSpeed Insights — лабораторный замер плюс полевые данные, если у сайта хватает трафика. Начинать всегда стоит с него.
• Вкладка Performance в браузере — когда нужно понять, какой именно скрипт держит главный поток и портит INP.
• Свой сбор метрик с реальных пользователей — небольшой скрипт шлёт LCP, INP и CLS на наш сервер, дальше смотрим динамику по неделям и по типам страниц.
• Яндекс.Метрика и Search Console — чтобы связать скорость с отказами и заявками, а не любоваться цифрами в вакууме.

Сколько это стоит

Оптимизация существующего сайта — это обычно 20–60 часов работы, то есть от 27 000 до 85 000 ₽ и две-четыре недели с учётом замеров и согласований. Мы начинаем с аудита на 6–8 часов, где считаем, что именно даст выигрыш и сколько секунд стоит каждая работа. Если по итогам аудита выясняется, что сайт медленный архитектурно и правки дадут 0,3 секунды, — так и говорим, и тогда разговор переходит в переезд на новую платформу.

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

Чего мы не делаем ради цифр

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

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

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

Короткие ответы

• скорость
• core web vitals
• фронтенд