A simple strategy to optimise asset delivery in WordPress

I was working on finishing and auditing a website today and realised, over the course of at least the past three+ years, that my scripts weren’t optimised for the context of the page at all.

WordPress comes with so many conditionals, but I hard hardly ever used them for conditionally enqueuing scripts and styles. I guess it’s time to fix that…

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.

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

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

<?php 
function unicorn_tears_assets() {
    if(is_page('contact')) {
        wp_enqueue_script( 'gmaps', 'https://maps.googleapis.com/maps/api/js?key=YOUR_KEY_HERE', '', date("dmY"), true );
    }

    wp_enqueue_style( 'unicorn-tears-styles', get_template_directory_uri() . '/dist/css/style.min.css', '', date("dmY")  );
    wp_enqueue_script('unicorn-tears-scripts', get_template_directory_uri() . '/dist/js/script.min.js', ['jquery'], date("dmY"), true);
}
add_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.

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 WordPress sites. I’m not trying to pass the blame here, but I learnt a lot of what I do from looking at other people’s code. I’m always trying to do better, and I’m only human so I can’t expect myself to know everything perfectly, but I’ve come to the conclusion this should be a thing to manually check for each site I work on.

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’m 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. What if the client in the future wants to put a map, or accordion on that page? It’s just easier to think the script will be available to serve that purpose.

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.

If clients need new functionality, it’s just a matter of patching it in. Better performance is always better than the sake of convenience potentially months or years down the line.

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. That has of course guided how I have been coding as well. Sometimes you have to question why you’re doing things instead of building on autopilot.

Conditionals like is_page(), is_post_type_archive() or is_home() work reliably, amongst others, and I feel like conditional loading should also be applied to custom plugins, many of which dump all assets onto each and every page.

I used to think concatenating all scripts was a cure-all, but now I think you just need to ensure the scripts are necessary for the page itself. Always check what scripts can be conditionally loaded in if you can, because scripts and styles can add up fast especially when plugins you may be using are often something you cannot completely control.