Як оптимізувати WooCommerce Cart Fragments без поломки кошика

Що таке WooCommerce Cart Fragments

Cart Fragments — це механізм WooCommerce для динамічного оновлення частин сторінки, пов’язаних із кошиком. Найчастіше йдеться про класичний віджет мінікошика: кількість товарів, перелік позицій і загальну суму.

Після додавання товару через AJAX WooCommerce може оновити ці елементи без повного перезавантаження сторінки. Для цього браузер звертається до спеціального endpoint і отримує HTML-фрагменти, які потрібно замінити в DOM.

Проблема виникає тоді, коли скрипт завантажується на сторінках, де немає мінікошика або іншого компонента, що використовує цей механізм. У такому разі сайт може виконувати періодичні запити без практичної користі для відвідувача.

• файл, який зазвичай відповідає за логіку, — `wc-cart-fragments.js`;
• типовий AJAX-запит — `?wc-ajax=get_refreshed_fragments`;
• основний кандидат на оптимізацію — сторінки без мінікошика та пов’язаних кастомних компонентів.

Чому не варто вимикати скрипт глобально

Глобальне видалення `wc-cart-fragments` може виглядати простим рішенням, але воно не враховує фактичну структуру магазину. На одній сторінці мінікошика може не бути у видимій частині шаблону, але він може відкриватися в мобільному меню, боковій панелі, header або popup.

Крім стандартного віджета WooCommerce, Cart Fragments іноді використовують теми, плагіни, кастомні шаблони та власні скрипти. Тому перед оптимізацією потрібно визначити, де саме кошик має оновлюватися динамічно.

Також не слід плутати Cart Fragments із самою функціональністю сторінок кошика та оформлення замовлення. Вимкнення конкретного JavaScript-файлу не повинно застосовуватися механічно до всіх сценаріїв WooCommerce.

• не видаляйте скрипт без перевірки мінікошика на десктопі та мобільних пристроях;
• враховуйте мінікошик у шапці, меню, drawer-панелі та popup;
• перевірте, чи не викликає його код теми або сторонній плагін.

Безпечне вибіркове вимкнення через functions.php

Практичний підхід — залишити Cart Fragments на сторінці кошика, сторінці оформлення замовлення та там, де активний стандартний віджет мінікошика. На інших сторінках скрипт можна прибрати з черги.

Код потрібно додати в дочірню тему або власний невеликий функціональний плагін. Не рекомендується вносити його безпосередньо у файли батьківської теми, оскільки оновлення теми може перезаписати зміни.

• зробіть резервну копію або підготуйте спосіб швидкого відкату;
• додавайте код у середовище, де його можна безпечно протестувати;
• пріоритет `100` допомагає виконати dequeue після більшості стандартних підключень скрипта.

add_action('wp_enqueue_scripts', function () {
    if (
        ! is_cart() &&
        ! is_checkout() &&
        ! is_active_widget(false, false, 'woocommerce_widget_cart', true)
    ) {
        wp_dequeue_script('wc-cart-fragments');
    }
}, 100);

Як працює ця перевірка

`is_cart()` і `is_checkout()` залишають скрипт на ключових сторінках магазину. Перевірка `is_active_widget()` визначає, чи активний стандартний віджет WooCommerce із ID `woocommerce_widget_cart` у зареєстрованій області віджетів.

Умова використовує логіку «і»: скрипт видаляється лише тоді, коли поточна сторінка не є кошиком, не є checkout і на ній не активний стандартний віджет мінікошика.

• якщо мінікошик реалізований блоком або власним шаблоном, ця перевірка може його не побачити;
• якщо тема підключає скрипт після виконання цього коду, може знадобитися інше рішення або пізніший хук;
• для нестандартного мінікошика краще спочатку з’ясувати його залежності.

Коли цей підхід потрібно змінити

Наведений приклад орієнтований на класичний віджет WooCommerce. Він не є універсальним визначенням усіх компонентів кошика. Сучасна тема може використовувати блоки WooCommerce, власний AJAX endpoint або JavaScript, який лише частково залежить від Cart Fragments.

Якщо після вимкнення зникає кількість товарів у шапці, не оновлюється сума або не працює відкриття мінікошика, скрипт потрібно повернути на відповідних сторінках. Для кастомного компонента можна залишити `wc-cart-fragments.js` або реалізувати окремий endpoint, який повертатиме лише потрібні дані.

Не варто додавати до винятків усі сторінки без аналізу. Краще визначити конкретні шаблони, де користувач взаємодіє з кошиком, і залишити функціональність саме там.

• перевірте документацію теми та плагіна, якщо мінікошик не є стандартним віджетом;
• не видаляйте залежності скрипта, якщо сторонній код очікує його наявності;
• для складних магазинів розгляньте умовне підключення власного JavaScript замість загального Cart Fragments.

Як протестувати сайт після змін

Тестування потрібно виконувати в режимі гостя та в новій сесії браузера. Кешовані cookies і попередньо завантажені скрипти можуть створити враження, що все працює, хоча реальний користувач побачить іншу поведінку.

Перевірте не лише головну сторінку, а й усі шаблони, де покупець може додавати товар або відкривати кошик.

• додайте товар у кошик із каталогу та зі сторінки товару;
• перевірте оновлення кількості, видалення товару та перехід до checkout;
• перевірте застосування та видалення купона;
• відкрийте мінікошик на десктопі й мобільному пристрої;
• перевірте товари з варіаціями, якщо магазин їх продає;
• переконайтеся, що після входу користувача або зміни валюти кошик не втрачає дані.

Перевірка в DevTools

Відкрийте Developer Tools браузера, перейдіть на вкладку Network і перезавантажте сторінку. У фільтрі запитів знайдіть `get_refreshed_fragments` або `wc-ajax`.

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

• перевірте також вкладку Console на JavaScript-помилки;
• переконайтеся, що файл `wc-cart-fragments.js` не потрібен іншому компоненту;
• тестуйте сторінки після очищення page cache, CDN-кешу та кешу браузера.

Типові помилки під час оптимізації

Найпоширеніша помилка — видалити `wc-cart-fragments` усюди, орієнтуючись лише на кілька зайвих запитів у Network. Якщо на сайті є мінікошик, проблема з продуктивністю вирішується не його поломкою, а точнішим визначенням умов завантаження.

Інша помилка — перевірити зміни лише для адміністратора. Авторизований адміністратор може бачити іншу версію сторінки через кеш, додаткові панелі або відмінну логіку теми. Основний сценарій потрібно тестувати як звичайний відвідувач.

Після зміни коду важливо очистити кеш сторінок. Інакше частина користувачів отримуватиме стару HTML-версію, а частина — нову, що ускладнить діагностику.

• не покладайтеся лише на оцінку PageSpeed без перевірки функціональності;
• не копіюйте код без аналізу кастомного header і мобільного меню;
• не редагуйте файли плагіна WooCommerce напряму;
• не вважайте відсутність одного AJAX-запиту доказом, що весь кошик працює коректно.