Как отключить AJAX-обновление корзины при изменении вариации товара в WooCommerce

На некоторых магазинах WooCommerce корзина начинает дергаться при каждом изменении вариации: меняется размер, цвет или комплект — и страница отправляет лишний AJAX-запрос. Это заметно на медленных шаблонах, в мобильной сети и на сайтах, где в корзине много кастомной логики: купоны, доставка, пересчет бонусов, сторонние виджеты.

Если задача не в том, чтобы полностью переписать корзину, а в том, чтобы убрать лишнее обновление и оставить стандартное поведение WooCommerce, это можно сделать точечно. Ниже — как понять, что именно вызывает запрос, чем отключение отличается от полного выключения AJAX в корзине и как проверить, что после правки ничего не сломалось.

Когда проблема действительно в AJAX-обновлении

Сначала стоит убедиться, что тормозит не сам шаблон товара и не тяжелые скрипты темы. Типичный признак — в DevTools в Network видно запросы к ?wc-ajax=update_order_review или к другим WooCommerce AJAX-эндпоинтам сразу после смены вариации. На странице корзины это часто выглядит как лишний пересчет итогов, хотя пользователь еще ничего не менял в самом заказе.

Что проверить в браузере

• Откройте страницу товара и вкладку Network.
• Выберите вариацию и посмотрите, какие запросы уходят в сеть.
• Проверьте, не запускается ли обновление корзины из-за кастомного JS темы или плагина.
• Сравните поведение в режиме инкогнито и без кэша браузера.

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

Какие есть варианты решения

Есть три рабочих подхода: отключить конкретный AJAX-обработчик через код, убрать триггер на стороне темы/скрипта, либо использовать плагин оптимизации, если в проекте уже есть такой слой. Для точечной задачи обычно проще и безопаснее код, потому что он не затрагивает остальную логику WooCommerce.

Подход	Что делает	Когда подходит	Компромисс
Код в теме или мини-плагине	Отключает конкретное поведение	Когда нужен контроль над одним сценарием	Нужно тестировать после обновлений
Плагин оптимизации	Убирает часть лишних скриптов и запросов	Если уже используется инструмент для чистки фронтенда	Не всегда дает точечный контроль
Правка JS темы	Удаляет триггер обновления	Если запрос вызывает именно тема	Можно сломать другие сценарии

Пошаговое решение через код

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

<?php
add_action( 'wp_enqueue_scripts', function () {
    if ( ! function_exists( 'is_product' ) || ! is_product() ) {
        return;
    }

    // Пример: отключаем кастомный скрипт темы, который триггерит лишний AJAX
    wp_dequeue_script( 'theme-variation-cart-sync' );
    wp_deregister_script( 'theme-variation-cart-sync' );
}, 20 );

Этот вариант работает только если вы знаете точный handle скрипта. Его можно посмотреть в исходниках темы или через поиск по wp_enqueue_script. Если handle неизвестен, сначала найдите, какой файл подключается на странице товара и какой код вызывает jQuery.post, fetch или $.ajax.

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

<?php
add_action( 'wp_enqueue_scripts', function () {
    if ( ! function_exists( 'is_cart' ) || ! is_cart() ) {
        return;
    }

    wp_add_inline_script(
        'wc-cart',
        "document.addEventListener('change', function(e){\n            if (e.target && e.target.matches('.qty')) {\n                e.stopImmediatePropagation();\n            }\n        }, true);"
    );
}, 20 );

Это не универсальный рецепт для всех тем, но он показывает принцип: не трогать WooCommerce целиком, а убрать именно тот триггер, который запускает лишний пересчет. В реальном проекте лучше вынести такую правку в небольшой mu-plugin, а не держать в functions.php активной темы.

Если нужен более безопасный вариант

Когда на сайте много сторонних интеграций, лучше не отключать все подряд, а сначала проверить, можно ли ограничиться правкой только для конкретной страницы или конкретного шаблона. Например, если лишний AJAX нужен только на мобильной версии, а на десктопе мешает, условие можно сузить через wp_is_mobile(). Но использовать это стоит осторожно: мобильность не всегда равна типу устройства, и такой фильтр не подходит для бизнес-логики.

Как проверить, что решение сработало

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

• Откройте страницу товара и повторите смену вариации.
• Проверьте Network: лишний AJAX-запрос больше не должен уходить.
• Добавьте товар в корзину и убедитесь, что стандартный сценарий WooCommerce работает.
• Проверьте корзину с купоном, доставкой и налогами, если они используются.
• Протестируйте страницу в режиме гостя и авторизованного пользователя.

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

Частые ошибки и как их исправить

Отключили не тот скрипт

Самая частая ошибка — убрать файл, который отвечает не за лишний AJAX, а за базовую работу вариаций. В результате селекторы вариаций перестают подставлять цену, изображение или SKU. Исправление простое: возвращайте скрипт назад и ищите именно тот handle, который вызывает пересчет корзины.

Правка конфликтует с мини-корзиной или купонами

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

Изменение внесли в тему, а потом потеряли после обновления

Для точечных правок не стоит использовать файл темы, если он обновляется разработчиком. Надежнее создать небольшой плагин для сайта или mu-plugin. Тогда отключение AJAX не исчезнет после апдейта шаблона.

Что делать, если запрос вызывает не WooCommerce, а тема

Иногда проблема не в ядре, а в теме, которая пытается синхронизировать цену, наличие или состав корзины при каждом изменении вариации. Тогда отключение через WooCommerce-хуки не поможет. Нужно найти JS-файл темы, где есть обработчик на событие found_variation, change или woocommerce_variation_has_changed, и убрать именно этот вызов.

Пример поиска по коду темы:

jQuery( function( $ ) {
    $( '.variations_form' ).on( 'found_variation', function() {
        // здесь часто лежит вызов AJAX-синхронизации корзины
    } );
} );

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

Практические советы по безопасности и производительности

Любая правка, которая влияет на корзину и вариации, должна быть минимальной. Не отключайте весь AJAX WooCommerce ради одной лишней операции. Чем шире отключение, тем выше риск сломать оформление заказа, особенно если на сайте есть подписки, доставка по зонам, динамические купоны или сторонние платежные модули.

• Держите правку в отдельном мини-плагине или mu-plugin.
• Перед выкладкой проверьте сценарий гостя и авторизованного покупателя.
• Сравните поведение на мобильном и десктопе.
• После обновления WooCommerce повторно прогоняйте тест смены вариации.

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

Короткий чек-лист перед публикацией правки

• Найден точный источник AJAX-запроса.
• Правка ограничена нужной страницей или шаблоном.
• Проверены вариации, корзина и оформление заказа.
• Очищен кэш страницы и браузера.
• Код вынесен из обновляемой темы.

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