Магазин на 10 000+ товаров: каталог, карта сайта, скорость

Мы мерили 54 302 товара при первом ответе 413,8 мс и 55 321 товарную страницу при 840,5 мс. Оба магазина живы и работают. Ограничение здесь не в количестве строк в базе, а в том, как собрана страница категории: сколько запросов она делает, кэширован ли подсчет в фильтре, сколько модулей висит на каждой загрузке.

По умолчанию 4.x. Сам объем каталога от версии ядра почти не зависит: его содержат индексы MySQL, кэш категорий и то, как разбита карта сайта. Наше наибольшее измерение – 54 302 товара при первом ответе сервера 413,8 мс – сделано на 3.x; магазинов такого объема на 4.x мы еще не мерили, поэтому цифры для четверки не обещаем. От версии зависит другое – модули: в 4.x переписали систему событий, и часть украинских сборок (консольный импорт прайсов, генераторы sitemap-индекса, выгрузка на площадки) пока выходит только под 3.x. Поэтому список модулей под ваш каталог сверяем на брифе: все критическое есть под 4.x – ставим 4.x; чего-то еще нет – обсуждаем 3.x на старте, чтобы не упереться в это на этапе интеграций.

Стоимость здесь определяет не количество позиций, а состояние выгрузки, и именно поэтому назвать сумму до разбора невозможно. Разница в том, что внутри скрываются две разные задачи. Первая: один чистый прайс, один язык, фильтр по семи характеристикам – это нижний предел. Вторая: несколько источников данных с разными форматами, два языка, глубокий фильтр и десятки тысяч накопленных дублей адресов, которые нужно разобрать. Куда именно попадает ваш проект, виден после разбора выгрузки.

Половина срока – это не дизайн. Аудит и измерение текущего состояния 4–6 дней, ТС и схема импорта 4–6, прототип каталога и фильтра 4–7, дизайн и верстка 8–14, сборка и интеграция 9–16, импорт и чистка дублей 7–14, погрузочная проверка и передача 4–7. Самые длинные этапы – сборка и импорт, и именно их не получается сжать: заливка батчами с проверкой занимает столько, сколько занимает.

Двумя независимыми методами и сравниваем результат. Первый – карта сайта: считаем записи в каждой подкарте. Второй – штатный поиск OpenCart с пустым запросом и лимитом 100 на страницу. На магазине снаряжения первый метод дал 54 302 товара, второй - 54 501-54 600: расхождение 0,4%, и это нормально. Если методы расходятся в разы – значит, в карте сайта дубли, и это уже отдельная строка работ.

Дубль — это когда та самая карта доступна по нескольким путям категорий, и все они попадают в карту сайта. Мы фиксировали 33 493 записи на 8 690 уникальных адресов в магазине садовой техники, 25 537 на 6 857 в магазине инструмента, 3 971 на 590 в магазине специй. Краулер тратит бюджет на просмотр одного и того же, а часть каталога остается вне индекса. Разбор таких адресов — отдельный этап, и он тем длиннее, чем больше истории накопилось.

Проблема. Стандартный генератор OpenCart собирает всю карту одним запросом, и на большом каталоге это 34,2 секунды – именно столько мы зафиксировали в магазине инструмента. Краулер столько не ждет. Решение – sitemap-индекс: отдельные подкарты по 3 000 адресов на товары, категории и информационные страницы. Так сделано в магазине снаряжения: 32 файла вместо одного.

Тогда импорт ставится на расписание и работает батчами в фоне, а не разовой загрузкой. Важно разделить две вещи: полный импорт с созданием новых карт и быстрое обновление только цен и остатков. Второе выполняется в разы быстрее и не трогает остальные поля. Расписание под вашу частоту фиксируем в ТС на этапе схемы импорта.

Нет, и никто честный такого не пообещает. Скорость и полноту сканирования определяет Google. Наша зона — чтобы в карте сайта не было дублей, чтобы она отдавалась быстро и подкартами, чтобы страница категории собиралась быстрее секунды, а canonical стояли правильно. Это то, что мы можем измерить до и после и показать цифрами в акте.