Last week, I was having a conversation with a fellow WordPress developer about improving page performance as it relates to JavaScript. Specifically, we were talking about if it makes sense to load JavaScript sources at the bottom of the page.

If you’ve done any client-side development for a moderate length of time, odds are strong that you’re well-aware that it’s considered a best practice to include JavaScript sources before the closing body tag rather than in the head element.

This is because it allows the browser to render the page more quickly without waiting for larger files to download (and JavaScript files are normally heavier than HTML documents because of their file size and the processing they do on the DOM).

There’s a lot that could be said with respect to this in terms of general web development, but in terms of WordPress, opting to enqueue your scripts at the bottom of the page versus the top of the page may require a bit more consideration.

WordPress Page Performance

For me, much of what this boils down to the context of the project of which I’m working. This can usually be reduced to one of two types regardless of if it is a theme or a plugin:

  1. Distributed Projects
  2. Non-distributed Projects

Distributed Projects are things like themes and plugins that will be used by a wide audience. Perhaps they are premium products, perhaps they are released for free on GitHub and/or in one of the WordPress repositories.

Regardless, the audience is wide, you don’t necessarily know who will be using your work, nor do you know the environment in which the code will be run.

Non-distributed projects are for projects in which you have total control over. Perhaps you’re building a custom theme that will only be used by one person, or perhaps you’re building a theme or a plugin (or even a suite of plugins) that will run on an intranet or a similar closed environment.

In this case, you know who the audience is and you have full control over everything that’s related to the environment in which your project is going to be executed.

The said environment is exactly what I use to determine how I’ll go about registering and enqueuing my JavaScript sources.

Distributed Projects

In the case of distributed projects, the way in which I go about registering and enqueuing JavaScript is pretty simple: I use all of the default values that the dependency API offers.

In the case of WordPress, this usually means that your scripts will be added to the page after jQuery but before the closing head tag (and likely somewhere in between other scripts).

Obviously, this has potential for slowing the page down, but when your code is going to be run alongside who-knows-how-many other people’s code and how dependencies are going to be added, it’s best to play it safe.

Case in point: I’ve tried to do the more performant option in more widely used projects before, but third-party code ended up doing their own thing and ultimately broke one of the dependencies I needed in my code.

In a perfect world, third-party code wouldn’t do this, and we’d have the fastest pages possible. But we don’t live in a perfect world so, you know, that’s now how it works.

And here’s a simple litmus test for WordPress projects: How many times have you been contacted about your work not working when the culprit is actually functionality introduced by a third-party?

Non-Distributed Projects

When you have total control over an environment, you can obviously build your work however you deem necessary.

Not only does this mean that you can setup your theme, plugin, or other aspects of the project to be added in whatever order you’d like, you can also go a full-on minification and concatenation of scripts such that everything is combined into a single file and then added to the page upon request.

Of course, you can make this even more advanced through the use of caching mechanisms and other things, but this is meant to be but one example.

Granted, there are still considerations that much be made:

  • What are you going to do when the core application is updated?
  • What happens when another plugin is introduced (if it is introduced) into the project?
  • …and so on

This is just to say that although non-distributed projects are subject to more control, they aren’t completely independent of outside factors. It’s just that you have more control as to how said factors play into how the overall project works.

Other Options

When you read a lot about best practices and other tips as it relates to programming, it’s easy to become dogmatic about how things ought to be versus how things are. By that, I mean it’s easy to know what yields the best performance, look at a project, and if it doesn’t do that, then it’s considered “bad programming.”

But I think experience makes us wiser. At least, I would hope it does.

When it comes to squeezing every single ounce of performance out of our web-based projects – be it sites, themes, applications, etc. – web developers generally have reasons for doing things the way that they, you know, do things and much of that is dictated by the environment in which their code is run.

That’s not only something we need to remember when looking at others code, but something that we need to remember when working on our own, as well. Though we know what might be the most performant thing to do, other factors contribute to decisions like this. As such, rather than getting legalistic about how things ought to be done, think in terms of practicality and why things are doing the way they are.

Odds are they have a rationale as to why they’ve done things a certain way, and we may be able to learn from it. Of course, this is more of a personal word of caution than anything else.

Regardless, this is my likely-simplistic approach to managing WordPress page performance as it relates to the various projects on which I work.