Как ускорить сайт: что реально даёт прирост в Core Web Vitals

Чтобы ускорить сайт, в 9 случаях из 10 достаточно четырёх вещей: сжать и правильно отдать картинки, включить серверный кэш и сжатие, убрать или отложить лишние сторонние скрипты и задать картинкам и баннерам фиксированные размеры. Эти работы занимают от 4 до 20 часов и обычно переводят LCP из «красной» зоны (больше 4 секунд) в «зелёную» (до 2,5 секунды). Всё остальное - критический CSS, переход на HTTP/3, CDN, рефакторинг JavaScript - даёт прирост уже в десятых долях секунды и имеет смысл тогда, когда базовые четыре пункта закрыты. Актуально на октябрь 2026 года.

Ниже разбираем по порядку: какие пороги Core Web Vitals считаются нормой, чем полевые данные отличаются от лабораторных (и почему 95 баллов в PageSpeed не значат, что сайт быстрый), что конкретно двигает LCP, INP и CLS, сколько часов стоит каждый приём и в каком порядке всё это делать. Цифры - из практики Honey Hunters Digital на проектах поддержки: сайты услуг, интернет-магазины и порталы на Битриксе, WordPress, MODX и Тильде.

Что такое Core Web Vitals и какие значения считаются хорошими

Core Web Vitals - это три метрики Google, которые описывают скорость и удобство страницы с точки зрения живого посетителя: насколько быстро появился главный контент (LCP), насколько быстро страница отвечает на действия (INP) и насколько сильно прыгает вёрстка при загрузке (CLS). Пороги жёсткие и одинаковые для всех: «хорошо» - это LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1.

Рядом есть вспомогательные метрики, которые сами в Core Web Vitals не входят, но помогают понять, где именно теряется время: TTFB (время ответа сервера, норма до 0,8 секунды), FCP (первая отрисовка хоть чего-нибудь, норма до 1,8 секунды) и TBT (суммарное время блокировки главного потока, норма до 200 миллисекунд в лабораторном замере). Правило простое: если TTFB уже 1,5 секунды, картинки и скрипты можно не трогать - сначала разбираться с сервером.

Важная деталь про INP: эта метрика в 2024 году заменила прежний FID, и заменила неслучайно. FID мерил только задержку до начала обработки первого клика и на большинстве сайтов показывал «зелёный» результат даже там, где интерфейс откровенно тормозил. INP считает полный путь - от действия до следующей отрисовки - и для всех взаимодействий на странице. По нашему опыту именно переход на INP вывел из «зелёной» зоны много сайтов на тяжёлых конструкторах и шаблонах с десятком плагинов.

Полевые данные против лабораторных: почему 95 баллов не значат «быстро»

Лабораторный замер (Lighthouse, вкладка с баллами в PageSpeed Insights) - это один прогон на эмулируемом устройстве в стерильных условиях. Полевые данные (отчёт CrUX в верхней части PageSpeed, отчёт Core Web Vitals в Search Console, «Скорость загрузки страниц» в Яндекс Метрике) - это то, что реально видели посетители за последние 28 дней с их телефонов и их интернета. Решения принимают по полевым данным, баллы Lighthouse - только подсказка, куда смотреть.

Классическая ситуация: лабораторный результат 92 балла, а в полевых данных LCP 4,8 секунды и доля «хороших» загрузок 38%. Причины почти всегда одни и те же:

• Lighthouse проверяет одну страницу, обычно главную, а трафик приходит в каталог и в карточки, где картинок в десять раз больше.
• У лабораторного прогона холодный кэш и ровный канал, у живых посетителей - мобильная сеть и устройства уровня «бюджетный Android трёхлетней давности».
• Часть тормозов включается только при реальном поведении: карта, видео, чат-виджет, онлайн-консультант, баннер cookie-согласия.
• Баллы - взвешенная оценка лабораторных метрик, а в поле учитывается 75-й процентиль, то есть опыт самых «невезучих» четверти посетителей.

