Любое улучшение подразумевает исправление, оптимизацию кода проекта или повышение мощности вашего сервера, а это уже затрагивает финансовую сторону.
Все рекомендации и действия по оптимизации проектов, представленные в этой статье, могут нарушить работу магазина. Поэтому мы просим быть максимально аккуратными в своих действиях и, если что-то пошло не так, отменить ваши предыдущие действия и обратиться за помощью к специалистам CS-Cart или вашего хостинга с описанием того, что привело к проблеме.
Обновите CS-Cart Store Builder или Multi-Vendor, все темы и модули
Обновление ядра CS-Cart, тем и модулей важно, потому что в новых версиях есть патчи производительности, патчи для улучшения и оптимизации процессов работы и для исправления багов и уязвимостей. Это один из самых простых способов увеличить скорость и стабильность работы магазина.
Обновите версию PHP и используйте его возможности
Найдите максимальную версию PHP, поддерживаемую вашей версией CS-Cart Store Builder или Multi-Vendor.
Нагрузочные тесты, проведенные нами на последней версии CS-Cart и стандартной теме без сторонних модулей, показывают, что производительность проекта можно увеличить, обновив версию PHP.
Отдельно хочется обратить внимание на то, что это может привести к временной недоступности магазина. Перед обновлением действующего проекта мы рекомендуем провести проверку обновления локально или на тестовом сервере, или обратиться к разработчикам.
Используйте OPcache
Как работает PHP приложение? PHP открывает файлы с кодом, собирает их воедино, анализирует, токенизирует и компилирует, а затем выполняет. Так как файлов много, процесс их открытия, чтения и компиляции может отнимать значительные ресурсы. Но поскольку файлы меняются не так часто, то компиляцию каждый раз можно не делать. Оптимально будет совершить её один раз, закэшировать результат и после этого обращаться к нему.
Эту работу выполняет модуль OPcache. Он сохраняет результат компиляции в кэш, чтобы потом работать с ним, а не генерировать его снова и снова. Таким образом, это ускоряет работу PHP за счет отсутствия процесса компиляции. А когда код изменится, модуль OPcache инвалидирует кэш и совершит компиляцию снова. Следует отметить, что OPcache включен в большинство сборок PHP. Как правило, его не требуется настраивать. Однако это справедливо не для всех хостингов. Некоторые отключают проверку на изменения файлов, что может вызвать проблемы при обновлении.
Совет эксперта: чтобы избежать проверки временных меток при каждом запросе и дополнительно снизить нагрузку, можно в продакшене установить opcache.validate_timestamps=0. Мы не советуем такой подход, так как подобные настройки могут привести к серьёзным проблемам. На современных SSD и NVMe проверка временных меток происходит очень быстро и не влияет заметно на производительность. А вот использование устаревших кэшированных файлов после обновлений может вызвать критические ошибки, особенно если изменилась структура базы данных. Кроме того, такая настройка сильно затруднит отладку и замедлит решение проблем при обращении в поддержку. Лучше использовать более сбалансированный подход, например, через opcache.revalidate_freq.
Используйте FastCGI
FastCGI — это один из вариантов подключения PHP к веб-серверу. PHP-FPM (FastCGI контейнер для PHP) и NGINX по умолчанию поддерживают совместную работу и сконфигурированы для максимальной производительности друг с другом без дополнительных прослоек.
Некоторые программисты используют Apache с модулем mod_php в качестве веб-сервера, либо комбинируют NGINX как фронтенд с Apache (mod_php) и PHP. Да, Apache позволяет применять .htaccess-файлы, что удобно для начинающих администраторов, но это может снижать производительность примерно на 3–7% по сравнению со связкой NGINX + PHP-FPM.
При использовании Apache важно учитывать потенциальные уязвимости в его конфигурации по умолчанию. Например, чрезмерное использование .htaccess, включённые модули без необходимости, или некорректно настроенный Directory Listing могут повысить риски безопасности. Более подробная информация приведена, например, в CVE-2021-41773, где описана уязвимость в настройках Apache, позволяющая обходить ограничения доступа к файлам.
Мы рекомендуем использовать NGINX + PHP-FPM как более производительное и безопасное решение, особенно при правильной настройке и минимизации экспонированных компонентов. Эта связка способна заметно увеличить скорость загрузки сайта по сравнению с другими конфигурациями.
Рекомендация: полностью исключите mod_php. Если вы используете Apache, то подключайте PHP через php-fpm или mod_proxy_fcgi.
Ограничьте PHP и изучите каждый параметр, который планируете менять
Да, как это странно ни звучит, но выставлять максимальные настройки для PHP — не всегда хорошее решение. Если вы выделяете больше памяти или не ограничиваете время выполнения каких-либо процессов, то другим компонентам системы может не хватить ресурсов, или они будут конкурировать друг с другом, пока за ними не придет OOM Killer.
max_execution_time: 60
Мы не рекомендуем выставлять время работы скрипта больше 1 минуты для обычных процессов. Но такие процессы как импорты, экспорты и обновления CS-Cart бывают долгими и для этих процессов иногда может потребоваться увеличение “таймаутов” на стороне PHP и MySQL.
Если процесс сложный, требующий увеличения этого параметра, лучше разбить его на более мелкие процессы и задачи. Попросите разработчиков декомпозировать длительные и тяжелые процессы на более мелкие, так как это повысит надежность системы в целом и вашего проекта в частности.
memory_limit: “512M”
Не стоит устанавливать значение этого параметра слишком большим, так как OOM Killer будет в этом случае приходить за всем PHP сразу. И не забывайте, что у вас есть еще MySQL и какие-то еще компоненты – им тоже нужна память, а еще самой системе для работы нужна память.
Примечание: для крупных магазинов с большим количеством товаров или сторонними модулями допустимы значения 768M или 1024M. Но перед увеличением — отслеживайте фактическое потребление памяти.
Обновите и оптимизируйте базу данных (MySQL)
Переконвертируйте все таблицы из MyISAM в InnoDB
В CS-Cart последних версий уже действует практика: все новые функции, а также переработанные модули и таблицы создаются на InnoDB. Это позволяет базе данных при тяжёлых и долгих запросах блокировать не всю таблицу, а только строки, с которыми идёт работа, а также обеспечит лучшую целостность данных благодаря поддержке транзакций и внешних ключей.
Ниже — главные отличия InnoDB и MyISAM:
- InnoDB поддерживает блокировки уровня строки, а MyISAM — только уровня таблицы).
- InnoDB поддерживает так называемую «целостность по ссылке», что включает поддержку ограничения внешних ключей (RDBMS), а MyISAM нет (DMBS).
- По сравнению с MyISAM, InnoDB использует журнал транзакций для автовосстановления и лучше справляется с высокими нагрузками.
Оптимизируйте настройки MySQL
Многие параметры нужно выставлять в зависимости от объема оперативной памяти, поэтому в рамках этой статьи мы не сможем дать точные значения, но укажем направление для исследования и размышления.
wait_timeout: 60
Очень долгий запрос в базу данных — это проблемный запрос, и он должен быть оптимизирован или переписан. Не нужно завышать время выполнения запроса, если он плохой — это приведет к проблемам для других запросов и процессов. Крайне редко бывают случаи когда этот параметр нужно увеличивать, но мы рекомендуем после проведения тяжелых работ этот параметр вернуть в исходное состояние.
Очень часто причиной долгих запросов является проблема при его проектировании.
Используйте MySQLTuner — он анализирует настройки на основе реального использования и даёт конкретные рекомендации для оптимизации. Очень полезный инструмент при настройке MySQL.
Рассмотрите MariaDB
На 2025 год MariaDB 10.11 LTS — это зрелая и совместимая с MySQL альтернатива с рядом уникальных функций, таких как улучшенная работа с виртуальными столбцами, расширенные движки хранения и системные таблицы в формате Aria. Однако стоит учитывать, что по результатам некоторых сравнительных тестов, MySQL 8 может показывать лучшую производительность в определённых сценариях — например, при сложных запросах с использованием JSON. Выбор зависит от типов нагрузок: если критичны скорость insert-операций, репликация или нагрузка на CPU — MariaDB может быть предпочтительнее. Для других сценариев — возможно большее внимание к настройке и оптимизации MySQL.
Увеличьте мощности сервера
Не все проблемы с производительностью сайта можно решить увеличением параметров конфигурационных файлов PHP, MySQL или обновлением серверного ПО. Иногда наступает момент когда нужно задуматься о повышении мощности сервера или тарифного плана у вашего хостера. Это может быть установка дополнительных аддонов, увеличение количества товаров или просто рост количества посетителей вашего сайта.
Также мы рекомендуем повышать мощности сервера на периоды распродаж и маркетинговых акций.
Совет: рассмотрите возможность использования облачных или контейнеризированных решений, таких как AWS, DigitalOcean, Docker или Kubernetes. Они обеспечивают масштабируемость и гибкость под рост вашего проекта.
Используйте HTTP/2 (и TLS 1.3), а также рассмотрите поддержку HTTP/3
Производительность здесь тесно связана с безопасностью. Протокол HTTP/2, поддерживаемый большинством современных браузеров и серверов, значительно оптимизирован по сравнению с HTTP/1.1 — он обеспечивает мультиплексирование запросов, сжатие заголовков и более эффективное использование соединений. Многие хостинг-провайдеры и веб-серверы (например, NGINX и Apache с соответствующими модулями) уже включают HTTP/2 по умолчанию при использовании HTTPS.
Практические шаги:
- NGINX: убедитесь, что в конфигурации listen указаны параметры ssl http2, например:
listen 443 ssl http2;
- Apache: проверьте, что модули mod_http2 и mod_ssl включены. В конфиге должно быть:
Protocols h2 http/1.1
Поддержка HTTP/3 (на базе QUIC) способна ещё больше повысить производительность, особенно в условиях высокой задержки и на мобильных сетях. Поддержка уже реализована во многих CDN (Cloudflare, Fastly) и браузерах. Серверы с поддержкой HTTP/3, например, NGINX (через quiche) и Caddy, требуют дополнительной настройки.
TLS 1.3 также настоятельно рекомендуется. Он не только повышает безопасность, но и ускоряет установление соединения благодаря сокращённому хендшейку.
Как включить TLS 1.3:
- NGINX: убедитесь, что используется OpenSSL 1.1.1+ и в конфигурации указано:
ssl_protocols TLSv1.3 TLSv1.2;
- Apache: с OpenSSL 1.1.1+ и Apache 2.4.38+:
SSLProtocol -all +TLSv1.2 +TLSv1.3
Проверьте поддержку с помощью SSL Labs Test или аналогичных инструментов.
Рекомендация: поддержка HTTP/3 (на базе QUIC) ещё больше увеличивает производительность, особенно для мобильных устройств и при высоких задержках соединения. Большинство современных браузеров и CDN уже поддерживают этот протокол.
Также обязательно включите TLS 1.3 — он обеспечивает как улучшенную безопасность, так и более быстрый обмен данными за счёт сокращения квитирования.
Твики и опции CS-Cart
В случае, если после внесения изменений проект перестал быть доступным — отмените изменения и обратитесь к технической поддержке CS-Cart и вашему хостеру. Они помогут вам с настройкой.
Используйте Imagick
GD и Imagick — это два независимых друг от друга расширения PHP для работы с графикой. Оба модуля очень схожи, однако Imagick дает более качественный результат при создании миниатюр изображений. При этом используя меньше памяти.
Для того чтобы включить Imagick, измените в массиве $config[‘tweaks’] файла config.local.php значение твика на imagick:
'image_resize_lib' => 'imagick',
Примечание: если Imagick не установлен на сервере, принудительное указание imagick может вызвать ошибки. Нужно предусмотреть проверку доступности компонента.
Также обратите внимание на то, что если у вас в файле config.local.php напротив image_resize_lib стоит auto, то если у вас установлен imagick, то он будет использоваться по умолчанию.
Включите APCu для кэша и Redis для хранения сессий
Мы рекомендуем использовать APCu для хранения кэша в CS-Cart и Redis — для хранения пользовательских сессий. Такое разделение позволяет снизить нагрузку на базу данных и файловую систему, ускоряя обработку запросов и повышая отзывчивость приложения.
Однако важно учитывать, что внедрение дополнительных сервисов (таких как Redis) увеличивает общую сложность инфраструктуры: появляется дополнительная точка отказа, за состоянием которой также нужно следить (например, с помощью мониторинга и перезапуска через systemd или supervisord).
Кроме того, перенос кэша в APCu означает, что кэш будет храниться в оперативной памяти каждого PHP-процесса. Это может увеличить общее потребление RAM и повлиять на производительность в системах с ограниченными ресурсами. Также APCu работает только в режиме mod_php или php-fpm и не подходит для многосерверных конфигураций, где кэш должен быть разделяемым.
Перед внедрением такого подхода убедитесь, что ваша инфраструктура учитывает эти особенности и обеспечивает стабильную работу всех компонентов.
$config['cache_backend'] = 'apcu';
$config['session_backend'] = 'redis';
Включение этих параметров в конфигурационном файле требует преднастроенных APCu в PHP и Redis на вашем сервере. Перед изменением конфигурационного файла убедитесь что APCu и Redis у вас доступны для использования на сервере. В случае, если вы не уверены или не знаете точно, обратитесь к системному администратору или хостеру для их настройки.
Для бэкапов используйте mysqldump
Mysqldump — это серверное расширение, которое установлено на всех современных хостингах, и все администраторы рекомендуют использовать его для создания бэкапов базы данных. Для бэкапов используйте mysqldump.
В CS-Cart поддержка mysqldump доступна, но по умолчанию отключена. Это связано с тем, что на некоторых хостингах mysqldump может быть недоступен, работать нестабильно или требовать дополнительных прав. Поэтому разработчики CS-Cart по умолчанию используют встроенный PHP-метод резервного копирования, который обеспечивает более широкую совместимость, но может быть менее эффективен на больших базах данных.
Чтобы включить mysqldump для бэкапов, добавьте параметр:
$config['tweaks']['backup_db_mysqldump'] = true;
в массив $config[‘tweaks’] в файле config.local.php.
После этого CS-Cart будет использовать mysqldump при создании резервных копий базы данных, что особенно полезно для больших проектов — дампы создаются быстрее и с меньшей нагрузкой на PHP-процесс.

