Покупатель уже указал адрес, но расчет стоимости доставки бесконечно загружается; после нажатия кнопки оплаты ничего не происходит, и повторно отправлять заказ страшно. Медленная работа страницы оформления заказа — это не только проблема загрузки страницы: задержка может возникать при расчете налогов, проверке наличия товара или перенаправлении на оплату. Сначала определите, что именно происходит: страница не открывается, форма медленно реагирует, заказ долго отправляется или медленно выполняется возврат после оплаты. Затем оптимизируйте API, скрипты и платежную цепочку, а не пытайтесь решить проблему наугад сжатием изображений или обновлением сервера.
При ускорении сайта электронной коммерции (commerce website acceleration) сначала воспроизведите полный процесс оформления заказа и зафиксируйте, на каком этапе возникает ожидание. Быстрая загрузка страницы товара не означает, что оформление заказа тоже будет быстрым: этот процесс связан с пользовательскими данными и транзакциями в реальном времени, поэтому многие запросы нельзя заменить общедоступным кэшированием.
Откройте панель Network (Сеть) в инструментах разработчика браузера и сохраните журнал запросов. Перейдите из корзины к оформлению заказа, последовательно укажите адрес, выберите способ доставки и отправьте тестовый заказ. По возможности используйте тестовую среду и платежную песочницу; зафиксируйте целевой рынок, устройство, сетевые условия и время тестирования, чтобы сравнить результаты до и после изменений.
Вкладка Timing (Время) в сведениях о запросе помогает различить время ожидания в очереди, установления соединения и ответа. Длительное ожидание первого байта — лишь один из признаков: оно само по себе не доказывает, что проблема связана с медленной работой базы данных. Для диагностики также изучите серверные журналы. Перед отправкой снимков экрана или журналов скройте имена, адреса, токены и платежные данные.

Если пересчитывать налоги и стоимость доставки при вводе каждого символа адреса, будет отправляться слишком много запросов; кроме того, запоздавший ответ на старый запрос может заменить верный результат нового. Запускайте расчет, когда пользователь перестал вводить данные, покинул поле или заполнил все обязательные поля, и отменяйте устаревшие запросы, чтобы одновременно не отображалось несколько индикаторов загрузки.
Затем проверьте, действительно ли запросы зависят друг от друга. Например, проверку наличия товара и проверку некоторых частей адреса можно выполнять независимо, не ожидая завершения каждого запроса по очереди. Но нельзя бездумно запускать расчет налогов заранее, если он зависит от адреса и данных о товарах. Передайте разработчикам схему последовательности запросов, отметив самый долгий запрос и его зависимости: так проблему будет проще решить, чем по расплывчатому сообщению «оформление заказа тормозит».
Часто причина связана с выполнением скриптов, а не только с размером загружаемых ресурсов. Виджет чата, тепловые карты, рекламные теги и повторяющиеся аналитические события могут занимать основной поток и замедлять реакцию полей ввода, кнопки промокода и кнопки оплаты. Запишите процесс зависания на панели Performance (Производительность), найдите длительные задачи, а затем поочередно отключайте необязательные компоненты в тестовой среде, чтобы проверить, связана ли проблема с ними.
На странице оформления заказа в первую очередь должны загружаться ресурсы, необходимые для совершения транзакции. Необязательные маркетинговые скрипты можно загружать с задержкой, но платежный SDK, проверку системы предотвращения мошенничества и обязательное управление согласием нельзя удалять бездумно. После изменения правил срабатывания тегов проверьте, не теряются ли события покупки и не отправляются ли повторно, чтобы ускорение страницы не искажало данные о конверсиях рекламы.
Изображения и шрифты тоже можно оптимизировать, однако на странице оформления заказа обычно не нужно показывать товары с помощью крупных изображений. Если основная задержка вызвана API, дальнейшее сжатие миниатюр товаров не устранит главную проблему.
После отправки заказа сразу покажите статус обработки и заблокируйте повторное нажатие. На серверной стороне также необходимо распознавать повторные запросы с помощью механизма идемпотентности: блокировка кнопки на стороне клиента не заменяет защиту транзакций. При превышении времени ожидания сначала проверьте исходный заказ и статус оплаты, а затем решите, нужно ли повторить попытку. Не инициируйте списание повторно без проверки.
Попросите разработчиков отдельно фиксировать время создания заказа, проверки наличия товара, создания платежной сессии и получения обратного вызова. Уведомления по электронной почте и синхронизацию маркетинговых тегов можно выполнять асинхронно, не задерживая оплату. Но пропускать проверку наличия товара, суммы и статуса заказа ради ускорения нельзя.
Страница завершения оплаты также не должна определять успешность платежа только по параметрам перенаправления браузера. Пользователь может закрыть страницу, а обратный вызов может поступить с задержкой. Обновляйте статус заказа на основании достоверного результата, полученного сервером, и предусмотрите возможность проверить статус. Если используется внешняя платежная страница, протестируйте соединение и перенаправление в целевых регионах: результаты, полученные в офисной сети, не обязательно отражают опыт зарубежных покупателей.
За один раз изменяйте только один тип параметров и повторяйте тест при сопоставимых условиях устройства, региона и сети. Помимо среднего времени обработки, отслеживайте распределение длительности медленных запросов, частоту ошибок API, дублирование заказов и долю успешных оплат. Улучшение показателей загрузки страницы еще не означает, что вся цепочка оформления заказа стала быстрее.
Задержку при ожидании оплаты и срок зачисления средств следует рассматривать как разные вопросы. Если параллельно вы оцениваете управление финансами, можете отдельно прочитать материал Обсуждение стратегий оптимизации управления финансами энергетических предприятий на основе прогнозирования денежных потоков; в нем рассматривается финансовый менеджмент, а не диагностика производительности процесса оформления заказа.
При обращении в команду разработки сайта или эксплуатации приложите шаги для воспроизведения проблемы, регион, обезличенные записи запросов и идентификатор соответствующего заказа. Если уже произошло повторное списание, сумма не совпадает или статус заказа некорректен, приостановите связанные изменения и сначала сверьте транзакции, а не продолжайте внедрять настройки для ускорения.
Связанные статьи
Связанные продукты