Практический вывод для владельца сайта: просить подрядчика «сделать 100 баллов» - плохая постановка задачи. Правильная формулировка - «вывести LCP, INP и CLS в зелёную зону в Search Console по группе URL каталога и карточек». Это проверяемо и напрямую связано с поведением посетителей.

Сколько бизнес теряет на медленном сайте

Прямая связь простая: каждая лишняя секунда загрузки увеличивает долю людей, которые уходят, не дождавшись страницы. В исследованиях ритейла и медиа за последние годы устойчиво повторяется один порядок величин: рост времени загрузки с 1 до 3 секунд повышает вероятность отказа примерно в 1,5-2 раза, а с 1 до 5 секунд - в 3-4 раза. Точный процент зависит от тематики, но направление одинаковое для всех.

На практике потери считают проще, через воронку. Допустим, на сайт приходит 6 000 посетителей в месяц, конверсия в заявку 2%, то есть 120 обращений. Если ускорение снижает долю отказов на мобильных с 62% до 52%, до контента добирается примерно на 600 человек больше, и при той же конверсии это плюс 12 заявок в месяц. При средней марже с клиента 15 000 рублей это 180 000 рублей в месяц - при разовых затратах на ускорение в районе 20-60 тысяч. Поэтому ускорение почти всегда окупается быстрее, чем редизайн или новая рекламная кампания: трафик уже куплен, его просто не доводят до формы.

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

Как снять замеры за 20 минут и понять, куда копать

Диагностика до работ обязательна: без цифр «до» вы не докажете ни себе, ни подрядчику, что что-то изменилось. Минимальный набор инструментов бесплатный, и на снятие замеров уходит около 20 минут.

1. PageSpeed Insights (pagespeed.web.dev) - по одной типовой странице каждого типа: главная, страница услуги или каталога, карточка товара, статья блога. Смотрите сначала блок полевых данных, потом «Диагностику».
2. Search Console, отчёт Core Web Vitals - единственное место, где видно распределение по всем URL сайта и группы проблемных страниц. Если сайт в Google не добавлен, это первое, что нужно исправить.
3. Яндекс Метрика, отчёт «Скорость загрузки страниц» - срезы по устройствам, регионам и типам соединения. Удобно сравнивать мобайл и десктоп и видеть, не упала ли скорость после обновления.
4. Яндекс Вебмастер, раздел «Скорость сайта» - полевые данные по мобильным и десктопным посетителям глазами Яндекса, плюс сигналы о медленном ответе сервера.
5. WebPageTest (webpagetest.org) с профилем «мобильный 4G» - даёт водопад загрузки, по которому видно конкретный тормозящий файл и очередь запросов.

Снимайте замеры всегда в одинаковых условиях и записывайте в таблицу: дата, URL, устройство, LCP, INP, CLS, TTFB. По опыту Honey Hunters Digital половина споров «стало быстрее или нет» возникает именно из-за того, что до работ никто ничего не зафиксировал, а после сравнивают мобильный замер с десктопным.

Что реально двигает LCP: шесть приёмов по убыванию эффекта

LCP почти всегда определяет один элемент: главная картинка первого экрана, крупный заголовок или блок баннера. Значит, задача сводится к двум вопросам: как быстро браузер узнаёт об этом элементе и как быстро получает его файл. Ниже приёмы в том порядке, в котором мы их применяем на проектах поддержки.

Две типовые ошибки, которые встречаются почти на каждом втором сайте. Первая: на картинку первого экрана поставлен loading="lazy" - браузеру буквально говорят «эта картинка не важна», и LCP растёт на секунду просто так. Вторая: баннер на главной подгружается слайдером через JavaScript, то есть браузер узнаёт о главной картинке только после загрузки и выполнения скрипта. Обе правятся за час и дают больше, чем неделя тонкой оптимизации.

