It’s Time for WordPress To Reduce Its Reliance On jQuery

This morning when I went to my site’s dashboard, I saw that the Automattic team had released the latest version of the Jetpack plugin – 8.4. As per my usual habit of never updating a plugin until at least 4 days had passed, I first went through the update notes to see if there were any security fixes that made it an urgent upgrade. As it turns out there were none, but, the following items caught my eye:

It looks like Jetpacks is trying to improve its performance by reducing its reliance on the jQuery library. This made me happy for many reasons, even though I personally only use the lazy loading functionality. The reason is that it might indicate a shifting away by WordPress from the ubiquitous jQuery library. Here’s why I think that’s a good thing.

jQuery is Everywhere

Around 75% of all website use jQuery. On an Internet where there are so many disparate platforms, it’s amazing that a single technology can come to dominate to completely in its niche. While it’s great that plugin developers can rely on the easy availability of jQuery on their websites, it poses a significant problem when it comes to page loading speeds.

You see, the very ubiquity of jQuery demands that you load it in the header! If you try and “defer” or “async” jQuery so that it loads later, you’ll quickly see that you end up breaking functionality on your site that depends on it. Even if your site works fine now, sooner or later you’re going to install a plugin or something that relies on jQuery being available and when it breaks, you’ll have no idea why it’s not working. Trust me – I’ve been there. Pulling your hair out wondering why a piece of Javascript doesn’t work, only to realize (much later) that the flaw was with the deferring of jQuery in the first place.

Render Blocking is a Problem

Now if this was only about download speeds, I wouldn’t mind too much. Bandwidth these days is expanding so fast, that the measly 33 KB or so of the jQuery download would be insignificant. In the worst-case scenario, you’re dealing with a laggy mobile connection in a place where Internet speeds reach dial-up levels of slowness. But fine, I’m willing to live with that edge case scenario.

The issue isn’t about download times though. It’s about the problem of parsing and rendering the content. As the jQuery library becomes more and more functional, its complexity increases, and browsers are very far from being uniformly fast at parsing it. The problem is compounded when we consider mobile phones that are far less powerful than desktop browsers, and which take an inordinate amount of time to render jQuery.

A CDN Is Only Partly Useful

Here at NameHero, we’ve explained before about how to properly load jQuery from a CDN, and it certainly helps – particularly if the client has already pre-fetched the DNS records and doesn’t have to make another call to resolve it. But it doesn’t solve the problem of jQuery taking so long to render at the beginning of every single page load.

Ultimately, I haven’t yet found a good solution to this problem. It might be that we’ll have to break up jQuery into smaller bits or something to achieve better results. Or better still, perhaps try and avoid using jQuery in the first place. The recent changes to the Jetpack plugin give me hope that developers are starting to move away from jQuery, and we’ll finally be able to do something to speed up our webpages without having a massive frontload that delays the showing of content!