Кейс: как ускорили сайт и что это дало бизнесу

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

Исходная точка: что было не так

Клиент — интернет-магазин товаров для дома: около 40 000 SKU, 300–400 тысяч визитов в месяц, заметная доля трафика из платных каналов и поиска. Замеры до старта работ:

• LCP на мобильных — 6,2 с, INP — 480 мс, CLS — 0,31;
• TTFB на страницах каталога — 1,8 с;
• вес главной страницы — 8,4 МБ, около 140 запросов;
• оценка PageSpeed Insights для мобильных — 21 балл;
• отказы из поискового трафика — 54%, конверсия в заказ — 0,9%.

Отдельная сложность: на тестовом стенде и на быстром интернете в офисе сайт выглядел нормально. Проблема проявлялась на реальных устройствах — недорогих Android-смартфонах и мобильном интернете, то есть у большинства покупателей.

Аудит: где на самом деле терялось время

Инфраструктура и бэкенд

Сайт жил на одном сервере без выделенного кэша. Каждый запрос к каталогу поднимал тяжёлые SQL-запросы, часть из них — без индексов. Статика раздавалась тем же сервером, что и динамика, поэтому загрузка одной картинки замедляла отдачу страниц. TTFB в 1,8 секунды — прямое следствие этой схемы.

Фронтенд и медиа

На главной подключалось 14 файлов JavaScript и 9 файлов CSS, часть — синхронно в <head>. Изображения отдавались в исходном разрешении: трёхмегабайтные фото товара в превью каталога. Шрифты грузились без предзагрузки, из-за чего текст «дёргался» и портил CLS. Внешние скрипты аналитики, чата и ретаргетинга блокировали отрисовку.

Что делали: семь направлений работ

1. Инфраструктура. Вынесли базу на отдельный сервер, добавили Redis для кэша запросов и полноценный кэш страниц. Статику и медиа перевели на CDN.
2. База данных. Добавили индексы, убрали N+1 запросы в карточке товара и каталоге, переписали выборку по фильтрам.
3. Изображения. Внедрили конвертацию в WebP и AVIF, адаптивные размеры под разные экраны, ленивую загрузку для всего, что ниже первого экрана.
4. JS и CSS. Разделили бандлы, отложили некритичный код, убрали дубли библиотек. Вместо 23 файлов осталось 4.
5. Критический путь отрисовки. Стили первого экрана вынесли в инлайн, шрифты — локально с предзагрузкой, метрики и чат — с задержкой до первого взаимодействия.
6. Мониторинг. Настроили сбор Core Web Vitals с реальных устройств, а не только лабораторные замеры.
7. Процессы. Добавили проверку производительности в релизный чек-лист, чтобы регресс не вернулся через месяц.

Работы шли итерациями: сначала инфраструктура и база, затем фронтенд. Это позволило уже на второй неделе увидеть эффект на TTFB и не ждать финала, чтобы понять, что направление выбрано верно.

Результаты: метрики через два месяца

• LCP на мобильных — с 6,2 до 2,1 с;
• INP — с 480 до 130 мс;
• CLS — с 0,31 до 0,04;
• TTFB — с 1,8 до 0,4 с;
• вес главной — с 8,4 до 1,6 МБ, число запросов — со 140 до 52;
• PageSpeed Insights для мобильных — с 21 до 78 баллов.

Отдельно стоит сказать про INP: именно он сильнее всего влиял на ощущение «сайт тормозит». Пользователь видел контент, но не мог нажать кнопку — и уходил.

Что это дало бизнесу

Скорость — не самоцель, важен эффект. За три месяца после завершения работ на сопоставимом трафике:

• конверсия в заказ выросла с 0,9% до 1,25%;
• отказы из поиска снизились с 54% до 41%;
• цена заказа из платных каналов упала примерно на 18%;
• глубина просмотра выросла с 3,1 до 4,4 страниц.

Заметная часть прироста пришлась на мобильный трафик и на позиции в поиске: Core Web Vitals учитываются в ранжировании, и по части категорий сайт поднялся в выдаче без дополнительной работы с контентом.

Сроки и стоимость

Проект занял около двух месяцев силами бэкенд-разработчика, фронтенд-разработчика и DevOps-инженера, при частичной занятости аналитика. Основные затраты — время команды и переход на новые серверные мощности; CDN и кэш-сервер добавили к ежемесячным расходам порядка 10–15% от прежнего хостинга.

Окупаемость считали просто: прирост заказов за первые три месяца перекрыл стоимость работ. Но это цифры одного проекта — на другом сайте с иной структурой трафика эффект может быть скромнее.

Выводы, которые можно примерить на свой сайт

• Начинайте с инфраструктуры и базы. Микрооптимизация картинок не спасёт, если TTFB — почти две секунды.
• Смотрите на полевые метрики, а не только на лабораторные: реальные устройства показывают совсем другую картину.
• Измеряйте до и после на сопоставимом периоде, иначе прирост легко списать на сезонность.
• Встройте проверку производительности в релизный процесс — иначе всё вернётся за пару месяцев.
• Разделяйте эффект: часть прироста даёт конверсия, часть — поиск и реклама. Так проще объяснить результат руководству.

Коротко

Медленный сайт — не техническая мелочь, а прямые потери на трафике, который вы уже оплатили. В этом кейсе семь направлений работ дали рост конверсии с 0,9% до 1,25% и снижение стоимости заказа из рекламы почти на пятую часть. Начинать стоит не с косметики, а с аудита: он покажет, где именно теряются секунды — на сервере, в базе или в браузере пользователя.