Покупатель не знает, что такое время до первого байта или сдвиг макета, но прекрасно чувствует, когда каталог открывается три секунды, а кнопка «В корзину» прыгает под пальцем. Медленный магазин теряет заказы тихо: посетитель просто закрывает вкладку и уходит к конкуренту. Разберём, как скорость связана с деньгами, как её правильно измерять и что конкретно делать, чтобы магазин работал быстро.
Как скорость превращается в деньги
Связь между скоростью и конверсией подтверждается почти на каждом проекте, где мы её измеряли. Когда время загрузки карточки товара на мобильном уменьшается с 4–5 до 2 секунд, показатель отказов на ней обычно падает на 15–30%, а конверсия в добавление в корзину растёт на 10–20%. Цифры зависят от ниши, но направление одинаковое всегда.
Посчитаем на примере. Магазин получает 60 000 визитов в месяц, конверсия в заказ — 1,5%, средний чек — 3 500 ₽. Это 900 заказов и 3 150 000 ₽ выручки. Если ускорение даст хотя бы 10% прироста конверсии, магазин получит 90 дополнительных заказов и 315 000 ₽ в месяц. На этом фоне работы по оптимизации стоимостью в несколько десятков тысяч рублей окупаются в первые недели.
Скорость влияет и на поисковое продвижение. Поисковые системы учитывают показатели загрузки и удобства страниц, а главное — поведение пользователей: быстрые возвраты в выдачу после медленной загрузки снижают позиции. Кроме того, медленный сайт хуже индексируется: поисковый робот тратит ограниченное время на сканирование, и на тяжёлом сайте он успевает обойти меньше страниц.
Какие метрики измерять
«Сайт грузится 3 секунды» — неточная формулировка. Загрузка состоит из нескольких этапов, и для пользователя важны разные моменты: когда появился контент, когда можно нажать на кнопку, не прыгает ли страница. Современный стандарт — набор метрик, отражающих реальный пользовательский опыт.
LCP — отрисовка главного контента
Время, за которое появляется самый крупный элемент на экране: главное фото товара или баннер. Хороший показатель — до 2,5 секунды.
INP — отклик на действия
Насколько быстро страница реагирует на нажатия: открыть фильтр, выбрать размер, добавить в корзину. Хорошо — до 200 мс.
CLS — стабильность макета
Насколько сдвигается контент при загрузке. Прыгающие кнопки и баннеры раздражают и приводят к случайным кликам. Хорошо — до 0,1.
TTFB — ответ сервера
Время до первого байта ответа. Не входит в основные метрики, но если сервер думает больше 600–800 мс, остальное уже не спасти.
Различайте лабораторные и полевые данные. Лабораторные инструменты запускают страницу в контролируемых условиях и показывают оценку с рекомендациями — это удобно для диагностики. Полевые данные собираются с реальных посетителей и показывают, как сайт работает на их устройствах и сетях. Ориентироваться нужно на полевые, а лабораторные использовать для поиска причин.
Измеряйте не только главную. Покупатели чаще всего попадают на сайт через карточки товаров и категории, а именно эти страницы обычно самые тяжёлые. Обязательно проверяйте корзину и оформление заказа — тормоза на последнем шаге стоят дороже всего.
Что чаще всего тормозит магазин
На аудитах медленных магазинов мы видим одни и те же причины. Хорошая новость в том, что большинство из них устраняются без переписывания сайта.
Тяжёлые изображения
Самая частая проблема. Фотографии загружаются в исходном размере 3–5 МБ и уменьшаются браузером до превью 300 пикселей. Категория из 48 товаров весит 40–60 МБ. Решение — автоматическая генерация нужных размеров, современные форматы WebP и AVIF, адаптивные изображения под размер экрана и отложенная загрузка картинок ниже первого экрана. Подробнее о подготовке снимков — в статье про фотографии товаров.
Сторонние скрипты
Онлайн-чат, виджет обратного звонка, несколько счётчиков аналитики, пиксели соцсетей, виджет отзывов, всплывающее окно с подпиской. Каждый скрипт по отдельности небольшой, но вместе они могут занимать больше половины времени загрузки и блокировать отклик на нажатия. Проведите ревизию: часть скриптов давно не используется, часть можно загружать после взаимодействия пользователя.
Медленный сервер и отсутствие кеша
Каждый раз, когда страница собирается заново из базы данных, сервер тратит сотни миллисекунд. Без кеширования каталог на несколько тысяч товаров с фильтрами превращает дешёвый виртуальный хостинг в узкое место. Нужен нормальный сервер, кеширование страниц и запросов, оптимизированные запросы к базе.
Перегруженная тема и плагины
Особенно характерно для WordPress и OpenCart: универсальная тема с десятками функций, которые не используются, и 40 плагинов, каждый со своими стилями и скриптами на каждой странице. Иногда проще и дешевле сделать лёгкую собственную тему, чем бесконечно оптимизировать купленную.
План ускорения по приоритетам
Ускорение лучше делать по принципу «максимальный эффект на минимальных затратах». Начинайте с того, что даёт больше всего, и после каждого шага измеряйте результат.
| Мера | Эффект | Сложность |
|---|---|---|
| Оптимизация изображений, WebP/AVIF, ленивая загрузка | Высокий | Низкая–средняя |
| Ревизия и отложенная загрузка сторонних скриптов | Высокий | Низкая |
| Кеширование страниц и включение сжатия | Высокий | Средняя |
| CDN для статики | Средний | Низкая |
| Резервирование места под изображения и баннеры (против CLS) | Средний | Низкая |
| Оптимизация запросов к базе, индексы | Средний–высокий | Средняя–высокая |
| Переход на более мощный сервер | Зависит от нагрузки | Низкая |
| Переработка фронтенда, лёгкая тема | Высокий | Высокая |
Не гонитесь за сотней баллов в лабораторных тестах. Оценка 100 из 100 на пустой странице ничего не стоит, если реальные покупатели на мобильном интернете ждут карточку четыре секунды. Цель — хорошие полевые показатели на ключевых шаблонах: категория, карточка, корзина, оформление.
Скорость на мобильных устройствах
Больше 70% посетителей розничных магазинов приходят со смартфонов, и часто — не с флагманов и не по Wi-Fi. Процессор бюджетного смартфона обрабатывает JavaScript в несколько раз медленнее ноутбука, поэтому тяжёлый фронтенд, который летает на компьютере разработчика, на телефоне покупателя подтормаживает при каждом нажатии.
Тестируйте на реальных недорогих устройствах или хотя бы с эмуляцией медленного процессора и сети. Уменьшайте объём JavaScript: не нужно загружать код слайдера, фильтров и чата на странице корзины. Сокращайте количество элементов на странице: каталог из 100 карточек с ховер-эффектами и мини-галереями тяжёл для мобильного браузера, лучше 24–36 товаров с кнопкой «Показать ещё».
Особое внимание — к первому экрану. Главное изображение товара должно загружаться с высоким приоритетом, шрифты — не блокировать показ текста, а баннеры и всплывающие окна — не перекрывать контент сразу после загрузки.
Не забывайте про фильтры каталога. Если каждое изменение фильтра перезагружает всю страницу, на мобильном это превращается в мучение: человек выбирает размер, ждёт, выбирает цвет, снова ждёт. Обновление списка товаров без полной перезагрузки и кнопка «Показать N товаров» после выбора нескольких параметров делают подбор заметно быстрее.
Пример: ускорение магазина товаров для дома
Магазин товаров для дома на WooCommerce с каталогом около 4 000 позиций обратился к нам с жалобой на падение конверсии с мобильных. Полевые данные показывали LCP карточки товара около 5,2 секунды и заметные сдвиги макета при загрузке. Аудит нашёл знакомый набор: фотографии без превью весом до 3 МБ, 11 сторонних скриптов, включая два неиспользуемых счётчика и старый виджет отзывов, отсутствие кеширования страниц и тему с конструктором, загружавшую стили всех блоков на каждой странице.
За три недели мы настроили генерацию превью в WebP, ленивую загрузку изображений ниже первого экрана, убрали лишние скрипты и перевели чат на загрузку по первому взаимодействию. Включили кеширование страниц для неавторизованных посетителей и объектный кеш для запросов к базе, зарезервировали место под баннеры. Тему не меняли — только отключили неиспользуемые модули конструктора.
Итог по полевым данным через месяц: LCP карточки снизился до 2,1 секунды, сдвиги макета практически исчезли, время ответа сервера уменьшилось втрое. Конверсия мобильного трафика в заказ выросла на 17%, а доля отказов на карточках — снизилась на четверть. Важно, что эффект был достигнут без смены платформы и редизайна.
Как удержать скорость после ускорения
Самая обидная ситуация — когда магазин ускорили, а через полгода он снова медленный. Контент-менеджер загрузил баннеры по 4 МБ, маркетолог добавил три новых пикселя, разработчик подключил ещё один модуль. Скорость нужно защищать процессами, а не разовым проектом.
- Автоматическая оптимизация всех загружаемых изображений на стороне сайта, без надежды на ручную подготовку.
- Правило: любой новый сторонний скрипт согласуется с разработчиком и проверяется на влияние на скорость.
- Мониторинг полевых метрик с ежемесячным отчётом по ключевым шаблонам.
- Проверка скорости перед каждым крупным релизом на тестовом сервере.
- Плановая ревизия плагинов и модулей раз в квартал.
Регулярный контроль скорости и мелкие исправления удобно включить в договор технической поддержки: проблема находится и исправляется до того, как успеет повлиять на продажи.
Выводы
Скорость магазина напрямую конвертируется в деньги: в число заказов, позиции в поиске и стоимость рекламного трафика. Измеряйте её правильно — по полевым метрикам LCP, INP и CLS на категориях, карточках и оформлении заказа, а не только по оценке главной страницы. Начинайте с самых выгодных мер: изображения, сторонние скрипты, кеширование. Отдельно проверяйте работу на недорогих смартфонах. И закрепите результат процессами, иначе через несколько месяцев всё вернётся к исходной точке.
Нужен сайт или интернет-магазин?
Обсудим задачу, подскажем подходящую платформу и оценим сроки и бюджет — бесплатно и без обязательств.
Обсудить проект
