Prevent Loading WooCommerce’s JS & CSS Files & Improve Loading Time

Building a digital store using WooCommerce is not rocket science. You can do it yourself or get help from many tutorials discussing WooCommerce on Savvy’s blog and across the web in general. However, in order to succeed and provide a good user experience for your store, a significant part of that user experience is the loading time and responsiveness of the store.

Your online store (your business, in other words) can stumble and fail if the user experience it offers is not up to par. In this post, we’ll describe one of many steps to improve the loading time of WooCommerce-powered websites.

The action we’re discussing in this case is how to remove, or rather, how to prevent WooCommerce from loading unnecessary JavaScript and CSS files on every single page of your website, but only on the pages where WooCommerce is active.

Several things to consider before proceeding:

• Are there elements on your site that depend on those WooCommerce scripts and are essential for WooCommerce pages itself? (Payment page, shopping cart, product pages, etc.). Elements like the cart icon in the header, or any widget in the site’s sidebar.
• Do you have a development environment? It’s highly recommended to test changes locally (on your personal computer) or in a development environment if you have one.
• You should know what you’re doing and be comfortable with code.
• Always make sure you have a proper backup of your site before you start tinkering with code.

Removing Default Loaded Files by WooCommerce

By default, WooCommerce loads three CSS files and five JavaScript files. These files are:

<!--CSS Files-->
<link  href='.../plugins/woocommerce/assets/css/woocommerce-layout.css' rel='stylesheet' type='text/css' />
<link  href='.../plugins/woocommerce/assets/css/woocommerce-smallscreen.css' rel='stylesheet' type='text/css' />
<link  href='.../plugins/woocommerce/assets/css/woocommerce.css' rel='stylesheet' type='text/css' />

<!--Javascript Files-->
<script src='.../plugins/woocommerce/assets/js/jquery-blockui/jquery.blockUI.min.js'></script>
<script src='.../plugins/woocommerce/assets/js/frontend/add-to-cart.min.js'></script>
<script src='.../plugins/woocommerce/assets/js/js-cookie/js.cookie.min.js'></script>
<script src='.../plugins/woocommerce/assets/js/frontend/woocommerce.min.js'></script>
<script src='.../plugins/woocommerce/assets/js/frontend/cart-fragments.min.js'></script>

The CSS file names will end with ‘rtl’ if your WooCommerce store is in Hebrew.

It’s quite obvious that you don’t need the script responsible for adding products to the cart (add-to-cart.min.js) to be loaded on the contact page, right? And surely, the CSS file responsible for styling the store layout (woocommerce-layout.css) shouldn’t be loaded on your blog posts, correct?

You can inspect the source code of any page on your site and see if these files are being loaded. Of course, if your site has already undergone optimization for speed, you might not see these files at all, except on WooCommerce pages where they’re necessary.

You want these files to be loaded only on relevant store pages, such as product pages, checkout page, shopping cart page, etc. So, in order to achieve that and remove unnecessary JS and CSS files from non-WooCommerce pages, add the following code to your functions.php file:

<?php
//* Enqueue scripts and styles

function savvy_remove_woocommerce_css_js() {

    // Check if WooCommerce is active
    if( function_exists( 'is_woocommerce' ) ){

        // Check if we are on a WooCommerce page
        if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) {

            ## Dequeue WooCommerce styles
            wp_dequeue_style('woocommerce-layout');
            wp_dequeue_style('woocommerce-general');
            wp_dequeue_style('woocommerce-smallscreen');

            ## Dequeue WooCommerce scripts
            wp_dequeue_script('wc-cart-fragments');
            wp_dequeue_script('woocommerce');
            wp_dequeue_script('wc-add-to-cart');

            wp_deregister_script( 'jquery-blockui' );
            wp_dequeue_script( 'jquery-blockui' );

            wp_deregister_script( 'js-cookie' );
            wp_dequeue_script( 'js-cookie' );

        }
    }
}
add_action( 'wp_enqueue_scripts', 'savvy_remove_woocommerce_css_js' );

Pay attention to the conditional tags in line 10. If you need to load these scripts on pages other than WooCommerce pages, you can adjust these conditions accordingly.

If you have any questions about this topic, feel free to ask in the comments, and I promise to respond promptly.

Appendix A

This solution will work perfectly for both CSS and JavaScript files. However, it’s worth mentioning that when it comes to WooCommerce’s loaded CSS files, you can remove them entirely from all pages of the site, including WooCommerce pages, using the following filter:

// Remove all the stylesheets in one line
add_filter( 'woocommerce_enqueue_styles', '__return_empty_array' );

Alternatively, if you want to remove a specific CSS file, you can do it like this:

// Remove each style one by one
function sv_dequeue_styles( $enqueue_styles ) {
    unset( $enqueue_styles['woocommerce-general'] );	    // Remove the gloss
    unset( $enqueue_styles['woocommerce-layout'] );		    // Remove the layout
    unset( $enqueue_styles['woocommerce-smallscreen'] );	// Remove the smallscreen optimization
    return $enqueue_styles;
}
add_filter( 'woocommerce_enqueue_styles', 'sv_dequeue_styles' );

Appendix A is extensively discussed in the post How to Remove Default Loaded CSS in WooCommerce.

To Sum Up

Depending on how you’re using WooCommerce, it might be advisable to optimize as described in this post. Personally, I’m a fan of proper user experiences in general and site speed in particular, so if an added plugin is loading its scripts globally, it could annoy me.

I like the code of the sites I work on to be tidy and clean whenever possible, but I also understand why WooCommerce loads these files globally. They’re meant to cover most scenarios users encounter, and if they didn’t, their technical support requests would skyrocket by thousands of percent.