Как ускорить интернет-магазин на Битрикс?

Основные направления проверки интернет-магазина:

• время формирования страницы на сервере

• работа каталога, поиска и товарного фильтра

• запросы к базе данных и расчёт цен

• настройка кеширования

• размер изображений и состав кода страницы

• обмен с 1С, оплатой, доставкой и другими сервисами

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

Проблема редко выглядит одинаково на всём сайте. Главная страница может открываться быстро, а категория с большим количеством товаров — заметно медленнее. У неавторизованного посетителя карточка товара работает нормально, но после входа задерживается из-за расчёта персональной цены

В Ameton начинаем работу с воспроизведения проблемного сценария. Команда выясняет, что делает покупатель, когда появляется задержка, какие данные в этот момент обрабатывает магазин и какие внешние системы участвуют в операции. Такой порядок помогает не тратить время на изменения, которые не влияют на реальную проблему

Сначала нужно определить, где возникает задержка

Формулировка «магазин медленно работает» не позволяет выбрать способ оптимизации. Команде необходимо выяснить, какая страница или операция требует больше времени и при каких условиях это происходит

Направления диагностики зависят от наблюдаемого симптома:

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

Первая задача команды — превратить субъективное ощущение в воспроизводимый сценарий: действие пользователя, условия возникновения проблемы и ожидаемый результат

Мощный сервер не исправляет неэффективную работу магазина

Производительность сервера влияет на скорость сайта, но увеличение ресурсов помогает только тогда, когда магазин действительно достиг ограничений инфраструктуры. Если задержку создаёт конкретный компонент или повторяющийся запрос, более мощный сервер лишь быстрее выполнит ту же лишнюю работу

Команда проверяет загрузку процессора, использование памяти, скорость диска, состояние базы данных и настройки серверного окружения. Эти данные сопоставляются с действиями покупателей и фоновыми процессами магазина

Иногда текущему серверу хватает ресурсов, но они используются неэффективно из-за настроек базы данных, кеширования, PHP, веб-сервера или фоновых заданий. В таком случае правильная настройка окружения ускоряет магазин без перехода на более дорогую инфраструктуру. Поэтому сначала нужно проверить конфигурацию действующего сервера и только затем решать, требуется ли увеличение его мощности

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

В Ameton рекомендуем обсуждать перенос на новый сервер после диагностики. Инфраструктуру имеет смысл усиливать, когда измерения показывают нехватку ресурсов, а не потому, что это самое заметное и быстрое решение

Каталог и база данных требуют предметной проверки

Интернет-магазин постоянно обращается к данным о товарах, предложениях, свойствах, ценах, остатках и скидках. Скорость зависит не только от размера каталога, но и от того, как эти данные организованы и сколько операций выполняется для одной страницы

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

Штатные средства 1С-Битрикс позволяют увидеть ресурсоёмкие страницы, компоненты и запросы. Однако отчёт показывает место задержки, а решение принимает разработчик. Команда должна определить, зачем выполняется операция, какие данные действительно нужны и можно ли сократить обработку без изменения результата для покупателя

При проверке каталога важно ответить на следующие вопросы:

• какие данные загружаются для категории и карточки товара

• какие запросы выполняются повторно

• какие свойства используются в фильтре

• как связаны товары и торговые предложения

• когда пересчитываются цены и скидки

• что происходит с каталогом во время импорта

Оптимизация считается корректной только тогда, когда магазин быстрее выполняет исходную задачу и сохраняет правильные товары, цены, остатки и условия покупки

Фильтр и поиск нужно настраивать под реальный каталог

Фильтр замедляется не из-за самого наличия большого ассортимента, а из-за количества и структуры данных, которые он обрабатывает при каждом запросе. Особенно заметной проблема становится, когда в отбор включены десятки свойств, хотя покупатель использует только несколько из них

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

Команда проверяет, какие характеристики действительно помогают выбрать товар, насколько единообразно они заполнены и какие варианты сортировки нужны посетителям. Отключить фильтр или убрать половину характеристик технически просто, но такое ускорение может ухудшить выбор товара

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

Кеширование должно учитывать актуальность коммерческих данных

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

Меню, информационные блоки и часть каталога обычно можно подготовить заранее. Корзина, персональные цены и содержимое личного кабинета зависят от конкретного пользователя. Остатки и стоимость товара могут меняться после обмена с учётной системой

Основные различия при настройке кеширования:

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

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

Изображения и внешние скрипты также влияют на скорость загрузки магазина

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

Для каталога особенно важна подготовка изображений. Если в небольшой товарной карточке загружается исходная фотография большого размера, покупатель получает лишний объём данных. Команда создаёт подходящие версии изображений и загружает фотографии за пределами видимой области по мере прокрутки

Отдельно проверяются аналитика, онлайн-чаты, рекламные системы, формы обратного звонка и другие внешние подключения. Если сторонний скрипт блокирует отображение каталога, проблема будет восприниматься как медленная работа 1С-Битрикс, хотя задержка возникает уже после формирования страницы

