Stop Pushing JavaScript To The Footer

Advice on how to improve your page speed can be a double-edged sword. For one thing, a lot of people who write these articles don’t know what it’s like to actually run a medium-sized or large website with even a little bit of complexity. If they did, they wouldn’t be so confident in their recommendations. The truth is that there’s no “one size fits all” approach when it comes to making your pages load faster. While some improvements can be made for free, others come with tradeoffs.

To make matters worse, outdated advice persists. For example, I’d written earlier about how it was no longer a good idea to combine JS and CSS files. That advice made sense in an earlier time when browsers were unable to download multiple files in parallel beyond a certain point. But with HTTP/2, those restrictions were removed and now combining CSS or JS in this way is actively harmful. But still you see people giving the same advice over and over.

In the same way, another “page optimization” technique that needs to go is moving external JavaScript to the footer. In this article I’ll explain why it’s no longer relevant, and how it can hurt your site.

The Original Purpose of Moving JS to the Footer

The entire reason for moving external JS files to the footer, was that it allowed the page to load in peace and the reader could start interacting with the page while the browser downloaded and parsed the JavaScript files in the background. For a long time, this advice made a lot of sense. JavaScript blocks the page from rendering, and so if you put them all in the footer, the viewer wouldn’t have to wait for it before they could see something useful.

So the trend started, which continues to this day. Everyone is told that it’s always better to put JavaScript in the footer.

But there’s a problem with this – inline JavaScript.

Inline JavaScript Messes Things Up

Inline JavaScript ruins things for those attempting to speed up their site. It’s easy to tell people to simply export it all to an external file and load it separately, but it’s often not feasible. Sometimes it’s generated programmatically and there’s nothing you can do. Often, it’s part of a plugin that you don’t want to touch.

The reason why inline JS is problematic, is that it can reference a JS function that’s defined only later in the footer. Here’s a screenshot of what it looks like when a JS file is deferred to the footer with an inline JS reference to it:

In this screenshot, the “anchorific” function present in inline JS is only defined later on in an external JS file that’s loaded in the footer.

In short, moving JS to the footer can break dependencies.

Using “defer” Instead

Just as the ability of browsers to simultaneously download lots of files rendered the practice of combining them obsolete, the “defer” and to a lesser extent, the “async” attribute have rendered obsolete, the practice of placing external JS files in the footer.

Now you can use use “defer”, and the JavaScript won’t be downloaded or parsed until the page has finished rendering. With “defer”, it also preserves the order of the scripts, which means that the original intentions of whoever created the JS are honoured.

This is particularly relevant ever since I figured out how to defer inline JavaScript. If you use this awesome technique, then the browser will attempt to execute everything in exactly the way it appears. As a result, you want all the relevant functions to be defined before the inline script shows up on the page. And for that to happen, you need to defer the JavaScript when it’s defined in the header, and not the footer.

Page Optimization is Specific to Each Website

Just remember that there is no single or easy solution for fast page speeds. Often there need to be specific adjustments that are unique to your site, as well as tradeoffs that you need to decide how to live with.

And sometimes, it’s just not worth it. Sometimes a particular “optimization” will demand so much maintenance that you should just live with the penalty. But using “defer” for JavaScript and inline scripts in the right way often carries a great payoff. See if you can make it work!