As a moderator on the WordPress Stack Exchange, I end up spending a lot of time on the site. I see lots of great questions, lots of not-so-great questions, and several you’ve-got-to-be-kidding-me questions. But the question I see the most often frustrates me:
How do I remove WordPress’ jQuery and use Google’s CDN version instead?
I have no trouble saying that, if you’re asking this question, you have no business building a website in the first place.
Why Use Google’s CDN?
The three most commonly cited reasons to dequeue WordPress’ bundled version of jQuery in favor of Googles are:
- Decreased Latency
- Increased Parallelism
- Better Caching
If you didn’t know any better, each of these arguments makes a lot of sense.
Decreased latency – the idea that jQuery will download faster from a properly-located CDN than your arbitrarily-located server – is a fallacy in today’s high-bandwidth world. jQuery by itself is 91KB when it’s minified (not counting any server-side data compression). Over a high-bandwidth connection, this downloads in less than half a second from just about anywhere (my server is located in a different country, yet jQuery still downloads in ~200ms for me). Consider the size of the rest of your site – ~300k of scripts, ~100k of content, ~1-2m of images – and the footprint left by jQuery is inconsequential.
Increased parallelism - the fact that a browser can only download so many resources at a time – is a valid concern. But consider that nearly all of your calls to jQuery are wrapped in some kind of document-ready event and there’s an easy work-around: load jQuery in the footer rather than the header. Your content will load first and the user experience is not impacted by waiting a fraction of a second before your fancy animations fire.
Better caching - the idea that Google’s servers will be configured more efficiently than yours – is bogus. If you’re counting on Google’s well-configured CDN to save your site from a poorly set-up server environment, then you have absolutely no business building or hosting websites. Your server should be fully capable of setting the appropriate cache control headers on script files and, if not, you should contract with someone who know what they’re doing to set it up.
Why NOT Use Google’s CDN?
WordPress takes great care to make sure its bundled libraries are fully compatible with other bundled scripts. jQuery is loaded in “no conflict” mode to prevent any potential script collisions over the $ variable in the global namespace. As of version 3.6, WordPress will be shipping with version 1.9 of jQuery – which removes several deprecated APIs like .live(). To prevent things from breaking, WordPress automatically loads jQuery Migrate, a plugin that adds these removed APIs back to the system, but alerts you in the browser console of their deprecation.
If you load jQuery 1.9 yourself from Google’s CDN, you’ll miss out on the jQuery Migrate plugin and end up breaking several themes and plugins that depend on these deprecated APIs. I still find .live() even in new code, so the chances of it littering your site and breaking things when you start swapping out libraries are extremely high.
Also, WordPress is taking steps to prevent you from dequeueing jQuery on the back end at all. You’ll still be able to override it for the front-end if you absolutely need to, but if you ever find such a need, stop and ask yourself why before heading down that path. Chances are good that your “need” is really just a patch over a deeper problem you don’t fully understand.
Why is this the Wrong Question?
I recently build a project for a client that worked flawlessly with jQuery 1.9, but broke with any lesser version. My first (wrong) instinct was to remove the bundled jQuery and bump the loaded version to 1.9 instead. It would have worked, but it wouldn’t really have fixed the issue.
Instead, I doubled down and walked back through the code instead. I was using a lot of non-jQuery code in my system, and it turned out I had a typo. With older versions of jQuery, my typo resulted in plain, non-functional code. With the newer version of jQuery, my typo accidentally invoked a jQuery method where I was attempting to invoke a native JavaScript method.
The fix was to correct the typo, making my code work 100% independent of jQuery.
I spent a few hours looking for the best way to override the bundled version of jQuery, but that was the wrong approach. The right approach was to ask an entirely different question: what will a different version of jQuery give me that I don’t have right now? The answer to that question: nothing.
Moving On
The only reason you should ever enqueue Google’s version of jQuery is if you are building a project for Google and they ask you to. A properly configured server will cache just as effectively, completely eliminating any concerns regarding cache duration or script latency. Moving your scripts to the right part of the page – the bottom – will further allay concerns about load time and user experience.
Nine times out of ten, “how do I replace the bundled version of jQuery” is the wrong question. It’s a question most frequently asked by newer web developers and it betrays your inexperience. Instead, take some extra time to learn to do things the right way and your site will be just as fast. Go for a fully-thought-out solution, not just a quick fix.
So if serving jQuery from your own server is so much superior, naturally I should get it much faster form your site, right? Let’s compare fetching minimized jQuery 1.83 for me between you and Google.
Your site: Connect: 0,234s TTFB: 0,405s Total time: 0,904s
Google: Connect: 0,062s TTFB: 0,109s Total time: 0,265s
Google outperforms your site 3x for me.
On other point – replacing jQuery with CDN version does not mean replacing it with different version, it is trivial to look up WP’s version and load same one.
Didn’t say it was faster. I said it was unnecessary. Now that you’ve got it, it’s cached and you don’t need to get it again.
Yes, you did and in strong words: “the idea that jQuery will download faster from a properly-located CDN than your arbitrarily-located server – is a fallacy”
^^yep. Also consider this: Google has a CDN with exit nodes all over the world. When you call jQuery from their service, it’s pulled from the closest place. Furthermore, as you already stated, once you pull it, it’s cached you don’t need to get it again. Chances are, it’s ALREADY in their cache, from some other site.
I run a blog network. When users visit my sites and wordpress spits out the url to jquery it’s relative. I want all my sites to use jQuery from the same place. If it wasn’t on Google, I would dequeue it just to load my own instead. It makes no sense for a social network of blogs to load the same file from hundreds of urls.
You’re half right that people who build websites should be able to turn on cache-control headers, but on a distributed geographic scale like google, thousands and thousands of sites already using Google’s jQuery as a CDN, increasing chances it’s already in their browser, I am thinking more and more this is a troll article to stir the pot.
So because you “Stuck to your guns” and found a typo in your own script should have ZERO weight on effecting someone’s choice of using Google of WordPress’s jQuery since you can choose which version you want to load from Google.
Don’t forget that the default jQuery in WP is loaded in no conflict mode. The jQuery loaded from Google is NOT in no conflict mode, which is why a huge number of conflicts happen when this is done.
@Pippin
I am running Jquery from Google like this.
<script type='text/javascript'>try{jQuery.noConflict();}catch(e){};</script>
Is this method of noConflict not adequate? I ask because I really don’t know.
I’m not getting any errors, and btw, it’s the 1.9 version.
I still feel good with Google CDN. Actually, in the post, Eric says the big disadvantage of Google CDN is the version 1.9 of jQuery (which will included in WP 3.6). So, we’ll see that happen. But until now, loading from Google CDN is still better and I don’t see any problem with it.
“Better” is highly subjective. Better how? Better in terms of load time? (Inconsequential after the first visit since jQ will be cached.) Better in terms of script load concurrency? (Non-issue if you load scripts in the footer.) Loading jQuery via Google’s CDN is solving problems that few sites actually have or need to address. It’s a habit most developers pick up from reading a hot blog post explaining why Google’s libraries are so cool … but better? I ask again: better how?
In Yahoo research visits with cold cache accounted for 40-60% visitors and 20% pageviews http://yuiblog.com/blog/2007/01/04/performance-research-part-2/
Caching is not silver bullet and non-cached load performance matters plenty.
I agree with Rarst. The only reason is website performance, and Yahoo answers that question very well. See here: http://developer.yahoo.com/performance/rules.html#cdn. If you don’t use a CDN like free Google CDN, you won’t get > 96 by Yslow or PageSpeed. Of course everything will be different if you use your own CDN
Quite frankly, if everything else about your site is configured so well that the only way to increase performance is to use a CDN – and if your traffic/audience justifies/demands using a CDN – you should really be using your own CDN for static content (images, styles, JS) anyway.
The point of using a CDN is not only to have an expire date far in the future instead it’s about the “cross-site caching” effect (as the cited article states). There’s a good chance that your visitor has already downloaded jQuery before.
And yes, decreased latency is important for mobile devices with limited bandwidth.
If a hosted version is good fit for your site depends and there’s no general answer to this question neither it does “betray your inexperience”.
If you’re targeting mobile devices with limited bandwidth, I question why you’re using large, somewhat slow libraries like jQuery in the first place.
Another reason to use a cdn is that it allows for simultaneous downloads, where as browsers tend to only load one script at a time from tyre same server. At least that was the car back in the day…
If you’re loading all of your scripts in the header (i.e. before regular page content) I would agree. However, you shouldn’t be loading your scripts there, jQuery in particular, because you’re likely not using any of them until after the document’s ready event fires. Load your scripts in the footer, then content will always load first and your users don’t have to wait for scripts to load to see content. This alleviates much of the concurrent download concern as well since the reason it’s an issue in the first place is that it blocks regular content from getting to the user.
My phone seems inclined to use car references. *the *case
I’m 100% with you on this one Eric. I can’t tell you how many times a plugin or theme was messed up simply because someone had denqued jQuery. Idk y so many people within the WP community do this. It’s something unique to WP users. Leave well enough alone and let WP manage itself!
The actual bug tracker is only talking about the admin area, not the front of the site. As a side effect it can deregister jquery in the admin.
This is moot point anyway to talk about. Move along folks.
The Trac ticket only addresses the admin area, yes. That’s to say the admin will be the only place you can’t replace jQuery with your own custom version. My point is that you shouldn’t anywhere else, either.
With everything you’ve said im more inclined to think that’s more difficult to use google cdn so really only those who know what they are doing and the consequences should attempt replacing it. I do however agree that a theme or plugin not dedicated to replacing wordpress’ s jquery should be used. But I replace it intentionally across my network as a muplugin and have it on my own cdn. You’re still advising against this? 500,000 pageviews across 200 networked domains (blog farm) it only makes sense that a sing user going from 1 blog to 25 others in my network would pull a duplicate file 25 times through different dns requests. I don’t understand your absolutionistic view on this.
Your situation – a large network that justifies using its own CDN – is somewhat rare. Yours is actually a situation where I would recommend using a CDN but, like you’re already doing, to use your own CDN rather than outsource to Google. If a site has enough traffic to justify a CDN, you should be using it for static images, styles, and other scripts as well. From the sounds of things, you already are. Kudos!
My post was directed more at people who are swapping out WP’s jQuery for Google’s without really understanding why. The WP.org forums and WP Stack Exchange are littered with “how do I” posts from new developers who read an article somewhere that encouraged using Google’s CDN but didn’t explain why.
If a site doesn’t need a CDN, don’t force one in. If your site does need a CDN, then set up a proper one. Offloading one script library to Google won’t magically make a site better.
Well, actually with my CDN plugin I made (Because all other CDN plugins suck) I have two lines of enqueue my own jQuery, one with Google and One with mine, and I’ve been testing back and fourth. Google’s is definitely faster than mine. Most likely due to precaching in peoples browser and the fact that their datacenters are everywhere. I’ve only found one person who had blocked Google that actually complained about not being able to load jquery (Page looked messed up, they didn’t know why) Changing to my CDN fixed it for them.
My CDN/Google’s CDN not enough of a difference to worry about. Well, my CDN is behind CloudFlare, and it’s still not as fast as Google’s either way.
But it’s good to know that you’re not a proponent of actually adding in “blocking the ability to dequeue Jquery” in the wordpress tracker. That’s a useless enhancement as people will just do stupider things to include Google’s jQuery if WordPress actually did that.
I shudder at the thought of “Developers” filtering the buffered html output so they can string replace the include jQuery string. <|:(
(Dunce Hat)
Why not just call .noConflict() and enqueue jQuery Migrate after enqueueing jQuery 1.9.1?
Seems that the only difference between the WordPress version of jQuery is that jQuery.noConflict(); is called at the end.
Why reinvent the wheel? Event if you were to do that, you’ll just have to keep doing it when WordPress updates. The entire reason for using an application framework (WP) is to avoid the need to do such things in the first place.
Nice article, except for the snobbery. I guess that’s just common with StackExchange folks: get a little knowledge, then start talking down to the rest of the world :p
Everyone is entitled to their own opinion. This just happens to be mine. If you see that as “snobbish” then, like me, you are entitled to that opinion.