Пока владельцы магазинов на CS-Cart покупают дорогие серверы, их клиенты ждут по 10 секунд на пустом месте

Пару лет назад ко мне пришел клиент с типичной, но болезненной историей. Крупный магазин автотоваров на CS-Cart, около 45 000 товаров. Ребята только что переехали на выделенный сервер с 16 ядрами NVMe за 250 евро в месяц. Базу вылизали, Redis настроили, Varnish прикрутили. Но менеджер открывает категорию «Тормозные диски» после утренней синхронизации с 1С — и страница висит 11 секунд. Белый экран, крутится колесо загрузки, клиент уходит на маркетплейс.

Владелец винил движок, хостинг, верстку и ленивых программистов. На деле причина была банальной, и с ней сталкивается каждый второй проект, где каталог обновляется чаще раза в месяц.

Анатомия проблемы: налог на первого посетителя

В CS-Cart из коробки заложен механизм отложенной генерации изображений (lazy thumbnail generation). Работает это просто: движок не создает уменьшенные копии фото заранее. Зачем тратить место на диске, если товар никто не посмотрит? Логика понятная, но в реальном e-commerce она превращается в катастрофу.

Представьте типичный сценарий. Прошел ночной обмен с учетной системой: обновились цены, остатки или залетела сотня новых позиций. Кэш сбросился. Утром на сайт заходит реальный покупатель с деньгами и открывает категорию на 48 товаров. Что делает сервер в эту секунду?

Он не просто отдает HTML. PHP-FPM перехватывает 48 запросов к несуществующим картинкам. Для каждого товара он достает из хранилища исходник — часто это тяжелый файл 3000x2000 пикселей весом в 4 Мб прямо из фотоаппарата контент-менеджера. Библиотека GD или Imagick начинает синхронно пережимать эти файлы в три разных размера: для сетки, для галереи и под ретину.

Итог — cs-cart медленная загрузка категорий, взлетающий до 100% Load Average, забитый пул PHP и посетитель, который закрывает вкладку через 4 секунды. Сервер не слабый. Его просто заставили на лету делать тяжелую пакетную работу прямо в момент клиентского запроса.

Почему стандартная оптимизация CS-Cart магазина здесь бессильна

Когда начинается паника из-за просадки скорости, владельцы обычно идут по накатанной дорожке:

Ставят модули полностраничного кэширования. Но кэшировать страницу, где половина картинок генерируется на лету, бессмысленно — первый запрос все равно будет висеть, отдавая 504 Gateway Time-out. Докупают ядра процессора. Это помогает проглотить 5–6 одновременных генераций вместо двух, но фундаментально ничего не меняет: процессор должен молотить графику вместо отдачи бизнес-логики.

Настоящая оптимизация cs-cart магазина начинается не с покупки мощностей, а с устранения паразитной нагрузки. Браузер должен забирать готовый статический файл напрямую через Nginx за 15–20 миллисекунд. Никакой PHP вообще не должен просыпаться при запросе картинки товара.

Как решить вопрос раз и навсегда

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

Сразу после импорта каталога или планового сброса кэша запускается фоновый скрипт через CLI (консоль сервера, а не браузер). Он тихо, в несколько параллельных потоков, с контролируемым приоритетом процессора проходит по всем новым товарам и категориям, нарезая кэш миниатюр cs-cart под все заданные в теме витрины размеры.

Когда живой человек открывает каталог, Nginx моментально отдает уже лежащие на диске WebP или JPEG файлы. Время до первого байта (TTFB) падает с 6–8 секунд до стабильных 200–300 мс. Процессор сервера при этом отдыхает, а страницы листаются так, будто это статический сайт на 5 страниц, а не монстр на десятки тысяч позиций.

Это и есть честное ускорение cs-cart: мы не прячем мусор под ковер сложными надстройками, а заставляем архитектуру работать правильно — тяжелые задачи уходят в бэкграунд, пользователи получают мгновенный отклик.

Практика GuardLabs

В GuardLabs мы набили на этом достаточно шишек, поддерживая нагруженные проекты. Чтобы владельцы магазинов не вздрагивали после каждой выгрузки из 1С, мы вынесли эту процедуру в отдельный отлаженный сервис. Наш прогрев кэша миниатюр в CS-Cart настраивается один раз на уровне сервера, перехватывает изменения каталога и автоматически подготавливает изображения до того, как их запросит первый клиент. Если вам надоело ловить просадки скорости и терять покупателей на пустых генерациях — заходите, настроим все без простоя сайта.