Office: 0194 386 4688 | Bob: 0740 332 1862

Dequeuing scripts and styles in WordPress

lbfl ConsultancyDequeue scriptsDequeuing scripts and styles in WordPress

Too many resources – CSS and js.

When it comes to software development for the web, we like many other developers, use the WordPress amongst others CMS platforms. Many choose the platform because it’s simple to deploy, however, this comes with several drawbacks. Using WordPress does present many challenges for web developers, principal amongst these are an over reliance on plugins.

Okay, we’ve all heard that “less is more” when it comes to crafting a WordPress website, and this remains to be true.

Plugins and more plugins…

More often than not, there’s a tendancy to select a theme only to find that there are features that we’d like to have that don’t come as part of the underlying theme. Experience shows that the majority of web developers simply continue to add plugins to provide the features that clients desire. There’s nothing wrong with this approach if you choose to buy an optimised plugin, sadly most use so called “freebies.” The result – slow performance, and badly created websites that rely on far too many CSS and javascript files.

The solution to these issues is to dequeue scripts and styles when not required, unfortunately, many don’t do this because they do not or can’t be bothered to do a little research.

The ultimate solution is to merge as many javascript and CSS files into one. The merging of javascript files is beyond the scope of this article, but this can be achieved with dramatic performance results!

Dequeue scripts.

To give you an idea of what the fuss is all about, we take a look at one of the most widely used and popular plugins Contact Form 7. We shalln’t bore you with the details but here’s an example of how to go about the task of dequeuing the plugin when it’s not required. The process used is the same for all plugins files.

Finding the $handle

$handle
(string) The slug of the script to dequeue.

This is perhaps the most difficult single thing to establish, although you can often find this within the page source using view page source from your browser. In the case of Contact Form 7 it handle is contact-form-7.

Once the handle has been established we can dequeue the CSS and javascript.

We’ll assume that you’ve created a child theme. You’ll now need to create a blank functions.php file within your child theme. This can be simply acheived using FTP software, but make sure that it’s place within the child theme, otherwise, once a theme is updated you’ll lose your changes!

Amending functions.php

Your functions.php file should look like this:

and we now need to add a custom function specifically aimed at dequeuing scripts. Here we go…

That’s it the contact form 7 script has been successfully dequeued throughout the entire website, however, we still need the script for any contact page, or any page that requires a contact form. So we now need to add extra lines to complete the contact form 7 function. We show complete code below.

So the script will only ever appear on the ‘Contact’ page or page ’12’ depending on how you’ve setup your Permalinks within WordPress.

Contact Form 7 additional information.

Recently the author of Contact Form 7 (Takayuki Miyoshi) released a new method for dequeuing contact form 7 version 7.3.9 or greater. Full details are found here – load javascript and stylesheet on when necessary.

Comments (2)

  1. Simon Greyson

    From a user perspective, isn’t it easier to use a plugin (WP Rocket, W3 Total Cache, WP Super Cache, Zen Cache, Cache Enabler and autoptimize) to name a few that will do this job quickly and easily? I’ve been using W3 Total Caache for years without issue.

    1. admin

      Well Simon, where do I start. In most cases this is ‘as you state’ the easiest method to speedup a lagging website. The trouble here is that most users rely on the free versions and simply don’t appreciate how difficult it can be to get them working correctly. I’ve seen various plugins deployed, some which offer mediocre page speed loading time improvements, others that simply break the code output. So yes in part, and no.

      I would always recommend a CDN for certain larger scale deployments, however, there’s no getting around the issue of making mistakes. Ordinarily, caching plugins concatinate javascript and CSS files (using various algorithms), trouble is that this often does cause conflicts in the javascript and CSS files. The result, a broken website which is often not noticable to the untrained eye, and there are a few glaring examples of this type of approach out there.

      For what it’s worth, we would always recommend using GZip in .htaccess as your starting point, then merge (concatinate) as many files as possible and then a CDN. A Caching programme should be the last port of call, most employ the use of CDN’s alongside deployment.