Reducing DOM Size by Disabling WooCommerce Assets on Non-Shop Pages

WooCommerce enqueues its entire library of CSS and JavaScript on every page of your WordPress site by default.

This behavior forces the browser to download, parse, and execute files like woocommerce-layout.css and jquery.blockUI.min.js on blog posts or contact pages that require no commerce functionality. When these assets load on non-shop URLs, the total page weight increases by approximately 200KB or more. Such unnecessary overhead negatively impacts the First Contentful Paint (FCP) and the Speed Index. You can observe these requests in the Network tab of Chrome DevTools where they clutter the waterfall chart and delay the execution of critical theme scripts.

Eliminating these dormant assets reduces the total DOM size and improves the performance score within Google Lighthouse. You will notice a cleaner resource execution path and lower main-thread blocking time on mobile devices.

Standard WooCommerce installations rely on three primary stylesheets and a collection of AJAX-focused scripts to manage the store experience. The woocommerce-general stylesheet contains the bulk of the store’s visual identity, while woocommerce-layout and woocommerce-smallscreen handle the grid systems for desktop and mobile displays. Scripts such as wc-add-to-cart and flexslider are essential for product interactions but offer no value on a standard informational page. If the total page weight exceeds 1.5MB, these unused files represent a significant portion of preventable technical debt. Loading these assets on every request forces the browser’s rendering engine to process CSS rules that will never be applied to the current page content. This leads to wasted CPU cycles and higher battery consumption on mobile hardware.

Optimization begins by targeting the wp_enqueue_scripts hook with a high priority. WordPress processes the script queue based on the priority value assigned to each action. Setting a priority of 99 ensures your de-queueing logic executes after WooCommerce has registered its handles.

Script handles act as unique identifiers that WordPress uses to manage dependencies within the header and footer sections. If you attempt to dequeue a script before it is registered, the command will fail silently, leaving the asset in the loading queue. Using a high priority of 99 or even 999 is a standard practice to override plugin-level enqueues. You must maintain this priority to prevent the theme from re-adding the scripts later in the lifecycle. Many developers overlook this priority setting, leading to frustration when assets continue to appear in the source code despite the presence of removal functions. Testing the output in the browser’s view-source mode confirms if the dequeueing was successful.

Fixing Asset Bloat by Using Conditional Tags

Direct control over asset loading requires using WooCommerce conditional tags to identify the current page context.

/**
 * Dequeue WooCommerce styles and scripts on non-shop pages.
 */
function webroom_optimize_woocommerce_assets() {
    // Prevent fatal errors if WooCommerce is inactive
    if ( ! function_exists( 'is_woocommerce' ) ) {
        return;
    }

    // Define ecommerce-related pages
    $is_shop_page = is_woocommerce() || is_cart() || is_checkout() || is_account_page();

    if ( ! $is_shop_page ) {
        // Scripts to remove
        $scripts = array(
            'wc-add-to-cart',
            'wc-cart-fragments',
            'woocommerce',
            'jquery-blockui',
            'jquery-placeholder',
            'wc-add-to-cart-variation',
            'flexslider',
            'zoom',
            'photoswipe',
            'photoswipe-ui-default'
        );

        // Styles to remove
        $styles = array(
            'woocommerce-layout',
            'woocommerce-smallscreen',
            'woocommerce-general',
            'wc-block-style',
            'wc-block-vendors-style'
        );

        foreach ( $scripts as $script ) {
            wp_dequeue_script( $script );
        }

        foreach ( $styles as $style ) {
            wp_dequeue_style( $style );
        }
    }
}
add_action( 'wp_enqueue_scripts', 'webroom_optimize_woocommerce_assets', 99 );

