Скорость сайта: что реально влияет на конверсию

Почему гонка за баллами PageSpeed — дорогая и бесполезная

Разница между 75 и 98 баллами PageSpeed — это обычно десятки часов работы разработчика: инлайн критического CSS, выпиливание сторонних скриптов, борьба за каждые 50 миллисекунд. Разница для пользователя — почти нулевая: он не видит баллы, он видит, когда на экране появился контент и когда сайт начал реагировать на нажатия.

Балл — это синтетическая оценка лабораторного прогона на эмуляции среднего устройства. Он полезен как термометр, но оптимизировать нужно не его, а конкретные метрики, по которым поисковики и пользователи реально судят о сайте. Для Google это фактор ранжирования Core Web Vitals, для Яндекса скорость работает через поведенческие: медленный сайт — отказы, возвраты в выдачу, потерянные позиции.

Ориентир, от которого стоит отталкиваться: LCP ¹ до 2,5 секунды на мобильном при соединении уровня 4G. Достигли — дальнейшие вложения в скорость почти не окупаются, деньги полезнее направить на коммерческие факторы и контент.

Core Web Vitals простыми словами: LCP, INP, CLS

LCP (Largest Contentful Paint) — через сколько секунд появился самый крупный элемент первого экрана: баннер, фото товара, заголовок. Это и есть субъективное «сайт загрузился». Норма — до 2,5 с, зона проблем — больше 4 с.

INP (Interaction to Next Paint) — как быстро сайт отвечает на действия: клик по кнопке, открытие меню, ввод в поле. Норма — до 200 мс. Плохой INP — это «нажал, и ничего не происходит»; чаще всего его портят тяжёлые скрипты аналитики, чатов и виджетов.

CLS (Cumulative Layout Shift) — насколько скачет вёрстка при загрузке. Классика: хотел нажать «Купить», а в этот момент сверху догрузился баннер и палец попал по рекламе. Норма — до 0,1. Лечится указанием размеров для изображений, баннеров и рекламных блоков заранее.

Этих трёх метрик достаточно, чтобы говорить о скорости предметно. Всё остальное в отчётах — вспомогательная диагностика.

Как мерить: PageSpeed Insights, Метрика и полевые данные

Главное правило: смотрите полевые данные (реальные пользователи), а не только лабораторные. В PageSpeed ² Insights это верхний блок «Данные реальных пользователей» из CrUX — он показывает, что происходит у живых посетителей за 28 дней. Лабораторный прогон ниже — для диагностики причин, не для оценки. ³

В Яндекс Метрике смотрите отчёт по времени загрузки страниц и связку с отказами: сегментируйте по устройствам — почти всегда проблема именно в мобильных. Google Search Console в разделе «Основные интернет-показатели» покажет, какие группы URL не проходят по LCP/INP/CLS — удобно, чтобы найти проблемные шаблоны страниц, а не отдельные URL.

Типичная ошибка — мерить скорость с рабочего компьютера по оптоволокну и решить, что всё хорошо. Проверяйте мобильную версию: у большинства коммерческих сайтов основная доля трафика приходится на смартфоны, и именно там LCP 4+ секунды. Кстати, резкие изменения трафика — повод проверить не только скорость: в кейсе с обвалом трафика причиной оказалась одна строка в robots.txt.

Три правки, которые дают 80% результата

1. WebP вместо JPEG/PNG. Изображения — обычно 50–70% веса страницы. Конвертация в WebP даёт минус 25–35% веса без видимой потери качества; на большинстве CMS это делается плагином или на уровне CDN за пару часов. Проверьте заодно, что картинки отдаются в реальном размере показа, а не 3000 px шириной под контейнер 400 px.

2. Отложенная загрузка всего, что ниже первого экрана. Атрибут loading="lazy" для изображений и iframe, отложенная инициализация карт, видео и виджетов чатов. Первый экран должен грузиться первым — всё остальное подождёт. Важно: картинку из первого экрана (баннер, фото товара) лениво грузить нельзя — это ухудшит LCP.

3. Хостинг с NVMe-дисками и нормальным TTFB. Если сервер отдаёт первый байт дольше 600–800 мс, никакая оптимизация фронта не спасёт. Переезд со старого shared-хостинга на тариф с NVMe часто срезает 0,5–1 с с LCP вообще без правок кода. Это самая «дешёвая» из трёх правок по трудозатратам.

Приоритет работ: что делать в первую очередь

Порядок, который работает на практике: сначала измерить полевой LCP мобильной версии главных шаблонов (главная, категория, карточка товара). Если LCP больше 4 с — начинать с TTFB и хостинга, затем изображения, затем lazy load. Если LCP 2,5–4 с — обычно хватает WebP и ленивой загрузки. Если LCP уже до 2,5 с — остановиться и заняться INP/CLS, только если они в красной зоне.

На реальных проектах ускорение LCP с 4,1 до 2,3 секунды давало +11% к конверсии без единого изменения в дизайне — просто потому, что часть людей переставала уходить, не дождавшись загрузки. Скорость — это конверсионная правка, и оценивать её нужно деньгами: посчитайте, сколько стоит +10% к конверсии при вашем трафике, и сравните со стоимостью работ.

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

