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:

WordPress Assets

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.
When it comes to programming, you make tradeoffs all the time – saying yes to one thing means saying no to something else – but is there has to be an optimal way to manage our WordPress assets?

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?