Что мы называем скоростью сайта

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

TTFB — время до первого байта ответа сервера. Высокий TTFB тянет за собой всё остальное: даже идеальный фронтенд не спасёт медленный API или холодный PHP без кеша. FCP показывает, когда появился первый осмысленный пиксель контента. LCP — когда основной элемент вьюпорта стал видимым; для карточки товара это часто главное изображение. INP отражает задержку реакции на клики и ввод на протяжении визита. CLS ловит «прыжки» вёрстки, из‑за которых человек промахивается по кнопке «Купить».

Отдельно стоит размер и стоимость JavaScript: время разбора, гидрации и блокировки главного потока. Именно тяжёлый клиентский код чаще убивает INP на мобильных, даже когда LCP выглядит приемлемо в отчёте.

Лаборатория и поле

Lighthouse и «идеальный» прогон WebPageTest отвечают на вопрос: «ломаем ли мы критический путь в контролируемых условиях?» Chrome UX Report и собственный RUM отвечают на другой: «что реально получают пользователи?» Разница между Wi‑Fi на ноутбуке и 3G на бюджетном Android может превратить «зелёный» лабораторный LCP в «красный» полевой. Если вы оптимизируете только под ноутбук разработчика, вы оптимизируете демо, а не продажи.

Почему среднее врёт

Представьте: у 90% сессий LCP меньше 2,5 с, у 10% — больше 6 с. Среднее может выглядеть «почти хорошо». Но именно медленный дециль часто — мобильные визиты из рекламы, регионы с слабой сетью, страницы с тяжёлыми рекомендациями. Эти 10% могут нести непропорциональную долю стоимости клика. Смотрите перцентили (75-й и 90-й) и сегменты, а не только среднее по сайту.

Что происходит с пользователем, когда сайт медленный

Человек нажимает «Купить» или переходит из поиска на карточку. Вместо товара он видит пустой экран, спиннер или сдвинувшуюся кнопку. Ожидание само по себе неприятно; на мобильном оно ещё и конкурирует с уведомлениями и соседней вкладкой конкурента.

Растёт вероятность ухода: возврат в выдачу, закрытие вкладки, повторный поиск с другим брендом. Снижается доверие: технически «кривой» магазин воспринимается как менее надёжный и менее современный — даже если ассортимент и цена в порядке. На мобильном особенно болезненны тяжёлый JavaScript, огромные изображения, медленный сервер и нестабильная сеть: именно там пользователь чаще всего принимает решение «подождать ещё» или «уйти».

Это не мистика UX. Это физика внимания: каждый лишний шаг ожидания отбирает шанс дойти до следующего этапа воронки. Связка скорости с деньгами начинается здесь, а не в отчёте Lighthouse.

Что говорят исследования крупных компаний

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

Google (Need for Mobile Speed, 2016). По агрегированным данным Google Analytics на выборке мобильных сайтов около 53% визитов с высокой вероятностью обрываются, если загрузка дольше трёх секунд; средняя загрузка многих мобильных страниц на 3G тогда измерялась десятками секунд. Это корреляция по большим выборкам издателей и рекламных площадок, не ваш A/B-тест. Смысл для бизнеса: мобильное ожидание — массовая причина отказа, а не «нишевая жалоба перфекционистов».

Amazon (по рассказу Greg Linden). В контролируемых экспериментах до начала 2000‑х страницы искусственно замедляли шагами по 100 мс и наблюдали заметное падение выручки; в презентациях часто фигурирует порядок ~1% продаж на каждые +100 мс. Amazon не публиковал формальный рецензируемый отчёт; цитата идёт из выступлений и блога инженера. Переносить «1% на 100 мс» на любой лендинг 2026 года как закон нельзя — но идея «малая задержка измерима в деньгах на огромном трафике» подтверждена культурой экспериментов компании.

Walmart (RUM, презентации ~2012–2013). По собственным данным, конверсия падала по мере роста среднего времени загрузки; у конвертирующих визитов среднее время было ниже (порядка 3,2 с против ~6 с у неконвертирующих). В ключевых слайдах: до +2% конверсии на каждую секунду улучшения и до +1% инкрементальной выручки на 100 мс. Это наблюдение на их трафике и их определении времени загрузки, не универсальная эластичность.

Bing / Microsoft (эксперименты с замедлением). В работах по онлайн-экспериментам искусственное замедление сервера на 100 мс давало порядок ~0,6% улучшения выручки при ускорении (линейная аппроксимация на их метриках). Важно: меняли задержку ответа, а не «красоту» интерфейса — это ближе к причинности, чем простой срез «быстрые vs медленные пользователи».

Pinterest. Пересборка страниц под производительность дала порядка −40% к метрике ожидания (Pinner Wait Time), +15% SEO-трафика и +15% к конверсии в регистрацию; эффект на привлечение был мультипликативным. Позже PWA для мобильного веба сократила время до интерактивности с десятков секунд до единиц и улучшила вовлечённость — снова связка «ускорили критический путь → выросли продуктовые метрики», а не только «подняли балл».

