Привет, Хабр!
Меня зовут Дмитрий, руководитель отдела рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.
Владельцы интернет-магазинов обычно замечают проблему по одному симптому: раньше сайт летал, а теперь тормозит. Каталог вырос с 500 до 15 000 позиций, добавили фильтры, настроили выгрузку с маркетплейсов и все как будто стало хуже. Страницы открываются дольше, поиск зависает, в выдаче появились жалобы на скорость.
Дальше начинается стандартный путь: ищут узкое место, находят что-то одно — хостинг, изображения, тяжелый скрипт. Затем исправляют его и удивляются, что сайт особо не ускорился. Потому что тормозит не что-то одно. Тормозит сразу несколько узлов, и они друг с другом связаны.
В этой статье разберем, что на самом деле нагружает магазин по мере роста каталога, где граница ответственности платформы и внешних инструментов, а где можно навредить себе самому. Покажем конкретный кейс, где переработка навигации и технической части дала +50% органического трафика за три месяца.
Что нагружает сайт по мере роста каталога
Проблема не в том, что товаров стало много. Проблема в том, что каждый новый товар — это не просто строка в базе данных. Это набор свойств для фильтров, изображения для CDN, торговые предложения с вариантами, остатки и цены для синхронизации. Нагрузка растет нелинейно.
1. Фильтры и поиск
Типичная ошибка — добавить в каталог 40-50 характеристик и подключить фильтр «из коробки». При каждом запросе база данных делает полный перебор: ищет все товары, у которых «свойство А = значение 1» и «свойство Б = значение 2». При 500 товарах это незаметно. При 10 000 — запрос начинает занимать секунды.
Правильное решение — фасетные индексы: заранее, в фоне, просчитать все комбинации значений фильтров и сохранить результаты. Тогда запрос пользователя превращается не в сканирование таблицы, а в чтение готового индекса.
Поиск по каталогу — отдельная история. Пользователи пишут с ошибками, на другой раскладке клавиатуры, используют синонимы и жаргон. «Ванна 170» и «акриловая ванна 170 см» — это один запрос в голове покупателя и два разных с точки зрения поиска.
2. Изображения и медиа
Средний интернет-магазин с большим каталогом хранит несколько сотен гигабайт изображений. При каждом открытии карточки товара браузер запрашивает 5-10 фото в оригинальном размере, если кто-то не позаботился о правильной обрезке и формате.
Современный стандарт — WebP вместо JPEG/PNG (в среднем на 25-35% легче при сопоставимом качестве), плюс отдача изображений нужного размера под устройство пользователя, плюс ленивая подгрузка LazyLoad: незачем грузить фото товаров, которые находятся в самом низу страницы, пока пользователь смотрит верхний экран.
1С-Битрикс из коробки не сжимает изображения и не обеспечивает их кеширование на устройстве пользователя. Это закрывается внешними инструментами, например, специализированными сервисами оптимизации изображений. Обходить это только средствами платформы не получится.
3. Синхронизация с 1С и маркетплейсами
Для магазина с живыми остатками синхронизация — это хроническая боль. Штатный обмен с 1С через CommerceML может при каждом запуске блокировать сайт на минуты: он формирует огромный XML-файл, разбирает его, обновляет тысячи записей в базе данных. Пока идет обмен, сайт тормозит или недоступен.
Типичное решение — разделить обмен на части по приоритетам. Остатки и цены критичны, их надо обновлять часто, но они затрагивают небольшую часть данных. Карточки товаров меняются редко, их можно синхронизировать раз в несколько часов. Для одного из наших клиентов, магазина светильников LEDCITY, мы настроили обмен так: полная синхронизация товаров раз в 4 часа, обновление статусов заказов каждые 2 минуты. Сайт не блокируется, данные актуальны.
Аналогичная история с маркетплейсами: если выгрузка на Wildberries или Ozon запускается вручную и в рабочие часы, это нагружает базу данных именно тогда, когда на сайте максимум покупателей.
4. База данных и индексы
С ростом каталога таблица товаров раздувается, а индексы перестают помещаться в оперативную память и начинают читаться с диска. Это один из самых коварных процессов — ухудшение постепенное, и его легко списать на что-то другое.
Признаки: запросы, которые раньше выполнялись за 50 мс, теперь занимают 500 мс. EXPLAIN показывает Using filesort или Using temporary там, где их быть не должно. Иногда помогает пересборка индексов, иногда — поднятие innodb_buffer_pool_size, иногда — переосмысление структуры запросов.
Был у меня один случай: магазин с каталогом 10 000 позиций, после переработки обмена с 1С, рефакторинга фильтров и перехода с PHP 7.1 на 7.4 с подключением Memcached получил двукратный прирост скорости без смены хостинга.
5. Нагрузка на административную панель
Часто забывают про нее. При больших каталогах административная часть сайта становится медленной сама по себе: список товаров с отображением всех свойств, массовые операции, отчеты. Менеджеры начинают жаловаться, что «редактировать неудобно», и это прямо влияет на качество данных — проще не заполнять поле, чем ждать, пока страница перезагрузится.
Что решает платформа, что — внешние инструменты, а что зависит от вас
Что закрывается из коробки
Современные платформы для интернет-магазинов берут на себя базовый набор: кеширование страниц, компонентов и результатов запросов; минификацию CSS и JavaScript; управление сессиями; постраничную навигацию с правильными индексами.
В частности, в решениях Аспро для платформы 1С-Битрикс есть:
Фасетные индексы для умного фильтра — вычисляются в фоне, не в момент запроса пользователя.
Автокомпозит и минификация CSS/JS — из коробки.
Настройка TTL кеша по частоте обновления данных: для страниц, которые меняются раз в сутки, кеш можно держать долго; для страниц с живыми остатками — короче.
LazyLoad для изображений и тяжелых блоков — подгрузка по мере прокрутки.
Монитор производительности и встроенный замер скорости по компонентам — можно видеть, что именно тормозит, не открывая DevTools.
Раздел «Отладка → Суммарная статистика» в 1С-Битрикс показывает время выполнения каждого компонента. Если один компонент занимает 80% времени ответа, то это уже конкретная точка приложения усилий.
Что решают внешние инструменты
CDN — разгружает сервер, отдает статику (изображения, CSS, JS) из точек присутствия, близких к пользователю. Для российских магазинов актуальны отечественные CDN: Selectel, VK Cloud, Yandex Cloud. Рекомендуемый ориентир TTFB (время до первого байта) — менее 200 мс; при использовании CDN достичь этого значительно проще.
Сжатие и конвертация изображений — Imagick, сторонние сервисы, или инфраструктурные решения на уровне сервера (nginx с модулем image filter).
Мониторинг — New Relic, Zabbix, Prometheus или хотя бы простейшее внешнее пингование. Без мониторинга деградация скорости обнаруживается, когда пользователи уже ушли.
Поисковые движки — Elasticsearch или OpenSearch для полнотекстового поиска при больших каталогах. Встроенный поиск платформы начинает сдавать при десятках тысяч товаров с богатыми описаниями. Elasticsearch позволяет добавить синонимы («смартфон» = «телефон») и ранжировать по популярности, что критично для 15 000 товаров.
Где легко навредить самому
Три сценария ниже встречаются постоянно.
Отключенный кеш для мгновенного обновления. Логика понятна: товар обновился в 1С, хочется, чтобы на сайте сразу отобразились актуальные данные. Кеш отключают. В итоге каждый запрос идет прямо в базу данных, время ответа растет в разы. Решение — не отключать кеш, а правильно настраивать его сброс при обновлении данных или уменьшать TTL для критичных страниц.
Раздутый функционал. Подключили модуль отзывов, модуль сравнения, модуль вишлиста, три модуля аналитики, виджет чата, попап с акцией, еще один попап. Каждый грузит свои скрипты, делает свои запросы. Суммарно +2-3 секунды к времени загрузки. Все это по отдельности кажется нужным, а вместе — убивает скорость.
Немодерируемый пользовательский контент. Отзывы, вопросы к товарам, UGC-фото. Без модерации туда попадает спам с внешними ссылками, изображения в оригинальном размере 8 МБ, дублирующий контент. Поисковики это не любят, сервер под это не рассчитан.
С ростом каталога растет цена плохой навигации
Парадокс, который часто упускают: технические улучшения скорости — необходимое условие, но не достаточное. Если товар не находится, прирост ассортимента не превращается в прирост продаж.
Представьте магазин сантехники: 8 000 SKU, быстрые страницы, хорошие изображения. Но фильтр устроен так, что для поиска ванны нужно последовательно выбрать: материал → форма → размер → цвет → производитель → наличие. Пользователь, который знает, что ему нужна «ванна 170 см», делает 5 кликов и видит 340 позиций без возможности быстро сузить. Часть посетителей здесь покидает сайт.
Теги быстрого поиска решают это иначе: прямо под фильтром — «ванны 150 см», «ванны 170 см», «акриловые ванны», «ванны с гидромассажем». Один клик — готовая выборка. Это не замена фильтру, а ярлык для самых частых запросов.
Управление торговыми предложениями — еще один инструмент навигации, который часто недооценивают. Если платье доступно в 6 цветах и 5 размерах — это 30 SKU. Показать их как 30 отдельных карточек в каталоге — засорить выдачу и запутать пользователя. Объединить в одну карточку с переключателем вариантов — это стандарт UX.
Умный поиск с обработкой опечаток, транслитерации и синонимов — необходимость при больших каталогах. Пользователь, который напечатал «утюу» или «utyug», не должен видеть «ничего не найдено».
Кейс «Новая Ванна»
Разберем конкретный пример — магазин сантехники «Новая Ванна». Это наглядная иллюстрация того, как одновременная работа над навигацией, скоростью и SEO-структурой дает результат.
Исходная ситуация: большой каталог, органический трафик из Яндекса — около 250 визитов в день. Сайт работал, но навигация была перегружена, фильтры медленные, шапка занимала слишком много места на экране.
Что мы сделали
Шапка и навигация. Переработали хедер: стал компактнее, контакты убрали в выпадающий список, иконки входа, корзины, избранного и сравнения выстроили в одну строку. Освободилось место для товара в верхней части экрана — первый прокрут стал информативнее.
Структура категорий. Под баннером разместили категории в виде визуальных карточек с изображениями. Пользователь видит не текстовый список, а визуальную навигацию — это снижает когнитивную нагрузку и ускоряет выбор раздела.
Фильтр и теги. Подключили умный фильтр с тегами быстрого поиска: «ванны 170 см», «акриловые ванны», «ванны с гидромассажем» — часто запрашиваемые комбинации вынесены на поверхность. Фасетные индексы проиндексируют все комбинации, поэтому отклик фильтра — мгновенный.
SEO-структура. Под списком товаров добавили SEO-описания с внутренними ссылками на посадочные страницы по производителям и регионам. Это создало дополнительный граф внутренних ссылок и повысило релевантность категорийных страниц под региональные запросы.
Карточка товара. Крупные изображения, кнопка «Купить в один клик», расчет стоимости доставки прямо на странице товара — без перехода в корзину. Для категории мебели для ванных возможность купить элементы комплекта по отдельности или сразу весь набор.
Результат
Через три месяца: органический трафик из Яндекса вырос с ~250 до ~380 визитов в день. Суммарный трафик (Яндекс + Google) достиг 30 000 посетителей в месяц. Но самое главное: выросли время на сайте, конверсии и выручка.
Примечательно, что этот результат достигнут без масштабного наращивания ссылочного бюджета — в основном за счет технической и навигационной проработки.
Практический чеклист: с чего начать аудит большого каталога
Проверьте время ответа сервера (TTFB) — если больше 500 мс до начала загрузки страницы, проблема в серверной части: кеш, база данных, серверные скрипты.
Посмотрите на фильтр — откройте DevTools, выберите несколько значений фильтра и замерьте время запроса. Более 300 мс — повод разбираться с индексами.
Проверьте вес страницы категории — суммарный объем загружаемых ресурсов. Более 5-7 МБ для каталога — как правило, некомпрессированные изображения
Посмотрите на расписание синхронизации — когда запускается обмен с 1С? Не в пиковые часы? Не каждые 5 минут с полной выгрузкой?
Проверьте TTL кеша — для каких страниц он установлен? Нет ли страниц, где кеш отключен вовсе без явной на то причины?
Посчитайте количество сторонних скриптов — откройте вкладку Network в DevTools, отфильтруйте по типу Script. Запросы к сторонним доменам блокируют рендеринг страницы.
Вывод
Большой каталог — это операционный актив, который при правильной технической поддержке и грамотной навигации конвертируется в трафик и продажи. Тормозить начинает не «большой каталог», а конкретные узлы: фасетные фильтры без индексов, синхронизация с 1С в пиковые часы, изображения без компрессии, отключенный кеш.
Граница ответственности выглядит так: платформа закрывает кеширование, индексирование и базовую оптимизацию; CDN и внешние сервисы — доставку и сжатие медиа; владелец — правильную архитектуру обмена данных, дисциплину по содержанию каталога и контроль подключаемых модулей.
Навигация и скорость — это не два отдельных проекта. Сайт может быть быстрым и при этом терять покупателей из-за плохой фильтрации. Или иметь отличную навигацию, но тормозить настолько, что пользователи не доходят до фильтра.
Оптимизируйте оба измерения одновременно — и рост каталога станет конкурентным преимуществом, а не источником проблем.
Для тех, кто работает на 1С-Битрикс, есть бесплатное руководство по ускорению сайта. Там технические рекомендации по кешированию, работе с базой данных и настройке обмена с 1С.
Какие узкие места в своем каталоге вы находили последними, а не первыми? По опыту, чаще всего называют базу данных и синхронизацию — но интересно, что показывает ваша практика.