Как ускорить сайт в 2026: Core Web Vitals без магии и мифов

Скорость сайта — единственный технический фактор, который одновременно влияет и на позиции в поиске, и на конверсию, и на стоимость рекламы. Разница между сайтом за 2 секунды и за 6 секунд — это 20–40% отказов, минус треть заявок и заметное падение в выдаче. В этой статье — что реально даёт ускорение, а что попадает в отчёты аудиторов «для галочки».

Что такое Core Web Vitals и зачем их знать заказчику

Core Web Vitals — это три метрики, которые Google (и с 2024 года Яндекс) считает главными для UX. Их измеряют по реальным посетителям, а не по синтетическим тестам, поэтому «зелёный» PageSpeed на одной странице ещё не значит, что у всех пользователей быстро.

INP заменил FID в марте 2024 и стал главной болью тяжёлых сайтов — он ловит любые тормоза при взаимодействии, а не только первый клик. Битрикс-магазины с десятками сторонних скриптов чаще всего валятся именно на INP, а не на LCP.

С чего начать: сначала измерить, потом чинить

• Google PageSpeed Insights — быстрый чекап конкретной страницы + данные CrUX по реальным посетителям за 28 дней.
• Search Console → «Основные интернет-показатели» — какие URL проседают у реальных пользователей. Именно с них начинают.
• WebPageTest — «водопад» загрузки, видно, какой ресурс задерживает LCP.
• Chrome DevTools → Performance — записать сессию и посмотреть, что грузит основной поток и ломает INP.
• Яндекс.Метрика → «Скорость загрузки страниц» — те же метрики, но по русскоязычной аудитории.

Не оптимизируйте сайт по одному прогону PageSpeed. Один и тот же URL может показать 45 и 82 балла с разницей в минуту — это нормально. Опирайтесь на данные за 28 дней и медиану, а не на скриншот.

LCP: как ускорить главный экран

• Найдите LCP-элемент (обычно это hero-картинка или заголовок) — DevTools показывает его в Performance.
• LCP-картинку конвертируйте в WebP/AVIF, отдавайте нужный размер под вьюпорт через srcset, добавьте fetchpriority="high" и уберите loading="lazy" именно с неё.
• Шрифт заголовка загружайте с font-display: swap и preload — иначе LCP тормозит на FOIT.
• Уберите с главного экрана всё, что рендерится через JS: слайдеры, отзывы, каталог. Их можно подгрузить после первой отрисовки.
• TTFB > 800 мс → проблема на сервере: медленный хостинг, тяжёлый Битрикс без кэша, дорогие SQL-запросы. Никакая клиентская оптимизация это не спасёт.

INP: борьба с тормозами при клике

INP ломается, когда после клика браузер долго считает JS вместо того, чтобы обновить UI. Типовые виновники — аналитика, чат-боты, коллтрекинг, старый jQuery-код и тяжёлые слушатели скролла.

• Отложите сторонние скрипты (Метрика, GTM, JivoSite, Callibri) через defer или загрузку по первому взаимодействию — эффект видно сразу.
• GTM вынесите в Server-Side режим или хотя бы уберите из него всё, кроме основной аналитики.
• Разбейте длинные задачи JS на куски через requestIdleCallback / setTimeout — браузер успеет отреагировать на клик.
• Уберите синхронный jQuery из header. Битрикс-шаблоны это любят — переносите в конец body или заменяйте на нативный JS.
• Тяжёлые обработчики скролла и resize оборачивайте в throttle/debounce.

CLS: чтобы вёрстка не прыгала

• Задавайте картинкам width/height в HTML — браузер зарезервирует место.
• Для рекламных блоков и виджетов заранее выделяйте min-height контейнера.
• Шрифты — с font-display: swap и локальным fallback схожих метрик (size-adjust), чтобы текст не «прыгал» при подмене.
• Не вставляйте баннеры и cookie-плашки над контентом после загрузки — размещайте снизу или заранее выделяйте место.

Что даёт максимальный эффект за минимальные деньги

Мифы, на которые не стоит тратить бюджет

• «Переписать всё на React/Next» — если проблема в тяжёлых сторонних скриптах и картинках, фреймворк её не решит.
• «Купить премиум-хостинг за 50 тыс/мес» — если рендер тормозит на клиенте, дорогое железо не поможет.
• «Гнаться за 100/100 в PageSpeed» — реальному бизнесу достаточно уверенно зелёной зоны CrUX. Разница между 85 и 98 баллами не отражается на конверсии.
• «Отключить jQuery полностью» — часто это неделя работы ради 20 мс INP. Дешевле починить конкретные тяжёлые обработчики.

Когда пора звать разработчиков

Если после базовых мер (сжатие картинок, отложенная аналитика, preload LCP) метрики всё ещё в жёлтой или красной зоне — проблема глубже: серверный рендер, архитектура запросов к БД, тяжёлый шаблон Битрикса, отсутствие полноценного кэширования. Такие вещи трогать без разработчика опасно: можно уронить магазин под нагрузкой.

Наши инженеры проводят аудит производительности за 1–2 дня и дают приоритетный план: что сделать сегодня, чтобы завтра увидеть рост, и что запланировать на следующий спринт. Часто первые 30% ускорения обходятся в 15–30 тысяч рублей и окупаются за пару недель за счёт роста конверсии.