The is_woocommerce() function returns true on the main shop archive, product categories, and individual product pages. You must also include is_cart(), is_checkout(), and is_account_page() to maintain the critical path for transactions. If you dequeue scripts on the checkout page, payment gateways like Stripe or PayPal will fail to initialize. This usually results in a 401 Unauthorized or 500 Internal Server Error during the AJAX checkout transaction. Maintaining this conditional logic ensures you do not break the customer journey while stripping unneeded bloat from the blog and homepage.

Properly identifying these pages is the only way to ensure the site remains functional. You achieve a leaner architecture without sacrificing the user experience on the storefront itself.

Modern WooCommerce updates have introduced additional bloat through the Block Editor integration and global styles. Stylesheets like wc-block-style.css and wc-block-vendors-style.css are now enqueued globally to support the Cart and Checkout blocks even if you use classic shortcodes. These files contribute to the “Reduce unused CSS” warning in performance audits, especially on mobile devices where bandwidth is limited. Removing these block styles requires targeting specific handles within your optimization function to ensure they do not block the main-thread execution. When the CSS specificity is too high, overriding these styles in your theme becomes a maintenance burden that complicates future design updates.

Reducing TTFB by Disabling Cart Fragments

The wc-cart-fragments.js script represents one of the most resource-intensive components in the WooCommerce ecosystem.

This script triggers an AJAX request to /?wc-ajax=get_refreshed_fragments on every single page load to update the mini-cart widget. On high-traffic servers, this constant polling bypasses most page caching mechanisms and puts a heavy load on the PHP workers and database. If the database query for cart fragments takes more than 0.5s, the entire page rendering process is delayed while waiting for the server response. You should only allow this script to run on pages where a dynamic cart total or a mini-cart widget is actually visible to the user. Many developers choose to replace this AJAX call with a static link or a custom local storage solution to preserve server resources.

Disabling cart fragments on non-shop pages prevents thousands of unnecessary hits to admin-ajax.php. Server resources are preserved for actual conversion events and checkout processing.

If you use a header-based mini-cart that appears on all pages, you will need to adjust the logic to keep wc-cart-fragments active. However, for sites where the cart is only accessible via a dedicated page, disabling this fragment request can reduce the Time to First Byte (TTFB) significantly. High-traffic stores often see a 20-30% reduction in server CPU usage after disabling global fragments. This change is particularly effective when combined with an Object Cache like Redis or Memcached. You must weigh the benefit of a dynamic cart count against the cost of a non-cacheable AJAX request on every page view.

Efficiency is the result of removing what is not used. You optimize the server and the client simultaneously by trimming the dependency tree.

Verifying Performance Gains with Network Audits

Verification of these changes requires a systematic approach using the browser developer tools.

Open the Network panel in Chrome and filter the results by “CSS” and “JS” while navigating a non-shop page. You should see a reduction in the total number of requests by 8 to 12 items depending on your active plugins. Total page size should drop significantly, often moving from 1.2MB to under 900KB on a standard installation. If the WooCommerce handles are still present, check the priority of your add_action call in functions.php. It is also vital to clear any server-side cache or CDN cache to see the updated HTML output. Persistence in testing ensures the optimization remains active after future plugin updates.

Lighthouse audits will reflect these changes in the “Opportunities” and “Diagnostics” sections. You will see improved scores for Largest Contentful Paint and Total Blocking Time.

Hand-coding these exclusions provides granular control that third-party optimization plugins often lack. Many plugins use a broad approach that can break functionality on specific custom post types or archive pages. By managing the queue manually, you reduce technical debt and gain a deeper understanding of your site’s asset architecture. Ensure you test the checkout process thoroughly after applying these changes to confirm that AJAX actions still function on the cart and checkout pages. If a 401 error occurs during checkout, verify that the wc-checkout script and its dependencies are properly enqueued. Consistent monitoring of the error logs will reveal any hidden conflicts created by the asset removal.

Related reading
Fixing Interaction to Next Paint (INP) delays in WooCommerce by optimizing JavaScript execution
WordPress script defer and async loading
Improving WordPress Speed by Implementing HTTP/3 Protocols