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.
you just have to do it once yo can put the code on a theme or a child theme
You just have to do it once … then again every time either jQuery or WordPress release an update.
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.
Yes, I also found the article helpful, but I tend to agree with original commenter. Using phrases like “..if you’re asking this question, you have no business building a website in the first place.”, especially regarding a topic that sparked as much discussion and debate as this one, comes off a little aggressive.
The entire point of that line was to be aggressive.
You have no business giving people advice. Jesus christ you have no idea what you’re talking about. You make shitty, uneducated reasoning and then backtrack all over it when people have called you out in the comments.
You’re certainly entitled to your opinion, just as you are entitled to not read my site if you disagree with mine. You’re also more than welcome to write a rebuttal on your own site – moreso than you are to deface mine with profanity and insults.
Lame
http://f.cl.ly/items/2L2m1k29421c1Q410v1A/jorbin_gonna_hate.jpg
Eric, I’m seeing jQuery 1.10.2 when I look at wp-includes/js/jquery/jquery.js
Did the version shift after you wrote this or did I get a different build?
I downloaded from wordpress.org
Version 1.10 came out between this post and the actual release of WordPress 3.6, so it was bumped up in core as well. If you were to try to build a theme/plugin compatible with 3.6 and bundled jQuery with it back in February, it would be broken today. Just another reason to not unenqueue WP’s jQuery.
Hey Eric. Your post is showing up as 1st on google on search string “wordpress remove jquery point to google” – would be helpfull if you add the how to remove jquery instructions, for future visitors, not for me. Furthermore I would like to say that I have read your post, I have full understanding over what you`ve written, and I do not agree with you on any of the points. Using Google’s CDN is better from speed P.O.V., also cache most certainly allready took place from another site (not coded by you). And other arguments like deprecated functions are not valid (heck, live() in 2013?). Your advice is good for people who played with wp for less than 1 year
Considering the entire point of my article is that developers should not be removing jQuery to set up their own version, there would be zero benefit to including instructions on doing the very thing I’m telling readers not to do.
You’re more than welcome to disagree with my argument.
Not sure why you continue to stand by this untenable position Eric. What is your motivation? It just doesn’t make sense to me. For all the reasons stated here, caching, speed of delivery and more, its patently obvious that yours is a losing position.
I disagree that developers who are using the CDN hosted copy of jQuery are “setting up their own version”. Quite the contrary, they are embracing what is widely held as a “best practice” approach to serving jQuery to their users.
It could be argued that it is you who is “setting up your own version”.
If you would have delivered this message with a bit of humility, it may have been better taken as an objective point of view.
Not sure why you (and others) continue to reject it under the guise of “widely held” “best practices.” Just because something is used often, or termed a ‘best practice’ doesn’t make it so. Comic Sans and Papyrus are widely used fonts, but both are universally despised by most of the development community. A best practice is merely the practice most people accept as being “best” and, honestly, the majority of people asking either how to replace WordPress’ jQuery with a Google-hosted one are too inexperienced to qualify “best” for coding practices.
Take a minute to look around the WordPress community, and you’ll see I’m not the only dev holding this position. There is even an older plugin available to force a site not to use Google’s jQuery as it breaks certain features, plugins, and compatibility issues. The core team even went so far as to forcibly prevent developers from dequeueing jQuery in the WordPress admin to prevent things from breaking.
Are there situations where a site would benefit from using a CDN (either Google’s or another) for loading jQuery? Absolutely. Does the fact that many developers use this technique blindly make it a reliable “best practice?” Not at all. Should developers be using this technique in their own sites? That depends 100% on their site, the developer, and the problem they’re trying to solve.
Eric isnt the only who holds this view:
http://pippinsplugins.com/why-loading-your-own-jquery-is-irresponsible/
However, My view is that ‘it depends’. I just had to deal with this issue and switched from the embedded jquery to google’s.
i did it for performance reasons. I want the cold-cache experience to be fast. My site (along with others of mine) runs on a single VPS. Cheap for multiple sites. I don’t want to pay for any cloud CDN or deal with the complexity of managing uploads to it and training users/publishers.
I want a min version and the fact that it comes from a different domain than my server means the browser can parallelize it. (My site has a ton of images that the client insists on)
Regarding the conflict issue, I have to say that WP makes it hard to deal with jQuery. I don’t see options (easily found) to send down the min version.
The noConflict mode really creates more hassles than it saves you from IMHO. Working with jquery plugins, and custom code is painful (I want to use $!!)
I know there are workarounds for these, but it seems like in 2013, the default should not be no-conflict.
jQuery is SO popular (vs prototype and other potentially conflicting libraries) that most people only know $ from jQuery.
i’d rather WP set defaults assuming this and give you an option to go the noConflict route if you have problems.
if the min option and the noConflict were easily solved from the UI, I probably would have just lived with the WP one.
However, when you search online for solutions, the “use google jquery” is MUCH easier to find than working around the above issues.
The path of least resistance is to just use google.
my 0.02
You can also load the jquery-migrate this is my solution to that particular problem:
wp_deregister_script( 'jquery' );
wp_register_script( 'jquery', 'http://code.jquery.com/jquery-1.10.2.min.js');
wp_enqueue_script( 'jquery' );
wp_deregister_script( 'jquery-migrate' );
wp_register_script( 'jquery-migrate', 'http://code.jquery.com/jquery-migrate-1.2.1.min.js');
wp_enqueue_script( 'jquery-migrate' );
}
add_action('wp_enqueue_scripts', 'add_scripts');
You’re missing the point entirely. Once you remove the core-bundled version of jQuery and load your own, you will not be able to use updated versions of jQuery when they become a part of core. You are effectively forking the project by way of an action – while this is allowable, it’s not recommended.
No, We’re not missing the point. Speaking for myself at least, I understand that by explicitly using google’s jquery, I am managing the version of jquery my site uses rather than letting WP handle that.
Sometimes I don’t want jquery versions changed out from under me. Instead I want to control when it gets updated.
Overall, I DO think the recommendations you make are good ones for a large set of scenarios.
However, what I find frustrating is that you don’t seem to have any room in your mind for alternatives where people’s individual circumstances make different tradeoffs a better approach for their site. It doesn’t mean we ‘have no business hosting a site’…
The articles on this website are written for a general audience. There are always exceptions to broad statements, and you could very well be one of those exceptions. However, please note a few things about your stated use case and why I would still disagree that a Google-hosted option is the best fit.
You state you want to control the version of jQuery and not defer that control to a 3rd party – yet you still are electing to use a 3rd party’s tool to serve your JavaScript. True, Google hasn’t failed to deliver the correct version of jQuery in response to requests, but you’re still placing your site’s performance in the hands of an organization over which you yield zero control.
If you are one of the few who’s site performance will be significantly improved by using CDN-hosted jQuery, then I would argue you need a CDN of your own. There are likely other benefits to moving your other scripts (and styles) to such a CDN, and you won’t be giving up control over to another service that may or may not serve the right content – or which might decide to stop serving content altogether.
We are placing whole nation’s fate in hands of the President with no futher control, why can’t we let the king of the internet serve that javascript ?
Most of us alread depend also on their analytics.js and it’s fine.
My hosting is far less reliable and efficient than the google’s infrascructure.
If I can deliver data faster (and for free), why shouldn’t I take advantage of that ? Of course let’s make it neatly, not the ignorant way, but it doesn’t look like a rocket-science. Clarkson would say “how hard can it be?” :]
I am a WP beginner and have some very basic, limited coding skills,
but tried to sort things out and find the reasonable solution.
Please, correct me if I’m wrong at any point.
I compared jquery files with Diff:
– ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
– code.jquery.com/jquery-migrate-1.10.2.min.js
Except of few chars in commented-out top section they are identical
– /wp-includes/js/jquery/jquery.js?ver=1.10.2 (from WP 3.7.1)
It’s also the .min version, but followed with one extra line at the end:
jQuery.noConflict();
– /wp-includes/js/jquery/jquery-migrate.min.js?ver=1.2.1 and
code.jquery.com/jquery-migrate-1.2.1.min.js are identical
My algorithm proposition is:
– check what version of jquery was wordpress about to load
– try to load that version from google CDN instead (or from jquery CDN if prefered)
– if OK, run jQuery.noConflict();
– if failed – just use the local file
– check what version of jquery-migrate was WP about to load (if any)
– try to load that version from jquery CDN
– if failed – just use the local file
Is anything important missing above ? Should check first if not is_admin
or not necessarily ?
Firstly, you won’t even be able to unenqueue these scripts in the admin. Second of all, every argument I make above regarding why offloading your jQuery to a 3rd party still applies.
If your site is trafficked enough to warrant loading jQuery from a CDN, then you need to set up a CDN for all of your scripts, not just jQuery.
Well, I think it’s the time to say it out loud and face the fact – most of us is more or less google-dependent. It provides us the majority of incoming generic traffic +AdWords, AdSense, YouToube, GoogleMaps, Translate, Chrome, Documents, Drive, Alerts, Calendar, Gmail etc. In my country (Poland, over 38.5 million people) Google is used for 95-96% of search queries.
I know that the single services (including google.com itself) has been down before, and that is the reason why I put a fallback. That’s simple.
Using CDN cost $. It’s just like a driving sports car. Why should I buy one right away just for my own if I would be very happy while just being able to drive it borrowed from my best neighbour?
After GZIP my main page =66KB and many pages with some shorter posts and little graphic are around 70KB,
Now – hold down to your chairs – 35.3 KB of that is jquery + jquery-migrate (yes, gziped).
(And it’s called with a query mark ? like /wp-includes/js/jquery/jquery.js?ver=1.10.2
what’s bad because of most proxies do not cache resources with a “?” in their URL even if a Cache-control: public header is present in the response.)
Continuing, every new visitor is downloading it, which takes unnecessarily time, lowers loading speed and consumes some extra GB of transfer.
While it is very likely that he already has that JS in his cache (and even if somehow he does not, then it will be better if he gets it from the _faster_ server from google, which will be also helpful when he visitits some other sites that request it).
It’s a win-win situation – everyone’s happy and the Web is faster. The key is to SHARE.
What’s more, I don’t konw did you noticed, but WordPress already loads the scriptaculous from google server, IMHO it’s only a matter of time when the rest of standard libraries will be switched too.
BTW, yesterday I made that plugin and it works fine. Now only need to add some extra features and test it on the other versions of WP. Would you like to take a look at it or maybe give it a try ;->
If you want to get started with a more affordable CDN option, I highly recommend CloudFlare. They’re incredibly well-supported and smooth. Conveniently, the entry-level option is free. Think of it as a step above borrowing the sportscar from the neighbor without having to shell out cash for it at the same time.
As for Scriptaculous, no I hadn’t noticed that WordPress was loading it from Google. I’m not sure what the team’s justification was with that, and I’ll definitely be following up on that. Thanks for point it out. My point about jQuery, though, remains – I strongly recommend against offloading it to a CDN outside of your control.
At this point, I think it’s time for leaders (such as the stackexchange WordPress moderator) to accept that some customers have different architectural approaches to things. These approaches aren’t uninformed and many of the benefits of that approach have been mentioned here. At the end of the day, each approach has its costs and benefits.
It is up to each customer to evaluate those costs and benefits to determine what is the best approach for their situation. There is no one “Right Way ™”.
It’s disheartening to see a leader in such a position constantly respond by batting down other informed approaches because they don’t agree with that leader with a constant stream of put-downs implying that they don’t know what they are doing, that they don’t deserve the be hosting a wordpress site, or that they need to start paying more money to satisfy the leader’s architectural preferences.
Please adjust course and a customer advocate. Please use the leadership position afforded to you to serve customers by figuring out a way to accommodate this alternative approach by making it easier to do and find documentation about.
I do accept that other people take different approaches. What you need to accept is that, on my personal blog, I will always advocate my personal opinions and emphasize commonly-accepted best practices. It’s up to you as a reader to either accept my point or not, and if not then to make a counter argument.
With jQuery, my position is rooted in:
– Personal experience building websites
– Experience working on WordPress core
– Discussions with other WordPress core developers
– Discussions with the jQuery development team
Both core communities – WordPress and jQuery – make the same argument. It’s when a third party (Google) introduced the hosted script and other bloggers started advocating for its use that the question about whether or not to offload to Google makes sense. In some cases it does – in the majority of cases it does not.
You are correct there is no “right way” here. What works for one site (i.e. using Google’s jQuery) will often be a poor decision for another site – advocating that everyone should remove WordPress’ jQuery is folly, but that’s what many do regardless. This results in endless streams of “how do I” questions by askers who haven’t put the thought into why they’re asking the question in the first place.
Bottom line: If your site needs a CDN, then use it. But don’t start trying to offload your scripts to a 3rd party CDN just because you read a blog saying it was a good idea. Think first. What problem does this solve? What other problems does it introduce? Is there more than one solution? If you’ve answers those questions first, then you won’t need to ask the question I quote above in the blog post at all.
What is your thought about dequeuing jQuery in WordPress so it can be called in the footer still from Google’s CDN? My idea is that I’d like to call jQuery 2 if the user is not using an older IE, but load 1.9 if they are.
Sorry, I mis-spoke above, I’d load jQuery from the WordPress footer from a local copy, but I’m assuming some of the other benefits of using the enqueued jQuery would be lost. Should I just let WordPress load jQuery and not worry about 2.0 vs. 1.9?
jQuery 1.9/1.10 and 2.X both expose the same API. You’re not really gaining anything by moving to 2.X versus 1.X except for adding logic to switch things based on the visitor’s user agent. Even then, UA switching can be unpredictable and unstable, so adding this kind of switch might accidentally serve the 2.X version to visitors browsing with older versions of IE and thus break the experience. It’s admirable to try to lessen the size of your script package, but in this case you’re not really gaining much but still risking a great deal.
Thanks, really appreciate the response— I’ll stick with leaving it alone. Any thoughts on render-blocking of the enqueued jQuery (as opposed to an asynchronous load in the footer)?
My thought is that you shouldn’t be dequeuing jQuery in the first place. As I’ve said before, if your site’s traffic justifies the use of a CDN, then use a CDN for everything, not just jQuery. CloudFlare has a free level that will allow you to super-charge everything.
I agree with everything you’ve said Eric. I know a lot of the guys here are giving you crap (and they’re certainly entitled to their own opinion) but I myself have tinkered around with switching out WordPress’ bundled jQuery for Google’s CDN version. Sure enough it ended up breaking a lot of plugins / features on my site.
If WordPress thought it was of such a great benefit to use Google’s CDN version I’m sure they would have done it to begin with.
In order to speed things up on my site for optimized page performance I use a CDN (MaxCDN). I have it setup to serve my images, css files, javascript files, etc. all from their CDNs. That being said, when a visitor ends up on my site and by some chance they don’t already have jQuery cached they’re basically getting the bundled WordPress version of jQuery but it’s being served to them from a CDN just as it would be if I were using the Google version.
So, I think that most people who are so interested in serving as many things as possible from a CDN are better off spending the money and investing in a CDN solution such as MaxCDN. Crap, I’m only paying these guys $40 a year and that’s more than enough for two of the sites I’m running.
BTW Eric, which WordPress plugin are you using for the ‘Notify me of follow-up comments via email’ and ‘Notify me of new posts via email’ for the comment section of your site?
The notification comes stock with Automattic’s Jetpack. I have a plugin that will do new posts by email, but haven’t built out the comment notification yet, so I stick with Jetpack for simplicity.
Makes sense, thanks for the response!
Slightly off-topic but still somewhat on the same topic. Do you know why it is that WordPress by default loads jQuery in the head section of the site as opposed to the footer? For instance, on the Twenty Ten theme I am using on an older site it’s loading jQuery in the head. I know that most people suggest loading jQuery in the footer for better page loading times but I couldn’t figure out why it’s not in the footer by default, thought you might know since you’re a moderator at the stack exchange.
Loading libraries in the header and functional implementations in the footer is a fairly well-accepted best practice. However, deferring all scripts to the footer is also well-accepted, so the wp_enqueue_script() function allows you to specify a script should load in the footer rather than the header.
The Twenty Ten theme, to the best of my knowledge, was not leveraging that feature.
I’ve enjoyed reading this debate, both sides of the argument make good points for and against using a CDN version of jQuery. I’m still undecided so will keep an eye on this topic in the coming months. For now, I’m sticking with jQuery provided by WordPress – although next week that may change – who knows?.
If using a CDN for jQuery enhances the performance of your site, you should really be using a CDN for all of your static assets. As service like CloudFlare will cache and serve scripts, styles, and images for you automatically – still using the version of jQuery that ships with WordPress.
Eric’s advice is a reasonable point and full use of a CDN will offer better performance for your site.It’s a good way.
I prefer a middle ground where I get jQuery and some other core scripts/assets from google’s CDN (or microsoft etc) but leave my site-specific static assets local on my server.
Everything is a trade-off. The approach I use lets me avoid the complexity and potential cost of using a CDN for everything like using a WP plugin to manage uploads to the CDN in the dashboard during content editing. I also keep my entire source tree in Git, including assets.
I do get a speedup because the core libraries increase page load and rendering speed by reducing network latency and head of line blocking.
for small and simple websites, this works for me.
However, it is not as much of a speedup as using a full CDN.as Eric says. If your site is large, has a lot of content, and you are seeing high server load and inbound network bandwidth, then a CDN will help those things.
I would really suggest you look in to a service like CloudFlare. First off, the basic package is free. Second, it’s a reverse-proxy CDN, which means you upload your resources to your site like usual. When visitors request them, they’re really requesting through CloudFlare – CF will cache the assets so they don’t have to go back to your server to fetch them next time.
The advantage – CDN-level performance from all of your static assets (scripts and images) without you needing to manage uploads to the CDN or keep your source tree outside of version control. Take a look: https://www.cloudflare.com/plans
Great article Eric! I came across this problem quite a while ago and now keep on refering to articles like your’s if I see somebody using google CDN jquery + WP. It will always break at some point.
Hmm… I’m wondering why you’re loading your web fonts from Google CDN then… it’s the same 3rd party, right? From your logic (regarding jQuery), you should load them from your site too.
These are your own words:
“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.”
Go figure!
I’m running a stock theme built by StudioPress called Sixteen Nine. It’s a case of using a stock solution that works fine rather than over-engineering something on my own when the wheel has already been invented. Do I agree with all of the engineering decisions made in the theme? Not necessarily.
Am I counting on Google’s CDN to save me from a poorly set-up server environment? No. I have done absolutely nothing to my server or this theme to force fonts to load from Google’s network.
Go figure … out what arguments I’m actually making.
“Over a high-bandwidth connection, this downloads in less than half a second from just about anywhere […] then you have absolutely no business building or hosting websites.”.
Really? jQuery is usually at the beginning of the critical path for JS execution. Loading it +500ms later means delaying +500ms a lot of other stuff. This might be ok for your simple blog, but for other sites, accumulating 6 cases like that in the same page will get you fired.
I guess that other performance improvements such as using a custom CDN for all static assets or asynchronous JS loading are stupid ideas for you, but they are critical for people trying to get the best user experience possible for a big site.
Read a bit more carefully. If you need a custom CDN, by all means use one. But if you’re using a custom CDN, you’re setting it up for far more than those who are removing WP’s jQuery just to load it from a 3rd party CDN like Google.
Seriously people. You’re all missing the point. DNS lookups are costly. That means to you newbs, that your CDN just cost a DNS lookup. Picture this. Put all your scripts and images on a CDN (like all the pro’s do). A single CDN. One DNS lookup for every high speed properly cache controlled response!
You’ll argue “but it’s just jQuery on a CDN” – sure, that one is. And the next one? What domain is that hosted on? etc.
WP has great tools for CDN incorporation. Use them, and steer clear of all this cruft.
child theme’s functions.php
—————-
if(!function_exists(‘move_libraries’)){
add_action(‘wp_enqueue_scripts’,’move_libraries’,9999);
function move_libraries(){
wp_deregister_script(‘jquery’);
wp_deregister_script(‘jquery-migrate’);
wp_register_script(‘jquery’,’//cdn.jsdelivr.net/jquery/latest/jquery.min.js’,false,null,true);
wp_register_script(‘jquery-migrate’,’//cdn.jsdelivr.net/jquery.migrate/latest/jquery-migrate.min.js’,false,null,true);
wp_enqueue_script(‘jquery’);
wp_enqueue_script(‘jquery-migrate’);
}
}
if(!function_exists(‘wp_remove_version’)){
add_filter(‘the_generator’,’wp_remove_version’);
function wp_remove_version(){
return ”;
}
}
—————-
How is this relevant to an entire article explaining why you shouldn’t add such code to a site?
I want to put the jQuery to footer of page. How can I do that? I have moved all script to bottom. But jQuery not moving. Why?
jQuery will show up at the top if it’s explicitly enqueued to be in the top, or if a script dependent on it (either your theme or a plugin) is enqueued at the top. Sometimes plugins do things wrong and there’s no real way to fix it.
Couple of things not covered in this article:
1. Using Google’s hosted jQuery will save you bandwidth:
If you have a heavy traffic website, and you’re using a paid CDN service to speed things up for your visitors, one of the files that the CDN will cache is WordPress’ own ‘jquery.js’. You may think that’s not a big deal, but it is routinely featured in my CDN’s statistics as one of the “Top 5” most bandwidth hungry files. About 1GB/day on average goes just for serving WordPress’ jQuery to users via my CDN. On a paid service, saving GB’s = saving money.
2. Implementing Google’s hosted jQuery in WordPress in “no conflict” mode:
This is the most common criticism of implementing Google’s hosted jQuery in WordPress that I’ve read. The fact that WordPress implements its jQuery library in “no conflict” mode, and that using Google’s hosted jQuery might break things. Well, there’s a simple solution… just manually set “no conflict” mode yourself after Google’s jQuery has been loaded.
It’s as simple as adding $.noConflict(); right after the link to Google’s jQuery library. Problem solved.
A more “elegant” solution would be to create a script file and name it something like ‘jquery.noconflict.js’. Put that in your WordPress’ jQuery scripts directory (wp-includes/js/jquery/jquery.noconflict.js). Then in functions.php simply use “wp_enqueue_script( ‘jquery-noconflict’ , ‘/wp-includes/js/jquery/jquery.noconflict.js’ );”, right AFTER you’re implementation of wp_enqueue_script() for Google’s jQuery.
Works beautifully.
Most of the people in this world have really slow Internet connections. people from africa, india, latin america, oceania still struggle with high data consuming websites. The whole point of the youtube’s 240p is for catering such visitors. So every byte matters when it comes to online. Jquery is actually a waste of bandwidth, it may improve the development time, but due to so many unnecessary texts in its library it ends up eating so much bandwidth. This may not be a problem for people from developed nations, but those who are from developing nations pay a lot of the money for data, especially for mobile data. Data is limited. On top of that latency increases the download time.
Google has so many cdn’s all over the world, but people can’t afford to buy such amount of cdns. In fact most of the people host their websites in US. So oceanian visitors, indian visitors, japanese visitors have to spend a lot the time to download the jquery file, but with google cdn, the file is pulled from the nearest datacenter improving the download speed, and making the site load faster. Also so many websites which are not wordpress use jquery library from google cdns, so chances are that visitors who visit the site already have it in the cache.
Jquery library bundled with wordpress isn’t in visitor’s browser, they have to visit at least once to get it cached, but when then the site loads slow at first, when the first impression is bad, it’s hard to expect they would visit once again to the site. So this whole article is a fallacy. It might be true if you maintain a big site like facebook from where visitor would rarely go out, but for a typical blog hosting every single resource in a cdn improves the loading time, and thereby increasing the conversion rate. It’s okay for wordpress team to bundle jquery in its package, because some people prefer everything in one place, but for a high performance websites, let them to remove jquery and add google’s version. perhaps you could put an option in settings to switch between bundled copy and google’s copy, but by default bundle copy is selected.
Kudos for commenting on a 4+ year old article. Great way to resurrect the conversation. That being said, there are some issues with your argument.
Yes. They do. Which is my key argument for focusing on progressive enhancement of front-end websites. If possible, we shouldn’t be using jQuery or any other large JS library at all, but should focus first on the content being presented. After said content has loaded, we can leverage JS and other tools to enhance the experience, but the focus should be first and foremost on content to ensure it loads well for those with slow connections. But, that is not the point of this article.
Yes! And you’ve just hit the key reason this blog post exists. The jQuery loaded by WordPress is not the jQuery loaded by a stock CDN. WordPress runs jQuery in no-conflict mode explicitly to maintain compatibility with other JS libraries that have been shipped with WordPress and used by various plugins/themes in the past. Loading jQuery from a separate, non-WordPress CDN will not load in no-conflict mode and potentially conflict with these extensions.
Further, enqueuing WordPress’ version of jQuery will automatically load the jQuery Migrate extension, which re-adds various jQuery API features and functionality that have been otherwise stripped from jQuery itself. Again, loading jQuery from a separate, non-WordPress CDN will not load in these features. Your theme, plugins, and some parts of WordPress itself might not work properly!
No. The point of this whole article is to offer general advice for a general audience facing a general situation. In general, you should avoid using jQuery on the front-end at all. At the time this article was published, developers were going out of their way to remove stock jQuery installations both on the front-end and on the back-end. That’s why WordPress core now does extra work to prevent removing jQuery on the back-end because, well, all of the reasons in the article and those enumerated above. Using a version of jQuery other than the one tested and shipped with WordPress introduces API version conflicts, breaks the user experience, and leads to even more “how do I” support questions.
I will admit that there are specific cases where leveraging a CDN for scripts makes sense. That’s why I publish tools like Dynamic CDN, which will rewrite all front-end assets (not just scripts) to use a separate CDN for speed. This article, however, was intended for more general audiences who might fall afoul of the numerous “how do I remove jQuery” tutorials that will likely lead to a broken website because of all of the above.
Be careful accusing writers of committing a fallacy. Your comments are otherwise well thought out and, in many situations, perfectly valid. However, even in these situations I would contend that “how do I replace the bundled version of jQuery” is the wrong question. In situations where loading jQuery from a CDN does make sense, that’s not the only asset you should be offloading. As said above, that situation would require you “go for a fully-thought-out solution, not just a quick fix.”