Разбор замера: что показывают цифры на реальной странице

Возьмём типичную карточку товара интернет-магазина и пройдём замер по шагам.

Что показал отчёт. Балл на мобильном — 41, LCP — 4,8 секунды, CLS — 0,19, INP — 260 мс. Балл выглядит катастрофой, но работать нужно не с ним.

Ищем, что именно грузится 4,8 секунды. В разделе с диагностикой видно, какой элемент считается главным: это фотография товара шириной 1600 пикселей, весом 780 КБ, отдаваемая в формате JPEG без сжатия. На экране она занимает 360 пикселей.

Считаем эффект. Пересжатие в современный формат и отдача под размер экрана уменьшают файл примерно в десять раз. LCP падает до 2,4–2,6 секунды. Одна правка, эффект — почти половина проблемы.

Смещение макета 0,19. Смотрим, что прыгает: блок с ценой сдвигается вниз, когда подгружается баннер акции. Лечится указанием размеров блока заранее — правка на десять минут, показатель уходит к 0,05.

Отклик 260 мс. Здесь виноват тяжёлый скрипт чата поддержки, который грузится сразу. Отложенная загрузка через три секунды или по первому касанию экрана снимает проблему.

Итог: три правки, ни одна не требует переделки сайта, а балл при этом поднимается примерно до 75. Оставшиеся 25 баллов стоили бы больше, чем все три вместе, и не изменили бы ничего для покупателя.

<!-- БЫЛО: одна тяжёлая картинка на все экраны -->
<img src="/img/tovar.jpg">

<!-- СТАЛО: под размер экрана, в современном формате,
     с размерами (иначе макет прыгает при загрузке) -->
<img src="/img/tovar-800.webp"
     srcset="/img/tovar-400.webp 400w,
             /img/tovar-800.webp 800w,
             /img/tovar-1600.webp 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="800" height="600"
     alt="Перфоратор в работе на бетонной стене"
     loading="lazy" decoding="async">

Что скорость даёт в деньгах: как посчитать для себя

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

1. Возьмите текущие цифры: визитов в месяц, конверсия в обращение, средний чек, доля мобильного трафика.

2. Найдите долю уходов по скорости. В системе аналитики сравните конверсию у визитов с быстрой и медленной загрузкой. Разрыв обычно заметный, и он и есть ваш резерв.

3. Посчитайте на примере. Пусть 40 000 визитов в месяц, 70% с телефонов, конверсия на мобильном 1,1% против 1,9% на быстрых визитах, средний чек 12 000 ₽.

Даже при осторожной оценке прироста конверсии (не до 1,9%, а до 1,5%) разница составляет более сотни обращений в месяц. Соотнесите это со стоимостью работ — обычно решение становится очевидным без споров о баллах.

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

Порядок работ: что делать в первую, вторую и третью очередь

Оптимизацию удобно вести тремя волнами — от дешёвого к дорогому.

Волна 1, эффект за неделю, силами контент-менеджера. Пересжатие изображений и отдача под размер экрана. Отложенная загрузка картинок ниже первого экрана. Удаление скриптов сервисов, которыми давно не пользуются — их обычно находится два-три.

Волна 2, месяц, нужен разработчик. Отложенная загрузка тяжёлых виджетов: чат, карта, видео. Указание размеров для баннеров и рекламных блоков. Настройка кеширования на сервере и сжатия ответов.

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

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

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

<!-- Чат, карта и видео грузятся не сразу, а при первом
     касании экрана или через 3 секунды — что наступит раньше -->
<script>
(function () {
  let done = false;
  function load() {
    if (done) return; done = true;
    const s = document.createElement('script');
    s.src = 'https://widget.example.com/chat.js';
    s.async = true;
    document.body.appendChild(s);
  }
  ['scroll','touchstart','mousemove'].forEach(
    e => addEventListener(e, load, { once: true, passive: true })
  );
  setTimeout(load, 3000);
})();
</script>

Типичные ошибки оптимизации скорости

• Оптимизация десктопа вместо мобильного. Баллы на десктопе почти всегда высокие — проблема не там.
• Lazy load на изображении первого экрана. LCP-элемент должен грузиться с максимальным приоритетом, иначе метрика ухудшится.
• Десять скриптов аналитики и виджетов. Каждый чат, квиз и пиксель бьёт по INP. Проведите ревизию: половина обычно давно не используется.
• Кэш-плагины без замера «до/после». Иногда агрессивное кэширование ломает формы и корзину — а падение конверсии списывают на сезон.
• Гонка за 95+ баллами по требованию руководства. Дорого и не влияет на продажи после достижения нормальных Vitals.

Скорость — один из факторов, но не единственный: без спроса и структуры она не даст трафика. Про фундамент — в материале о сборе семантического ядра, а пример комплексной работы, где скорость была одним из этапов, — в кейсе роста трафика в 4 раза. Остальные разборы — в рубрике SEO.