When it comes to developing web sites and web applications, there are two things that developers always consider as it relates to the project’s assets and its performance:
- The number of HTTP requests a page requires
- Loading all of the assets versus only what we need for a page (also known as YAGNI or You ain’t gonna need it.)
This is an obvious problem as we have tools like Head.js and Sprockets for managing this issue, and then we have customizers for larger utilities like Bootstrap that allow us to customize our builds.
Managing WordPress assets is becoming incredibly more relevant especially as frameworks, themes, and plugins become more powerful, and as people begin to build full applications on top of WordPress.
The Problem of WordPress Assets
I’ve previously mentioned that I’m a huge fan of CodeKit, and I’ve shared how I organize my WordPress assets in both my plugins and theme files for CodeKit-based development.
Once I’m further into development, I’ve ultimately generated a set a minified JavaScript source files:
And I’ve typically been of the mindset that files should only be loaded when their needed. But when you follow this approach, it results in functions.php file looking something like this:
if( 'add individual' == strtolower( get_the_title() ) ) {
wp_register_script( 'individuals-create', get_template_directory_uri() . '/js/individuals-create.min.js', array( 'bootstrap' ) );
wp_enqueue_script( 'individuals-create' );
} // end if
if( 'update individual' == strtolower( get_the_title() ) ) {
wp_register_script( 'individuals-update', get_template_directory_uri() . '/js/individuals-update.min.js', array( 'bootstrap' ) );
wp_enqueue_script( 'individuals-update' );
} // end if
if( 'view individuals' == strtolower( get_the_title() ) ) {
wp_register_script( 'individuals-all', get_template_directory_uri() . '/js/individuals-all.min.js', array( 'bootstrap' ) );
wp_enqueue_script( 'individuals-all' );
} // end if
This example doesn’t even take into account localized themes, admin screens where we have access to the current screen, and more.
Even more so, this is just the JavaScript source – I’ve not even touched on stylesheets.
Obviously, it’s a bit of a pain to manage and it’s creating a lot of conditional code at the expense of minimizing HTTP requests. I don’t particularly like this approach, but I tend to lean in the direction of loading only what you need.
But on the other hand…
Without writing some type of plugin to manage a project’s assets and serve a single file consisting only of what’s needed for the given page (which also comes at the expense of doing work on the server), I see two options and they are the same that I’ve laid out at the beginning of the post:
- We load only what’s needed. This may include multiple HTTP requests, but the overall file size is relatively small.
- We create one master stylesheet and one master JavaScript file to reduce the total number of requests to two, but this overall file size is larger and includes things the user won’t require at the moment.
What’s a developer to do?
So I’m genuinely curious how you guys handle this situation. I’m interested in everything you guys have tried and are using (or have used), what works, and what hasn’t.
This can include a complex caching setup with assets minified, compressed, and reduced to single files served from a CDN, to a smaller solution where no caching is used and you guys are doing something else on your smaller, less complicated server.
How do you guys manage this dilemma?
In the admin at least, you can easily restrict scripts/styles by checking the hook of the current page. Whenever you use add_submenu_page() (or any of the related helper functions), there is a unique hook registered for your page, and this hook is passed as a parameter to your function connected to the admin_enqueue_scripts action.
Totally – and that’s what I normally do in the admin, but it still creates this situation of writing individual LESS files for each page then a conditional for each when I wonder if having a single dashboard.less file imported on each admin page isn’t just a better way to go.
Still not sure on this yet.
Ultimately its impossible to know what a user is going to do when they get to your site. You can use Google Analytics, and view user flow charts to predict what is going to happen, but that’s not 100%.
For sites I build I use one master CSS and JS file and try to keep them as small as possible. After the initial page load (most likely the homepage), the user will have cached the assets, and then each subsequent page load will be much faster. In my opinion fewer HTTP requests is typically better than smaller file sizes.
Nice topic though, might be worth further investigation.
Yes – you’re right, it’s impossible know but I still think the problem stands in that are we okay with more HTTP requests and less file size, or the opposite?
For most, many won’t care especially those in high bandwidth areas, but as our applications become more complex, this becomes more of a problem.
But I like your advice regarding one master file and one master JavaScript file. That’s exactly what I was after – finding out how many of the other professional guys are doing it, too. I’m at a place where I’m beginning to lean in that direction, but only if others are noticing more success (where success = performances + maintainability) with it than not, you know?
As has been mentioned, there are tradeoffs, but I’m in the camp that prefers to combine custom scripts and styles into a single master file. Additional HTTP requests are typically going to be more expensive than a few extra kilobytes, but if a script is fairly large and serves a particular purpose, I might break it out into a separate file for maintainability or to isolate it to the requests that need it. My process could certainly be optimized, but I don’t think small gains are going to be worth the additional complexity and maintenance hassles for most projects.
The WordPress admin does serve as an interesting example — most scripts are combined and compressed at run time (not sure if any caching is done) through the file located at /wp-admin/load-scripts.php. The admin won’t receive as much traffic as the front end, so the server overhead should be more than worth the gains on the client side. I believe there are plugins that should help do the same thing on the front end, but they should cache the output to minimize the server overhead. Or the scripts could be combined in a build/deploy routine.
As an aside, I’m not sure if the snippet where you’re registering and enqueueing scripts is just an example, but you can eliminate the call to wp_register_script() in that particular case — wp_enqueue_script() accepts the same parameters. I typically only register scripts if they need to be selectively enqueued in different places throughout a theme.