На обычном магазине WooCommerce часто проблема не в самом плагине, а в том, что на странице оформления грузится лишнее: стили корзины, скрипты вариаций, блоки доставки, элементы, которые на checkout не используются. Если отключать всё подряд, легко сломать валидацию полей, обновление доставки или работу платёжного шлюза. Поэтому здесь нужен точечный подход: сначала понять, что именно подключается, потом снять только лишнее и проверить, что оформление заказа не деградировало.
Когда это действительно нужно
Сценарий обычно один и тот же: страница оформления открывается медленно, в отчёте браузера много запросов, а часть ресурсов явно относится к каталогу или карточке товара. На checkout это особенно заметно на мобильных устройствах и при подключённых нескольких платёжных модулях. Если задача — ускорить именно оформление заказа, а не весь сайт целиком, лучше работать не через глобальное отключение стилей WooCommerce, а через условия для конкретной страницы.
Диагностика: что именно грузится на checkout
Перед правкой кода откройте страницу оформления в браузере и посмотрите список CSS и JS. В Chrome это удобно делать через вкладку Network или через просмотр исходного кода страницы. Ищите файлы с именами, которые явно относятся к WooCommerce: woocommerce-layout.css, woocommerce-smallscreen.css, wc-cart-fragments, wc-add-to-cart, wc-single-product, selectWoo. Не все из них можно отключить без последствий, поэтому сначала определите, что реально используется на checkout.
Полезный практический тест: временно откройте checkout в режиме инкогнито, отключите кеширующие расширения браузера и сравните список запросов до и после правки. Если у вас есть staging-копия, проверяйте изменения только там.
Что можно отключать, а что лучше оставить
| Подход | Что даёт | Риск |
|---|---|---|
| Отключить всё WooCommerce на checkout | Максимально сокращает загрузку | Высокий: ломает поля, оплату, обновление доставки |
| Снять только неиспользуемые стили | Безопаснее, чем глобальное отключение | Нужно проверить визуальные состояния |
| Отключить отдельные скрипты по условию | Лучший баланс скорости и совместимости | Требует точной диагностики |
Пошаговое решение через functions.php или мини-плагин
Если тема или дочерняя тема уже используются в проекте, код можно добавить в functions.php. Для более аккуратной поддержки лучше вынести его в небольшой mu-plugin или отдельный мини-плагин. Ниже пример, который снимает часть ресурсов только на странице оформления заказа.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( ! function_exists( 'is_checkout' ) || ! is_checkout() || is_order_received_page() ) {
return;
}
// Стили, которые часто не нужны именно на checkout.
wp_dequeue_style( 'woocommerce-layout' );
wp_dequeue_style( 'woocommerce-smallscreen' );
wp_dequeue_style( 'woocommerce-general' );
// Скрипты, которые могут быть лишними в зависимости от темы и модулей.
wp_dequeue_script( 'wc-cart-fragments' );
wp_dequeue_script( 'wc-add-to-cart' );
wp_dequeue_script( 'wc-single-product' );
}, 100 );Этот пример нельзя считать универсальным. Например, wc-cart-fragments часто нужен, если в шапке есть мини-корзина, которая должна обновляться без перезагрузки. А woocommerce-general может влиять на базовую вёрстку формы. Поэтому после внедрения обязательно проверьте поведение формы и внешний вид.
Более безопасный вариант: отключать только то, что точно не используется
Если на checkout у вас нет мини-корзины, AJAX-обновления в шапке и сложных виджетов WooCommerce, можно начать с более мягкого набора. Обычно безопаснее убирать стили карточки товара и каталога, а не базовые стили оформления заказа.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( ! function_exists( 'is_checkout' ) || ! is_checkout() ) {
return;
}
wp_dequeue_style( 'woocommerce-layout' );
wp_dequeue_style( 'woocommerce-smallscreen' );
wp_dequeue_script( 'wc-single-product' );
}, 100 );Если после этого оформление заказа стало выглядеть нормально, но запросов всё ещё много, переходите к точечному анализу остальных подключений. Не пытайтесь убрать всё за один проход.
Как понять, что решение сработало
Проверка должна быть не только визуальной. Сверьте три вещи: список подключённых файлов, работу формы и сценарий оплаты. Откройте checkout, заполните обязательные поля, переключите способ доставки, смените платёжный метод и отправьте тестовый заказ. Если страница не падает, ошибки в консоли отсутствуют, а лишние CSS/JS действительно исчезли из исходника — задача решена.
- в консоли браузера нет ошибок JavaScript;
- форма заказа валидируется и отправляется;
- способы доставки и оплаты переключаются без зависаний;
- в исходном коде отсутствуют отключённые файлы;
- мини-корзина и счётчики в шапке не сломались, если они есть.
Для быстрой проверки можно открыть исходный код страницы и найти имя стиля или скрипта через поиск по странице. Если файл всё ещё присутствует, значит условие отключения не сработало или ресурс подключается не через стандартный enqueue.
Частые ошибки и как их исправить
Отключили скрипт, который нужен платёжному шлюзу
Некоторые модули оплаты используют собственные зависимости или опираются на стандартные скрипты WooCommerce. Если после правки перестала отправляться форма или не открывается модальное окно оплаты, верните отключённый скрипт и проверьте документацию конкретного шлюза. Особенно аккуратно работайте с библиотеками, которые подгружаются через плагины доставки и оплаты.
Сняли стили, а форма стала «сыпаться»
Это типичный эффект, когда убирают не только декоративные, но и базовые стили. В таком случае откатите woocommerce-general или другой подозрительный стиль и отключайте уже более узкие файлы. Если тема сильно завязана на стили WooCommerce, часть правок лучше перенести в дочернюю тему и проверить адаптивность отдельно.
Код не сработал, хотя ошибок нет
Частая причина — неправильный хук или слишком ранний приоритет. Для снятия ресурсов используйте wp_enqueue_scripts и достаточно высокий приоритет, чтобы сначала отработали подключения темы и плагинов. Ещё одна причина — кэш страницы: после изменения кода очистите серверный и браузерный кэш.
Практика безопасности и производительности
Если вы вносите такие правки на живом магазине, сначала сделайте резервную копию и проверьте сценарий на staging. Не редактируйте файлы плагина WooCommerce напрямую: обновление затрёт изменения. Для повторяемых задач удобнее держать отдельный мини-плагин с коротким набором отключений. Так проще откатить правку и понять, что именно влияет на checkout.
Если задача шире и вам нужно не только отключать ресурсы, но и чистить сайт от лишних подключений, дублей и мусорных элементов, в экосистеме WPShop для таких задач подходит Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpskins.ru&utm_medium=article&utm_campaign=kak-otklyuchit-otdelnye-skripty-i-stili-woocommerce-na-konkretnoj-stranitse-oformleniya. Но даже с плагином логика остаётся той же: сначала диагностика, потом точечное отключение, потом проверка заказа.
Мини-чек-лист перед публикацией изменений
- проверили, какие CSS и JS реально грузятся на checkout;
- отключили только ресурсы, которые не нужны в этом сценарии;
- протестировали форму заказа на тестовом заказе;
- проверили мобильную версию страницы;
- очистили кэш после изменений;
- убедились, что платёжный шлюз и доставка работают без ошибок.
Если после точечной оптимизации checkout стал легче, но функциональность не пострадала, значит вы выбрали правильный уровень вмешательства. В WooCommerce это почти всегда важнее, чем агрессивно «обрезать» всё лишнее одним махом.