У нас уже есть статья про то, сколько стоит простой сайта — когда сервер падает и сайт вообще недоступен, это легко посчитать: трафик умножить на средний чек умножить на время недоступности. Но есть менее очевидная и куда более распространённая проблема: сайт работает, не падает, отдаёт код 200 — и при этом стабильно теряет деньги просто потому, что грузится на полторы-две секунды дольше, чем нужно. Это другая история, и считать её нужно иначе.
Почему медленный, но рабочий сайт — это незаметная проблема
Простой сайта видно сразу: алерты, звонки от клиентов, паника в команде. Медленная загрузка не вызывает паники — сайт просто работает чуть хуже, чем мог бы, месяц за месяцем, без единого инцидента, который бы заставил кого-то забить тревогу. Именно поэтому эта потеря почти никогда не попадает в отчёты — её не с чем сравнить, нет момента «до и после», как при аварии.
Что говорят данные о связи скорости и конверсии
Независимо от отрасли, индустриальные исследования крупных платформ (Google, Amazon, Akamai и другие публиковали подобные данные за последние годы) стабильно показывают одну и ту же закономерность: с каждой дополнительной секундой загрузки страницы вероятность отказа растёт, а конверсия падает. Точные цифры различаются между нишами и типами устройств, но направление эффекта универсально — и оно нелинейно: эффект ускоряется на мобильных сетях и слабых устройствах сильнее, чем на десктопе с быстрым интернетом, потому что там абсолютное время ожидания человека всегда больше при той же относительной задержке.
Практический вывод: ускорение сайта — это не абстрактное «хорошо для SEO», а измеримое улучшение бизнес-метрик, причём эффект накапливается на каждом этапе воронки, а не только на главной странице.
Какие именно метрики связаны с деньгами
LCP (Largest Contentful Paint) — момент, когда пользователь видит основной контент
Это первое впечатление от загрузки страницы. Если LCP превышает 2.5 секунды, пользователь начинает ощущать сайт как медленный ещё до того, как успел что-либо сделать — а первое впечатление сложно компенсировать дальнейшим UX.
TTFB (Time to First Byte) — скорость ответа сервера
Это фундамент, на котором строятся все остальные метрики: если сервер отвечает за 1.5 секунды до того, как браузер вообще получит первый байт HTML, ни одна клиентская оптимизация это не компенсирует. TTFB — единственная метрика из этого списка, которая полностью зависит от бэкенда и хостинга, а не от фронтенда.
INP (Interaction to Next Paint) — отзывчивость на действия
Менее очевидная для бизнеса метрика, но не менее важная: если страница визуально загрузилась, но не реагирует на клики и ввод (например, потому что основной поток браузера занят выполнением тяжёлого JavaScript), пользователь воспринимает это как «зависание» — и это особенно критично на этапе оформления заказа, где каждый клик должен сработать мгновенно.
Где теряются деньги конкретно
Длинная воронка чувствительнее короткой. Чем больше шагов между заходом на сайт и конверсией (просмотр каталога → карточка товара → корзина → оформление), тем больше точек, где задержка может оттолкнуть пользователя, и тем сильнее накопленный эффект медленной загрузки на каждом шаге.
Мобильный трафик теряет больше. Если основной трафик идёт с мобильных устройств и медленных сетей, эффект от лишней секунды загрузки ощутимо выше, чем для десктопной аудитории на хорошем подключении.
Платный трафик особенно болезненно реагирует. Если вы платите за клик по рекламе, а пользователь уходит из-за медленной загрузки страницы до того, как увидел предложение, — это прямая потеря рекламного бюджета, а не абстрактная «недополученная выручка».
Это не призыв гнаться за идеальными цифрами
Важная оговорка: связь между скоростью и конверсией не означает, что нужно бесконечно гнаться за идеальными значениями метрик любой ценой. Эффект от ускорения нелинейный и убывающий — разница между LCP в 6 секунд и 2.5 секунды критична для бизнеса, а вот разница между 1.8 и 1.2 секунды почти никогда не оправдывает дополнительные недели инженерной работы. Бизнес-смысл есть в том, чтобы выйти из зоны «явно медленно» в зону «нормально», а не полировать и без того приемлемый результат.
Техническую сторону того, как именно ускорить LCP, TTFB и остальные метрики, мы подробно разбирали в других материалах — здесь же важнее посчитать, оправдана ли эта работа экономически именно для вашего сайта.
Как прикинуть свою цену медленной загрузки
Грубая, но рабочая модель для оценки:
- Посмотрите текущий LCP по ключевым страницам воронки (каталог, карточка товара, страница оформления) — через анализ Core Web Vitals;
- Сравните отказы и конверсию у пользователей с быстрой загрузкой (через сегментацию в аналитике по реальному времени загрузки, если такая возможность есть) и у пользователей с медленной;
- Если разница в конверсии между сегментами заметна — у вас есть собственная, специфичная для вашего сайта оценка цены каждой секунды, гораздо точнее любых усреднённых отраслевых цифр;
- Сопоставьте эту цифру со стоимостью инженерной работы по ускорению — это и есть честный ответ на вопрос, стоит ли оно того прямо сейчас.
Если же речь идёт не о хронически медленном сайте, а о внезапном ухудшении — это уже не вопрос экономики, а технической диагностики, и здесь полезен постоянный мониторинг доступности: резкое изменение времени ответа сервера обычно видно в графиках раньше, чем падает конверсия.
Чек-лист
- Замерить текущий LCP, TTFB и INP по ключевым страницам воронки
- Сопоставить метрики скорости с конверсией по сегментам пользователей, если есть такая аналитика
- Оценить долю мобильного трафика — там эффект от медленной загрузки сильнее
- Определить, в какой «зоне» сейчас сайт: критично медленно, приемлемо, или уже хорошо
- Не оптимизировать ради красивых цифр там, где бизнес-эффект уже исчерпан
- Настроить постоянный мониторинг, чтобы заметить деградацию скорости раньше, чем она отразится на выручке
Заключение
Простой сайта считают в деньгах почти всегда, а медленную загрузку — почти никогда, хотя оба сценария бьют по выручке, просто один — резко и заметно, а второй — постепенно и незаметно. Регулярная проверка через анализ Web Vitals и постоянный мониторинг доступности позволяют увидеть проблему до того, как она превратится в привычную фоновую потерю, которую никто уже не замечает.