Добавьте блокировку бэкэнда для процессов генерации кэша
В последних версиях CS-Cart появилась возможность предотвратить одновременную генерацию кэша несколькими пользователями. Это особенно полезно при высоких нагрузках — например, после очистки кэша или при первом запуске после деплоя.
Чтобы включить эту защиту, в файле config.local.php добавьте строку:
$config['lock_backend'] = 'database';
В этом случае CS-Cart будет использовать базу данных для хранения информации о блокировке, не допуская одновременного запуска ресурсоёмких операций.
Также поддерживается использование Redis в качестве хранилища блокировок, что предпочтительнее для высоконагруженных проектов, особенно в распределённых средах. Для этого укажите:
$config['lock_backend'] = 'redis';
Важно: убедитесь, что Redis доступен и корректно настроен в CS-Cart. Использование Redis повышает производительность и снижает нагрузку на базу данных при работе с блокировками.
Это поможет избежать не только перегрузки сервера во время генерации кэша, но и проблем с корректной обработкой заказов. В последних версиях CS-Cart механизм блокировок также используется при взаимодействии с платёжными системами, такими как Stripe и PayPal. Без активной блокировки возможно некорректное обновление статусов заказов, что, в свою очередь, может привести к ошибкам в учёте остатков товаров и другим сбоям в бизнес-логике.
Совет эксперта: используйте модуль Performance Booster. Performance Booster — это встроенный в CS-Cart инструмент для улучшения кэширования и ускорения работы магазина. Он позволяет сократить время генерации страниц за счёт оптимизированной работы с кэшем и более эффективного хранения данных. В версиях CS-Cart до 4.19.1 модуль устанавливается отдельно, а начиная с 4.19.1 будет входить в стандартную поставку (в ядро системы) — хотя доступен он будет не во всех тарифных планах.
Рекомендуем активировать Performance Booster и протестировать работу магазина до и после включения — в большинстве случаев наблюдается заметный прирост скорости загрузки страниц.
Как найти и исправить проблемы производительности CS-Cart без навыков программирования
Даже без знаний кода вы можете выявить и устранить узкие места производительности вашего магазина на CS-Cart или CS-Cart Multi-Vendor. Ниже — практические советы и метрики, которые помогут вам провести базовую диагностику самостоятельно.
Используйте встроенный отладчик CS-Cart
CS-Cart имеет встроенный режим разработчика (debug mode), который можно активировать, добавив параметр ?debug к URL. После этого в правом верхнем углу появится значок “жука”, по нажатию на который откроется подробная информация:
- SQL — количество и время выполнения запросов к базе данных.
- Blocks — скорость загрузки блоков и использование памяти.
- Page generation time — общее время генерации страницы.
Метрики, на которые стоит ориентироваться:
Показатель | Рекомендованное значение |
Время генерации страницы | ≤ 1 сек. — отличная производительность 1–2 сек. — нормальное значение > 2 сек. — повод для анализа и оптимизации |
Время запроса к БД | ≤ 0.1 сек. — хорошее значение > 0.1 сек. — стоит проверить запрос и оптимизацию индексов |
Кол-во блоков из кэша | ≥ 5 из 20 — допустимо, но чем больше блоков берётся из кэша, тем лучше производительность |
Время рендера блоков | ≤ 0.1 сек. — быстро 0.1–2 сек. — допустимо, но требует внимания > 2 сек. — повод для детального разбора |
Совет: включите отладчик, затем переходите по страницам — вы увидите, какие блоки или модули загружаются медленно, и где нужно искать узкое место.
Проверьте настройки кэширования
- В административной панели перейдите Дизайн → Темы, и проверьте, выключена ли опция “Перестраивать кэш автоматически”. Если сайт уже в продакшене и не ведутся частые правки — отключите эту опцию.
В файле config.local.php проверьте, чтобы было:
$config['tweaks']['disable_block_cache'] = false;
Иногда разработчики по ошибке оставляют кэш отключенным, что может заметно снизить производительность.
Оптимизируйте изображения
- Проверьте сайт через Google PageSpeed, чтобы выявить тяжёлые изображения.
- Щелкните правой кнопкой по изображению → Inspect Element, чтобы посмотреть реальный размер.
- Используйте сервисы сжатия изображений без потери качества: tinypng.com, imagecompressor.com и др.
Проверьте модули
Некоторые сторонние модули могут генерировать сотни запросов к базе, особенно при большом количестве сущностей (товаров, брендов и т.п.).
Что делать:
- Включите отладчик и перейдите на медленную страницу.
- Перейдите на вкладку SQL — отследите, какие модули или блоки делают много или долгих запросов.
- Во вкладке Blocks проверьте, какие блоки грузятся дольше всего.
- В разделе Модули → Управление модулями отключите подозрительные модули и проверьте, изменилась ли производительность.
- Если сторонних модулей много — отключите все, затем включайте по одному, чтобы выявить “тормозной”.
Обратите внимание на cron-задачи и внешние синхронизации
Некоторые задачи (бэкапы, синхронизация с внешними сервисами, рассылки) могут запускаться в часы пик и нагружать сервер.
Решение: настройте запуск таких cron-задач на время с наименьшей активностью пользователей (например, ночью), согласно аналитике посещаемости.
Опирайтесь на метрики
Многие инструменты показывают противоречивые данные (включая Google PageSpeed). Например, даже крупные eCommerce-проекты получают низкие оценки при тестах в мобильной сети. Это не всегда отражает реальную производительность сайта для пользователей.
Советы:
- Проверяйте метрики регулярно.
- Сравнивайте показатели до и после изменений.
- Не полагайтесь только на внешний отчёт — смотрите, как сайт работает “вживую”.
Краткие выводы
- Отключите Rebuild cache automatically, если не ведёте разработку.
- Убедитесь, что disable_block_cache не включён по ошибке.
- Оптимизируйте изображения, особенно на главной и карточках товаров.
- Отключите или перепроверьте тяжёлые модули (по SQL-запросам и рендеру блоков).
- Используйте встроенный отладчик и думайте критически при оценке производительности.
Совет Андрея Мягкова, CTO CS-Cart:
“Не зацикливайтесь на оценках тестов — ориентируйтесь на реальные метрики и опыт пользователей. Низкий PageSpeed не всегда значит, что сайт медленный. Смотрите, где физически расположен ваш сервер и откуда приходят пользователи. Если магазин в Австралии, а клиенты — из Европы, задержки будут не из-за “плохой оптимизации”, а из-за расстояния. Иногда достаточно разместить копию проекта ближе к аудитории, и всё заработает заметно быстрее. Тесты — это подсказка, а не приговор”.
Более подробно советы по быстрой оптимизации и поиску проблем с производительностью вашего проекта на CS-Cart Store Builder и CS-Cart Multi-Vendor без навыков программирования описаны здесь. А также мы рассказывали в статье о том, что влияет на скорость работы сайта в целом.
Каталог продуктов и сервисов CS-Cart
- ★ CS-Cart для маркетплейсов: онлайн-демо
- ★ CS-Cart для интернет-магазинов: онлайн-демо
- ★ Мобильное приложение: App Store, Google Play
- ★ Cloud-хостинг: преимущества и условия
- ★ Сервис Заботы: чем полезен сервис
Гаянэ
Гаянэ Тамразян — писатель и контент-маркетолог, специализирующийся на электронной коммерции. Она создает информативные и актуальные статьи, которые помогают читателям разобраться в сложностях цифровой торговли. Ее стиль написания отличается ясностью и доступностью, что делает материал понятным как для профессионалов, так и для широкой аудитории. Гаянэ стремится делиться знаниями, вдохновляя бизнес и потребителей на успешное взаимодействие в быстро меняющемся мире онлайн-торговли.