Как чинить INP: отзывчивость, а не загрузка

INP портит не вес страницы, а длинные задачи JavaScript, которые занимают главный поток в тот момент, когда посетитель уже тыкает в кнопку. Лечение всегда идёт в одну сторону: меньше кода на главном потоке и меньше работы в обработчиках событий.

Что проверять по порядку:

• Сторонние скрипты. Онлайн-чат, коллтрекинг, A/B-тестер, аналитика на каждый клик, виджет отзывов - вместе легко дают 300-800 миллисекунд блокировки на бюджетном телефоне. Нужные оставляем, остальные удаляем, оставшиеся переводим на отложенную загрузку после первого взаимодействия.
• Тяжёлые обработчики. Классика - фильтр каталога, который на каждое нажатие пересчитывает весь список и перерисовывает DOM. Решается дебаунсом и перерисовкой только изменившейся части.
• Плагины-дубли. Две библиотеки слайдеров, два jQuery разных версий, три скрипта «липкой» шапки - типичная картина сайта, который 5 лет развивали разные подрядчики.
• Анимации на скролл. Параллакс и появление блоков часто реализованы через обработчик scroll без throttle: на телефоне это гарантированные подтормаживания.
• Гидрация на фреймворках. Если сайт на React или Vue, посмотрите, не выполняется ли при старте работа, которую можно отложить до реального взаимодействия.

Ориентир по результату: отложенная загрузка чата и коллтрекинга обычно снимает 150-400 миллисекунд INP, а разбор фильтра каталога - ещё 100-300 миллисекунд. Это ровно та разница, которая переводит метрику из «нужно улучшить» в «хорошо».

CLS: пять причин, по которым вёрстка прыгает

CLS - самая дешёвая в исправлении метрика: обычно это несколько строк CSS, а эффект посетитель замечает сразу, потому что перестаёт промахиваться по кнопкам. Сдвиги почти всегда вызваны тем, что браузер не знал заранее, сколько места займёт элемент.

1. У картинок не заданы width и height (или aspect-ratio в CSS). Браузер верстает текст, потом подгружает фото и всё съезжает вниз.
2. Шрифт подменяется на ходу. Сначала системный, потом брендовый с другой метрикой - текст перескакивает. Лечится preload шрифта и подбором запасного шрифта с похожими пропорциями.
3. Баннеры, карты и iframe без зарезервированного места. Блок с рекламой или картой появляется и раздвигает контент.
4. Уведомления и cookie-баннеры, вставленные в поток документа. Полоса согласия должна быть position: fixed, а не выталкивать страницу вниз. Про сами согласия и их обязательные элементы мы писали в разборе 152-ФЗ на сайте.
5. Контент, который дорисовывается скриптом: «товар в наличии», персональная цена, счётчик акции. Нужно резервировать место под максимальный размер блока.

Проверять CLS глазами неудобно - сдвиг случается за доли секунды. Удобнее открыть панель Performance в браузере с эмуляцией медленной сети или использовать расширение Web Vitals: оно подсвечивает прямоугольники, которые сдвинулись.

Картинки: главный источник веса почти на любом сайте

На типовом сайте услуг картинки занимают 60-80% веса страницы, и именно с них начинается ускорение. Задача - отдавать изображение в том формате и в том размере, который реально нужен конкретному устройству.

Рабочий порядок действий:

• Формат. WebP вместо JPEG и PNG экономит в среднем 25-35% веса без видимой потери качества, AVIF - до 50%, но требует чуть большей аккуратности с поддержкой старых браузеров. Для логотипов и иконок - SVG.
• Размер. Фотография 3000 пикселей по ширине, выведенная в блок шириной 400 пикселей, это чистая потеря 90% трафика. Нужны нарезки под реальные размеры блоков и атрибут srcset.
• Ленивая загрузка. loading="lazy" для всего, что ниже первого экрана, и обязательно без него для LCP-картинки.
• Ресайз на загрузке. Если контент-менеджер заливает фото прямо из телефона, никакая разовая оптимизация не поможет: нужен автоматический ресайз на стороне CMS.