Zalando и другие ритейлеры. В отраслевых сводках встречается оценка порядка +0,7% выручки при −100 мс; первоисточник часто слабее Amazon/Walmart и требует осторожной цитаты. Для AliExpress, Booking и Netflix в блогах гуляют похожие истории — перед презентацией бизнесу лучше открыть первоисточник команды, а не пересказ агентства.

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

Перевод скорости в деньги

Возьмём упрощённый интернет-магазин: 1 000 000 посетителей в месяц, конверсия 2%, средний чек 5 000 ₽.

Заказов: 1 000 000 × 0,02 = 20 000.
Выручка: 20 000 × 5 000 = 100 000 000 ₽.

Допустим, ухудшение скорости снижает конверсию на 5% относительно текущей (не на пять процентных пунктов): новая конверсия 2% × 0,95 = 1,9%. Заказов становится 19 000. Потеря — 1 000 заказов или 5 000 000 ₽ потенциальной выручки в месяц.

Это не утверждение «сайт стал на секунду медленнее ⇒ −5%». Это перевод вашей гипотезы о Δ конверсии в деньги. Именно так стоит разговаривать с бизнесом: «если скорость съест 5% конверсии при нашем трафике и чеке, месяц стоит вот столько».

Формула потерь и почему важна прибыль

Базовая выручка:

Revenue = Traffic × Conversion Rate × Average Order Value

Потеря выручки при изменении конверсии:

Lost Revenue = Traffic × ΔConversion × Average Order Value

где ΔConversion — абсолютное изменение доли заказов (например, с 0,020 до 0,019 → 0,001).

Прибыль:

Lost Profit = Lost Revenue × Gross Margin

Так разговор смещается с «сайт потерял заказы» к «медленный сайт потенциально уменьшает прибыль на X ₽ в месяц». При марже 30% потеря 5 млн выручки — это около 1,5 млн прибыли. Именно эту сумму сравнивают со стоимостью спринта на кеш, CDN и урезание бандла.

Дополнительный рычаг — цена секунды привлечённого трафика. При 500 000 посетителей и среднем чеке 4 000 ₽ каждый 0,1 п.п. конверсии (0,001 в долях) стоит 500 000 × 0,001 × 4 000 = 2 000 000 ₽ выручки. Менеджеру проще думать: «улучшение LCP на медленном сегменте может вернуть долю этих двух миллионов», чем «LCP был 3,2 с».

SEO, реклама и повторные визиты

Скорость влияет не только на мгновенную конверсию. Метрики Core Web Vitals участвуют в сигналах ранжирования Google; Яндекс тоже учитывает удобство страниц, хотя точная формула закрыта. Пользовательские сигналы (отказы, короткие сессии) могут усиливать эффект. Отдельно миф: «ускорили главную — выросли все позиции». Доказанный минимум: CWV и стабильный HTML помогают не терять качество входа; остальное — контент, ссылки, интент. Подробнее про слои видимости — в гайде SEO / AEO / GEO.

Реклама жёстче. Клик из Google Ads, Яндекс Директа или Meta уже оплачен. Медленная посадочная значит: деньги потрачены, а продажа не состоялась. Стоимость привлечения клиента растёт не потому, что «реклама плохая», а потому что воронка теряет людей после клика. Оптимизация LCP на лендинге кампании часто окупается быстрее, чем ещё один креатив.

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

Воронка интернет-магазина: скорость на каждом шаге

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

Пример схемы воронки (цифры демонстрационные):

Если медленный JS на карточке режет добавление в корзину, а тяжёлое оформление заказа режет оплату, вы чините не «сайт», а конкретные разрывы. Сравните две картины:

Быстрый путь (LCP по шагам): 2,0 → 1,8 → 1,7 → 1,9 с.
Медленный путь: 5,5 → 6,2 → 7,1 → 8,0 с.

Во втором случае человек «платит» ожиданием на каждом клике. Отсюда правило: оптимизируйте скорость воронки, а не только главную для красивого скриншота Lighthouse.

Что обычно замедляет современные сайты

Серверная часть. Медленные SQL, N+1, тяжёлый PHP или Node без кеша, «холодный» API, неправильный CDN или его отсутствие. TTFB выше секунды на ключевых страницах — красный флаг до споров о React.

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

Изображения. JPEG там, где нужен WebP/AVIF; 3000 px ширины вместо 600; нет ленивой загрузки и srcset. LCP часто = картинка товара: пока она не оптимизирована, фронтенд-микрооптимизации дают мало.

Сторонние скрипты. Аналитика, чаты, пиксели рекламы, карты, виджеты, A/B-платформы, рекомендации. Каждый «маленький» тег добавляет конкуренцию за главный поток. Без инвентаризации сторонних скриптов вы лечите симптомы в своём коде, пока чужой скрипт держит INP.

Как измерить влияние скорости на своём сайте

Шаг 1. Соберите базу: трафик, конверсия, средний чек, выручка, отказы, полевые Core Web Vitals (не только Lighthouse).

