Core Web Vitals - это не «буквы для сеошников», а измеримая скорость и стабильность страницы. Когда поисковики давят на медленные сайты, они бьют по тем, кто теряет клиентов на мобильном интернете и слабом железе. В 2026 это уже часть конкуренции, а не «дополнительная опция».
Ниже - что править в первую очередь и как связать с деньгами, без заумных графиков.
LCP - главный картинка и первый экран
Тяжёлый баннер, автоплей видео, шрифты из десяти файлов - классика провала. Сжали медиа, отложили неважное, отдали статику с CDN - уже движение. Цель простая: быстрее увидел смысл, быстрее кликнул.
CLS - ничего не прыгает
Реклама, шрифты, всплывающие баннеры сдвигают кнопку в момент клика - это не «мелочь», это потерянные заказы. Резервируйте место под блоки, не подгружайте гигантские виджеты в первый экран без нужды.
INP - отклик на действия
Долгий JS на главной, тяжёлые трекеры, неоптимальные обработчики - всё это ощущается как «лагает». Обрежьте трекинг до нужного минимума, гоняйте тяжёлое после взаимодействия.
Сколько теряете на конверсии
Ориентиры из практики: заметное улучшение скорости на мобиле часто даёт единиц процентов конверсии, на большом трафике это уже деньги. Считайте до/после честно, одной и той же неделей, без смены рекламы в середине теста.
Окупаемость за месяц
Реально, если трафик уже есть и вы не ломали воронку другими изменениями. Если трафика мало - сначала трафик, иначе любая оптимизация «не окупается» математически.
Третьи стороны
Виджеты чатов, тяжёлые баннеры рекламных сетей, счётчики «на всякий случай» - частая причина провала. Оставьте только то, что реально кормит решения. Остальное подгружайте после согласия или после первого действия.
Картинки
Форматы нового поколения, правильные размеры, ленивая загрузка ниже первого экрана. Не заливайте пятимегабайтные PNG там, где хватит оптимизированного WebP.
Культура релизов
Скорость ломается обратно, если каждый релиз добавляет новый тяжёлый скрипт «потому что маркетинг попросил». Введите бюджет на вес страницы и проверку метрик после каждого релиза.
Регрессия скорости в CI
Lighthouse CI или аналог на ключевых URL, пороги по LCP/INP/CLS. Падение метрики = блокер релиза, как упавший тест.
Храните историю метрик, чтобы видеть медленный дрейф, а не только резкие провалы.
Третьи стороны и тег-менеджер
Контроль списка скриптов, async/defer по умолчанию, запрет произвольных вставок маркетинга без техревью.
LCP: реальные виновники
Часто это не «тяжёлый React», а один неоптимизированный баннер или шрифт. Пройдитесь по цепочке критического пути: что блокирует первый экран, можно ли отложить, можно ли уменьшить.
INP и сторонние скрипты
Аналитика, чаты, пиксели — типичные тормоза ввода. Грузите отложенно, режьте полномочия iframe, задавайте бюджет на главной.
CLS и реклама
Резервируйте место под баннеры, не вставляйте динамические блоки над кнопкой «купить». Для пользователя это не «чуть поехало», а потерянный клик.
Бэкенд и кэширование API
Быстрый фронт не спасает медленный `/cart`. Профилируйте p95, ставьте кэш на горячие справочники, следите за N+1 в ORM.
Мобильные сети и офлайн
Тестируйте на 3G-throttle регулярно, не раз в квартал. Покажите skeleton вместо белого экрана — воспринимаемая скорость тоже метрика.
Процесс: бюджет скорости в бэклоге
Выделите capacity на регрессию метрик каждый спринт. Скорость деградирует постепенно, как проценты на долг — лечить дешевле рано.
Нужен аудит скорости и план работ - контакты GERS, дадим короткий отчёт без лишней теории.