Самое важное: после разовой чистки нужен регламент. Иначе через полгода контент-менеджер снова зальёт десяток фотографий по 4 мегабайта, и всё вернётся. Поэтому в поддержке мы ставим автоматическую конвертацию и держим правило «картинка в блог - не больше 200 КБ» в инструкции для редакции.

Сторонние скрипты и счётчики: сколько они стоят в миллисекундах

Каждый внешний скрипт - это отдельное соединение с чужим сервером, который вы не контролируете, плюс время на выполнение кода. На сайтах, которые приходят к нам на поддержку, мы регулярно находим 8-15 внешних подключений, из которых реально нужны три-четыре.

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

Что делать с нужными: загружать после события взаимодействия (первый скролл, клик, движение мыши) или по таймеру в 3-5 секунд, подключать с async или defer, а для метрик использовать серверную отправку, если платформа это позволяет. Чат-виджет почти всегда можно заменить на кнопку, которая подгружает сам виджет только по нажатию, - на LCP и INP это даёт заметный выигрыш, а на число обращений не влияет.

Сервер, хостинг и кэш: когда виноват не код

Если TTFB держится выше 0,8 секунды, оптимизировать фронтенд почти бессмысленно: любая страница начнётся с секундной паузы. На дешёвом шаред-хостинге с перегруженным соседом или на тарифе без нормального диска эта пауза иногда доходит до 2-3 секунд.

Что проверять на серверной стороне:

• Кэширование страниц. На Битриксе - композитный кэш и кэш компонентов, на WordPress - плагин страничного кэша, на MODX - встроенный кэш документов. Для сайтов услуг это самый дешёвый способ срезать секунду.
• Сжатие. Gzip или Brotli для HTML, CSS, JS. Проверяется одной командой curl, включается в настройках сервера или в .htaccess.
• Кэш в браузере. Заголовки Cache-Control и Expires для статики на 30 дней и больше: повторные визиты становятся почти мгновенными.
• HTTP/2 или HTTP/3. Многие сайты до сих пор работают по HTTP/1.1, где каждый файл встаёт в очередь. Переключение обычно делается на стороне хостинга за полчаса.
• Версия PHP и индексы в базе. Переход с PHP 7.4 на 8.3 часто ускоряет генерацию страницы на 20-40%, а один недостающий индекс в тяжёлом каталоге - в разы.
• CDN. Нужен, если посетители географически разбросаны или много тяжёлой статики. Для сайта услуг с трафиком в одном городе эффект обычно небольшой.

Если после всех проверок TTFB не опускается, дело в тарифе или в хостере. Как выбирать и в какой момент пора переезжать, мы подробно разобрали в статьях как выбрать хостинг для сайта и перенос сайта на другой хостинг без потери позиций. Отдельно отметим: если сайт стал медленным резко, а не постепенно, это не вопрос оптимизации - это инцидент, и его стоит разбирать по инструкции что проверить самому за 10 минут.

Что даёт мало или не даёт ничего

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

• Минификация CSS и JS сама по себе. Экономит килобайты, когда проблема в мегабайтах картинок. Делать стоит, но как сопутствующую работу, а не как главную.
• Плагин «ускорение сайта» без настройки. На WordPress такие плагины часто ломают вёрстку и ставят отложенную загрузку на LCP-картинку, то есть ухудшают метрику.
• Погоня за 100 баллами. Последние 10 баллов Lighthouse обычно стоят столько же, сколько первые 40, а на полевые метрики почти не влияют.
• Склейка всех скриптов в один файл. В эпоху HTTP/2 это уже не ускоряет, а иногда мешает кэшированию: при правке одной строки посетитель перекачивает весь бандл.
• AMP для сайта услуг. Технология потеряла поддержку в поиске и даёт больше ограничений, чем выгоды.
• Перенос на новый фреймворк «ради скорости». Переписать сайт стоит в десятки раз дороже оптимизации и несёт риски потери позиций. Если такой разговор возник, сначала честно сравните варианты - мы разбирали это в материале про стоимость редизайна сайта.