Шаг 2. Разделите сессии по скорости, например по LCP: < 2,5 с / 2,5–4 с / > 4 с. Сравните конверсию и выручку на посетителя по группам.

Шаг 3. Смотрите поле: RUM, Google Analytics / Яндекс Метрика, Chrome UX Report, серверные логи TTFB. Лаборатория — для отладки регресса в CI.

Шаг 4. Ищите корреляцию осторожно. Таблица вида «медленный LCP → ниже конверсия» полезный сигнал, но корреляция ≠ причинность: медленные сессии могут быть ботами, слабыми устройствами или тяжёлыми страницами каталога с иной семантикой спроса.

Такую таблицу на своих данных стоит показать бизнесу как гипотезу, а не как доказанный закон. Доказательство — эксперимент.

A/B-тест скорости и ловушка одной метрики

Сильный дизайн: вариант A — текущий сайт, вариант B — ускоренный (или искусственно замедленный для оценки эластичности). Одинаковые трафик, аудитория, период, цены и рекламные кампании; меняется техническая реализация. Меряйте конверсию, долю добавлений в корзину, долю дошедших до оплаты, выручку на посетителя, средний чек, отказы — не только LCP.

Искусственное замедление (как у Amazon/Bing) часто чище для оценки «сколько стоит 100 мс», чем большой рефакторинг, в котором заодно поменяли UX. Ускоряющий релиз зато ближе к реальной работе команды.

Ловушка одной метрики: LCP улучшили с 4,2 до 2,1 с, а конверсия и выручка не сдвинулись. Технический успех есть, бизнес-эффект не доказан — возможно, узкое место было в доставке, цене или форме оплаты. Обратный случай: LCP почти не изменился, но сценарий «добавить в корзину» стал ощутимо быстрее за счёт INP — и заказы выросли. Смотрите связку метрик пути, а не один зелёный кружок в отчёте.

Демонстрационный (не полевой) пример для разговора с заказчиком:

При 200 000 визитах и чеке 3 500 ₽ прирост конверсии на 0,25 п.п. — это 200 000 × 0,0025 × 3 500 = 1 750 000 ₽ выручки. Пометьте в презентации: какие строки из RUM, какие — иллюстрация.

Экономика оптимизации и бюджет производительности

Пусть оптимизация стоит 300 000 ₽, а после неё стабильно появляется +300 000 ₽ дополнительной прибыли в месяц. Срок окупаемости:

Payback = Investment / Monthly Incremental Profit = 1 месяц

Окупаемость за первый месяц:

ROI = (Incremental Profit − Investment) / Investment

На горизонте года эффект обычно больше разовой стоимости, если вы не откатываете регресс. Бюджет производительности — способ не съесть этот эффект обратно:

Бюджет — договорённость продукта и разработки: новый виджет чата не въезжает «тихо», если ломает INP. Это защита конверсии от накопленного технического шума.

Цель «PageSpeed 100» плохая сама по себе: сто баллов не гарантируют продажи, хороший UX и совпадение с полем. Правильная цель — минимизировать время до нужного действия пользователя на всём пути покупки.

Приоритет работ обычно такой: сервер и TTFB → критический путь отрисовки (HTML/CSS/шрифты) → изображения LCP → JavaScript → сторонние скрипты → CDN и кеш на краю. Связка UX и денег в переговорах с заказчиком также разобрана в обзоре окупаемости UX.

Чек-лист для владельца сайта

• Измеряется полевой LCP (не только Lighthouse)
• Измеряются INP и CLS
• Измеряется TTFB на ключевых URL
• Есть RUM или хотя бы CrUX + Метрика или аналогичная аналитика
• Известны конверсия, средний чек и маржа
• Конверсия смотрится в сегментах по скорости
• Для спорных релизов планируется A/B или тест с замедлением
• Задан бюджет производительности и владелец регрессов
• Платный трафик проверяется на скорость посадочных
• Скорость воронки (карточка → корзина → оплата) важнее «баллов главной»

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

Дальше по теме

• JavaScript: 8 оптимизаций производительности — что мерить и что резать в клиентском коде.
• 10 фактов про окупаемость UX — цифры для разговора с заказчиком о трении.
• SEO, AEO, GEO в 2026 — где CWV стоят среди слоёв видимости.
• Почему я ушёл с Next.js на Astro — практический кейс веса JS на маркетинговом сайте.
• Эволюция веб-архитектуры — контекст, откуда берётся тяжёлый клиент.

Заключение

Медленный сайт — это не «плохой Lighthouse». Это меньше просмотренных товаров, меньше корзин, меньше заказов, выше стоимость привлечённого клика и меньше прибыли. Оптимизацию скорости имеет смысл оценивать в рублях: через свою воронку, свои перцентили и свою гипотезу Δ конверсии — с калькулятором выше и честным тестом, а не с чужим мемом про «+1 секунда».

Цепочка, которую стоит повесить над доской команды:

Performance → UX → поведение → конверсия → заказы → выручка → прибыль