A simple strategy to optimise asset delivery in WordPress

Published June 20, 2019
.* :☆゚

I was working on finishing and auditing a website today and realised, over the course of at least the past three+ years, I have been a lazy developer.

Either that or the checklist of to-dos and things to check have exponentially increased, which would actually not surprise me considering how much has changed in web development in the past few years.

Actually, the big thing I realised today was that I really need to use conditionals more. Code splitting may not be a thing for WordPress sites (at the moment) but I think I can definitely do better when it comes to assets delivery.


So, the typical WordPress way to serve scripts and styles is to register them in functions.php and enqueue them. You can place them in the header or footer too, manually, but the enqueue method is just a way easier method of managing all your assets in one place.

1function unicorn_tears_assets() {
2    wp_enqueue_script( 'gmaps', 'https://maps.googleapis.com/maps/api/js?key=YOUR_KEY_HERE', '', date("dmY"), true );  
3    wp_enqueue_style( 'unicorn-tears-styles', get_template_directory_uri() . '/dist/css/style.min.css', '', date("dmY")  );
4    wp_enqueue_script('unicorn-tears-scripts', get_template_directory_uri() . '/dist/js/script.min.js', ['jquery'], date("dmY"), true);
5}
6add_action( 'wp_enqueue_scripts', 'unicorn_tears_assets' );

Now, imagine doing all of this…but with conditionals.

1function unicorn_tears_assets() {
2    if(is_page('contact')) {
3        wp_enqueue_script( 'gmaps', 'https://maps.googleapis.com/maps/api/js?key=YOUR_KEY_HERE', '', date("dmY"), true );  
4    }
5
6    wp_enqueue_style( 'unicorn-tears-styles', get_template_directory_uri() . '/dist/css/style.min.css', '', date("dmY")  );
7    wp_enqueue_script('unicorn-tears-scripts', get_template_directory_uri() . '/dist/js/script.min.js', ['jquery'], date("dmY"), true);
8}
9add_action( 'wp_enqueue_scripts', 'unicorn_tears_assets' );

It may seem obvious to you now that you’ve seen how incredibly simple this strategy is, but to be completely honest, I’ve never bothered or really even thought to do this before. Why?

In the years I’ve worked on pre-existing sites, many of which have been created by teams of people….not one have I noticed at any point an effort to control scripts or styles apart from the use of a caching plugin which is common practice for heavy WordPress sites. I suppose that laziness has somewhat influenced my own lazy practices…

When you’re building a website from start to finish, the kB of dependencies can add up fast and what may seem like a small addition can amount to a far heavier site further down the road.


I recently worked on a number of edits to the State Buildings site, and they had an interesting approach to assets.

They de-registered all default scripts from WordPress like jQuery, and re-enqueued them using a cdn. This approach makes a lot of sense to me because a lot of users would already have common scripts like jQuery or Bootstrap cached on the browser, and a cdn may arguably have a faster load time than a shared server.

However, one noticeable flaw I noticed was that some scripts that weren’t even being used at all were being loaded on the page for no other reason than it may be used by the client “in the future”.

I am guilty of this logic too.

In the past, I have included things like slick, google maps, and isotope on almost every page of a website simply because…that was how it was always done.

I get that there are things like flexible content layouts and spaces for additional content “in the future”. But now, I’ve just come to realise it is a bit nonsensical to load all this stuff in the first place when the likelihood of it being actually used on a page is close to zero. Especially things like Google Maps which really doesn’t need to be loaded in on every page.


As I said before, I know this all sounds terribly obvious, but when you work with other people’s work for a while you get a feel for what is acceptable and what isn’t. For some reason, it became acceptable to throw all your dependencies on a page and hope for the best.

It’s no wonder WordPress gets such a bad rap for being bloated. In many ways, it is. But having dabbled in other CMS’s the past few months, it is still by far the simplest, easiest, and best solution for many use-cases too.

It would be nice if there was an easy way to automatically load scripts in whenever they are used, but that is not the way WordPress is structured. I don’t think it’s even really very necessary for most of the sites WordPress is used for. All I’m saying is, if you work with WordPress it’s actually not that hard to optimise the delivery of assets on a page.

WordPress does a lot of the heavy lifting for us. Conditionals are plentiful and incredibly simple to use. Things like is_page(), is_post_type_archive() or is_home() will do the job. But there’s way more where that came from.

I used to think concatenating everything was a good idea, but now I think you just need to ensure the scripts are necessary for the page itself, and weigh the pros and cons of allowing flexible content with dependencies such as isotope / slick etc. versus overall page weight.