Порядок работ: план на две недели

Ускорение - это не один подвиг, а последовательность коротких шагов с замером после каждого. Такой план мы обычно ставим в работу в рамках поддержки.

1. День 1-2. Замеры и приоритеты. Полевые данные по 4 типам страниц, водопад загрузки, список тормозящих файлов и скриптов. На выходе - таблица «что чиним, сколько часов, какой ожидаемый выигрыш».
2. День 3-4. Сервер. Кэш страниц, Gzip или Brotli, заголовки кэширования статики, HTTP/2 или HTTP/3, актуальная версия PHP. Контрольная точка: TTFB до 0,8 секунды.
3. День 5-7. Картинки. Массовая конвертация в WebP, нарезки и srcset, lazy-load ниже первого экрана, fetchpriority на LCP-элементе, автоконвертация на загрузке в CMS.
4. День 8-9. Скрипты. Инвентаризация внешних подключений, удаление лишних, отложенная загрузка оставшихся, замена чата на кнопку-триггер.
5. День 10-11. Вёрстка и CLS. Размеры картинок и iframe, preload шрифтов и font-display, фиксированные габариты баннеров и уведомлений.
6. День 12-14. Контрольные замеры и регламент. Повторные замеры в тех же условиях, отчёт «было - стало», мониторинг скорости и правила для контент-менеджера.

Через 28 дней после работ нужно обязательно перепроверить Search Console: полевые данные обновляются скользящим окном, и реальная картина по всем URL появляется только спустя месяц. До этого вы видите только лабораторные замеры и собственные проверки.

Влияет ли скорость на позиции и на выдачу ИИ-поиска

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

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

В ИИ-поиске - Алиса, AI Overviews, ответы ChatGPT - скорость важна по-своему: роботы, которые собирают данные для ответов, тоже имеют лимиты по времени ожидания, и страница, которая отвечает 4 секунды, чаще просто не попадает в выборку. Что ещё нужно для попадания в такие ответы, мы собрали в отдельном разборе как оптимизировать сайт под ИИ-поиск. И наоборот: если позиции уже высокие, а заявок нет, скорость - одна из первых причин, которые мы проверяем, разбирая, почему высокие позиции не всегда дают продажи.

Сколько стоит ускорение сайта и сколько времени занимает

Ускорение считается в часах работы, а не пакетом, потому что объём зависит от того, что уже сделано. По нашей практике базовая оптимизация сайта услуг занимает 8-16 часов, интернет-магазина на Битриксе - 20-40 часов, а точечные правки вроде картинки первого экрана и отложенного чата - 2-4 часа.

В поддержке сайта Honey Hunters Digital эти часы входят в тариф. Базовый тариф - от 15 000 рублей в месяц: 4 часа работ плюс «Красная кнопка» на срочные инциденты, часы не переносятся на следующий месяц. Тариф 51 000 рублей в месяц - час работы 3 000 рублей, неиспользованные часы переносятся. Тариф 96 000 рублей в месяц - час работы 2 900 рублей, часы тоже переносятся. То есть базовая оптимизация сайта услуг укладывается в 2-4 месяца базового тарифа или в один месяц на старшем, если нужно сделать всё сразу. Сколько часов занимают типовые задачи, мы свели в таблицу оценок по доработкам сайта.