В Ameton разделяем серверную и пользовательскую скорость. Это помогает понять, нужно ли менять работу компонентов или достаточно привести в порядок содержимое страницы

Интеграции не должны заставлять покупателя ждать внутренние процессы

Расчёт доставки, переход к оплате, получение остатков и передача заказа могут зависеть от внешних систем. Если магазин ждёт их ответ при каждом действии пользователя, задержка внешнего сервиса становится задержкой сайта

Например, при выборе доставки магазин может запрашивать тариф и срок у логистической службы. Если сервис временно недоступен, покупателю нужен понятный результат: повторный расчёт, другой доступный способ или сообщение о невозможности получить тариф. Бесконечное ожидание не является корректной обработкой ошибки

Что команда проверяет в связанных системах:

• какие обращения выполняются во время действий покупателя

• какие данные можно получать заранее

• какие операции можно выполнить после подтверждения заказа

• сколько времени сайт ожидает ответ

• что происходит при недоступности внешнего сервиса

• можно ли безопасно повторить неудачную операцию

• как обнаруживается частичная передача данных

Если заказ уже сохранён на сайте, то покупателю обычно не нужно ждать завершения всех внутренних обменов, потому что часть операций можно выполнить после оформления. При этом команда должна контролировать, что заказ передан, не продублирован и получил ожидаемый статус

Результат ускорения проверяют по пути покупателя

После оптимизации нужно повторить критичные действия покупателя, а не только открыть изменённую страницу. Ускорение каталога может затронуть фильтрацию, цены и доступность товаров, а изменение оформления заказа — доставку, оплату и передачу данных менеджеру

Сценарии для итоговой проверки определяются устройством магазина. Обычно команда проверяет:

• открытие основных категорий

• применение популярных фильтров и сортировок

• выбор торгового предложения

• отображение цены и остатка

• добавление и изменение товара в корзине

• применение скидки или промокода

• выбор способа доставки

• оформление и оплату заказа

• отображение заказа в личном кабинете

• передачу заказа в связанную систему

Скорость измеряют до и после изменений в сопоставимых условиях. Одновременно проверяют правильность результата: быстро открывающаяся карточка с неправильной ценой не считается успешно оптимизированной

Если команда меняет запросы, кеширование или расчёт заказа, то изменения сначала проверяют отдельно, потому что ошибка может проявиться не на изменённой странице, а на следующем шаге покупки

Компетентный разработчик понимает проект целиком

Компетентная команда не принимает просьбу «ускорить сайт» как готовую постановку задачи. Сначала она выясняет, какой сценарий мешает покупателю, какие данные в нём участвуют и что нельзя нарушить во время оптимизации

Вопросы, которые стоит задать разработчику:

• Какие пользовательские сценарии вы изучите до начала работ?

• На основании каких данных определите причину замедления?

• Какие товары, цены, остатки или пользовательские условия затронут изменения?

• Что вы проверите после выпуска?

• Какой риск вы видите в предлагаемой оптимизации?

Сильный ответ будет связан с конкретным устройством магазина. При работе с каталогом разработчик спросит об источнике товаров, цен и остатков. При оптимизации авторизации уточнит роли пользователей и персональные разделы. При изменении заказа проверит доставку, оплату, уведомления и дальнейшую передачу данных

Признак компетенции — способность связать изменение сайта с бизнес-результатом и назвать сценарий, который нельзя нарушить ради формального улучшения показателя скорости

Пример из практики Ameton

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

Команда исключила лишние операции и повторно проверила выдачу товаров, цены, остатки, сортировку и корзину. Категории стали загружаться быстрее, а логика выбора товаров сохранилась

Практический вывод: сначала нужно найти источник задержки и только затем решать, требуется ли усиление сервера

Как оценить предложение по ускорению интернет-магазина

Хорошее предложение объясняет, какую проблему команда собирается измерить, что может её вызывать и как будет проверен результат. Обещание «ускорить сайт» без описания сценариев и границ работ не позволяет оценить пользу изменений

Критерии обоснованного подхода:

Стоимость работ зависит от масштаба диагностики и найденной причины. Исправление одного неоптимального компонента и переработка каталога с несколькими интеграциями требуют разного объёма анализа, разработки и тестирования. Точную оценку можно дать после того, как команда воспроизведёт проблему и определит затронутые функции

Когда нужен технический аудит производительности

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

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

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

Ускорение интернет-магазина на 1С-Битрикс должно начинаться с конкретного вопроса: какое действие покупателя работает медленно и почему. Сервер, кеширование, каталог и интеграции проверяются не по отдельности, а как части одного сценария покупки

Ameton может провести диагностику магазина, воспроизвести проблемные действия и подготовить план оптимизации с порядком проверки результата. Для первого обсуждения достаточно адреса сайта, описания медленного сценария и информации о каталоге и подключённых системах