Так ли плох Битрикс на самом деле? Разбираем возможные причины технических проблем и низкой скорости интернет-магазина
Интернет-магазины и площадки электронной коммерции — это сложные системы, в работе которых могут случаться сбои и ошибки. Но в коммерческой среде простои в работе — это всегда убытки. В статье расскажу о том, как системно решать эту задачу.
Если сайт работает с ошибками и сбоями, то встает вопрос «Кто виноват?»
Нередко исполнители грешат на Битрикс. Типичные аргументы о недостатках платформы:
Проблемы при интеграции с 1С.
Недостаточная гибкость архитектуры.
Проблемы при обработке данных из нескольких источников.
Разрастание объема хранимых данных.
Проблемы масштабирования.
Сложная интеграция с современными средствами разработки верстки.
Но так ли плох Битрикс на самом деле? Кейс из практики
Клиент готовился к запуску нового сайта на готовом решении Aspro для Битрикс вместо старого — на Python. Но при перенаправлении на новый ресурс всего лишь 30% трафика (20 тысяч пользователей в сутки) он переставал выдерживать нагрузки и падал.
Клиент начал сомневаться, что новый сайт на Битрикс вообще выдержит их нагрузку. Встал вопрос: дорабатывать текущий сайт или создавать еще один, но на фреймворке.
Мы провели углубленный технический аудит сайта и нагрузочное тестирование, чтобы выявить слабые места. Проверили производительность текущего клиентского сайта, чистый шаблон Aspro.Next и Битрикс с настройками по умолчанию без изменений в коде.
Выяснили, что сайт на «чистом» Aspro.Next выдерживает нагрузку в разы большую той, чем нужно клиенту. Обнаружили, что проблемы на клиентском сайте связаны с некачественной кастомизацией компонентов Aspro и большим количеством некэшируемых запросов. После исправления ошибок сайт работает гораздо быстрее и с легкостью выдерживает даже большие нагрузки, чем на старой версии.
Почему экономить на разработке невыгодно. Некачественный сайт = низкая конверсия = убытки
Мнимая экономия на старте нередко приводит к тому, что в бэкенде накапливается большое количество проблем. В итоге через какое-то время подрядчик предложит либо произвести рефакторинг кода, либо полностью создать сайт с нуля.
К примеру, в рамках аудита интернет-магазина производственной компании мы нашли такое большое количество проблем и барьеров в UX, что клиент принял решение отказаться от старого сайта, так как бюджет по устранению ошибок был соразмерным. И несмотря на то, что мы всегда выступаем за постепенный редизайн, в данном случае выгоднее было разработать новый сайт.
Сбои в работе интернет-магазина — это прямое влияние на бизнес. Чем больше проблем, тем больше барьеров на пути пользователя, ниже конверсия и больше потерь.
Резкое падение конверсии после функционального сбоя на сайте
Кейс из практики
Ecom-директор в нашем проекте жаловался, что в периоды маркетинговой активности сайт зависал: административная панель работала крайне медленно, операторы не успевали обрабатывать заказы, а компания несла убытки.
Провели технический аудит и выяснили:
Структура кода требовала оптимизации.
Имелись функциональные проблемы и ошибки в верстке.
Некоторые модули 1С-Битрикс были настроены и использовались некорректно.
Основную нагрузку на сайт создавал обмен заказами с фулфилментом и неоптимальные настройки сервера по распределению задач. После доработки интеграции с фулфилментом и оптимизации серверных настроек, сайт и админ-панель начали работать быстро и без сбоев.
Типичные ошибки при техническом сопровождении сайта
Экономия в процессе технического сопровождения сайта может приводить к последующим сбоям. Перечислим типичные ошибки, которые мы встречали при проведении аудитов:
1. Ошибки при работе непосредственно с платформой Битрикс. Самая распространенная проблема — ошибки в работе типового функционала из-за модификаций в ядре 1С-Битрикс.
Есть еще одна серьезная проблема — создание самописных компонентов без особой необходимости вместо использования сложных комплексных и стандартных от Битрикс. Это вызывает проблемы при попытках расширения функционала, обновлении CMS и при развитии проекта.
2. Ошибки backend-разработки на PHP и Bitrix API. Запросы к БД в цикле, лишние файлы, служебные скрипты в открытом доступе, отсутствие защиты при обращении к GET- и POST-параметрам.
3. SQL-запросы в файлах страниц, шаблонах, запросы в циклах. Ошибки логики, постоянные повторы ошибок и, как следствие, высокая нагрузка на сайт и замедление его работы.
4. Кеширование компонентов отсутствует или отключено. В режиме отладки выводится сообщение о нулевом размере кэша, в результате — высокие нагрузки и замедление работы.
5. Ошибки верстки. Сайт загружается, но интерфейс не работает несколько секунд. В итоге пользователь видит сайт искаженным, а поисковые системы понижают сайт в ранжировании.
6. Проблемы с изображениями. Тяжелые и неоптимизированные картинки, которые могут быть низкого качества, устаревшего формата и в неэффективной кодировке.
7. Некорректная работа скриптов. Например, сами скрипты подключаются с внешних серверов, которые географически удалены от сервера сайта.
8. Низкий уровень безопасности сайта. Уязвимости к SQL-injection и Cross-Site Scripting. Файлы сессий, которые позволяют мошенникам получать доступ ко всем проектам на хостинге. Отладочная информация выводится на страницах публичной части, служебные файлы доступны по URL.
9. Не настроен сервер и его окружение. При повышении посещаемости сайт замедляется или вовсе отказывается работать. В итоге ресурс теряет позиции в поисковых системах и возможных клиентов.
10. Не настроено автоматическое резервное копирование. Последняя резервная копия сайта создана более недели назад, что может привести к потере важных данных и затратам на восстановление. Бэкап хранится на том же диске, на котором лежат файлы сайта. В случае взлома, удаления сайта или фатального выхода из строя серверного оборудования бэкап также пропадает.
11. Выполнение агентов на хитах. В больших интернет-магазинах есть служебные процедуры, которые запускаются редко, но занимают много времени, например, регулярная выгрузка номенклатуры на торговые площадки. Это приводит к замедлению работы сайта по причине непостоянного времени генерации страниц.
12. Не удалены неиспользуемые модули. Чем больше в системе модулей, тем дольше загружается любая страница и дольше запускается инициализация ядра платформы. Это приводит к медленной работе сайта.
Кейс из практики
К нам пришел крупный клиент из ювелирной тематики, у которого очень медленно работал сайт.
Провели технический аудит и обнаружили:
Низкое качество программной реализации.
Несоблюдение стандартов разработки на 1С-Битрикс и отсутствие документации.
Множество источников скрытых ошибок.
Уязвимости для безопасности сайта.
Места с повышенной нагрузкой.
Легаси от нескольких подрядчиков с различными стилями написания кода и отсутствием единой концепции.
Устранив большинство проблем и проведя рефакторинг, мы полностью решили вопросы со скоростью работы сайта.
Как проходит аудит и что получает заказчик
Что входит в техаудит:
Анализ работы сервера, кода и программной архитектуры.
Стандартные тесты 1С-Битрикс: качества, производительности, безопасности, работы модулей и компонентов.
Frontend-тестирование: кроссбраузерное и кроссплатформенное тестирование верстки на реальных устройствах, а также с использованием сервисов.
Нагрузочное тестирование: выявление предельных нагрузок, анализ достаточности настроек ПО сервера, анализ результатов и рекомендации.
Функциональное тестирование: корзины, оформления заказа, личного кабинета, регистрации и других элементов функционала.
Что в результате
По итогам анализа заказчик:
Получит подробный отчет, который содержит качественные и количественные данные, сводные таблицы и инфографику, выводы и рекомендации.
Сформирует целостную картину проблем, которые наблюдаются в серверной архитектуре и коде: backend и frontend.
Поймет, что нужно предпринять, чтобы увеличить скорость работы сайта.
Получит конкретные рекомендации, как исправить выявленные проблемы.
Сможет подготовить список важных задач для развития проекта и определите их приоритет.