Если вы берёте работы на рынке отдельной услугой, ориентируйтесь на вилки: разовый аудит скорости - от 5 000 до 20 000 рублей, базовая оптимизация - от 20 000 до 60 000 рублей, комплексная работа с магазином - от 80 000 рублей. Насторожить должно обещание «ускорим до 90 баллов за 5 000 рублей за один день»: за эти деньги можно поставить плагин кэширования, а не разобрать причины. Что вообще должно быть в нормальном отчёте по сайту, разобрано в статье про стоимость SEO-аудита.

Чек-лист: 12 проверок, которые можно сделать сегодня

1. Прогнать 4 типовые страницы через PageSpeed Insights и записать полевые LCP, INP, CLS.
2. Проверить TTFB: если выше 0,8 секунды, начинать с сервера.
3. Найти LCP-элемент (PageSpeed его показывает) и убедиться, что на нём нет loading="lazy".
4. Посмотреть вес главной картинки: всё, что больше 300 КБ, пересжать.
5. Проверить, отдаются ли картинки в WebP или AVIF.
6. Убедиться, что у всех картинок заданы width и height.
7. Выписать все внешние скрипты и вычеркнуть те, которыми никто не пользуется.
8. Проверить, включено ли сжатие Gzip или Brotli.
9. Проверить заголовки кэширования статики.
10. Проверить протокол: HTTP/2 или HTTP/3 вместо HTTP/1.1.
11. Проверить версию PHP на хостинге.
12. Открыть отчёт Core Web Vitals в Search Console и посмотреть группы проблемных URL, а не только главную.

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

Если копаться в водопадах загрузки некогда, напишите нам - посмотрим ваш сайт, покажем, где именно он теряет секунды, и назовём честное число часов на исправление без обещаний про сто баллов. Это поддержка сайта, а если тормоза мешают расти в поиске, имеет смысл смотреть шире - вместе с SEO-продвижением. Контакты и форма - на странице контактов. А ещё у нас есть Telegram-канал «Тусовка владельцев сайтов»: туда мы складываем короткие разборы вроде «что сломалось у клиента на этой неделе и чем это лечилось» - без теории, зато с живыми примерами.

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

Можно ли ускорить сайт без разработчика?
Частично да. Включить кэш и сжатие, переключить PHP и HTTP/2 в панели хостинга, пересжать картинки перед загрузкой и убрать забытые счётчики из админки может и владелец сайта. Работа с кодом - критический CSS, отложенная загрузка скриптов, разбор тяжёлых обработчиков - требует разработчика.

Что важнее ускорять: мобильную версию или десктоп?
Мобильную. На сайтах услуг в России доля мобильного трафика обычно 60-80%, пороги Core Web Vitals для мобильных жёстче по факту (слабые процессоры и нестабильная сеть), и именно мобильные замеры чаще оказываются в красной зоне.

Сколько времени занимает ускорение сайта?
Базовая оптимизация сайта услуг - 8-16 часов работы, то есть 1-2 недели календарно с учётом согласований и замеров. Интернет-магазин - 20-40 часов. Результат в полевых данных Search Console виден примерно через 28 дней после внедрения.

Правда ли, что после ускорения вырастут позиции?
Напрямую - нет, скорость сама по себе слабый фактор ранжирования. Но она улучшает поведенческие метрики и индексацию, поэтому в сочетании с нормальными текстами и структурой вклад заметен. Ждать роста позиций только от ускорения не стоит.

Нужен ли CDN небольшому сайту?
Обычно нет. Если посетители находятся в одном-двух регионах, а статика умещается в пару мегабайт, выигрыш от CDN будет в пределах погрешности. CDN имеет смысл при географически разбросанной аудитории, большом объёме медиа или при защите от нагрузок.

Что делать, если сайт на конструкторе и код править нельзя?
На Тильде и похожих платформах доступны картинки, число блоков и внешние скрипты - это уже даёт основную часть выигрыша. Если и после чистки метрики остаются красными, вопрос переходит в плоскость переезда: плюсы, минусы и порядок действий мы разобрали в статье про сайт на Тильде.