This is a topic that has been covered numerous times, including several times on this site, but I still find theme and plugin developers that are either unaware of the negative consequences or simply disregard them. I’d like to talk a bit about why exactly removing the default version of jQuery in WordPress and loading one from elsewhere, such as Google, is terribly irresponsible.

The process of removing the default jQuery in WordPress and making it load from Google looks like this:

function pluginprefix_load_scripts() {
	if ( !is_admin() ) {
		wp_register_script('jquery', '', false, '1.9');
add_action( 'wp_enqueue_scripts', 'pluginprefix_load_scripts' );

It’s an unfortunately very common practice for themes, and some plugins, to do this. Usually the developer does it because he or she believes they are improving the load times of the site using the theme/plugin, or perhaps they’re gaining access to new features in the latest version of jQuery that isn’t yet available in WordPress core. I’ve seen themes and plugins do this simply because they read a tutorial that said it was the best thing to do.

The big question is: why is this bad?

There are many reasons, and I will touch on each briefly.

1. WordPress Loads jQuery in noConflict Mode

The purpose of noConflict mode is to help ensure there are not compatibility problems between jQuery and other javascript libraries loaded into WordPress. In short, noConflict mode means that the standard $ short cut used in jQuery (and other javascript libraries) is not usable, and must be replaced with jQuery.

As shown by the WordPress codex,

     $(#somefunction) ...


    jQuery(#somefunction) ...


    // $ has been declared as a "short cut" to jQuery
    $(#somefunction) ...

You can also use your jQuery like this (when in noConflict mode):

(function($) {
    // $() will work as an alias for jQuery() inside of this function

So why is loading jQuery from Google (or anywhere else) bad? It’s bad because it is not loaded in noConflict mode, and that can very often result in error messages, such as this:

Uncaught ReferenceError: jQuery is not defined and Uncaught SyntaxError: Unexpected token <

This kind of error happens because the non-standard jQuery library loaded expects you to write your jQuery like this:

     $(#somefunction) ...

instead of the proper (in WordPress) way:

    $(#somefunction) ...

Since WordPress loads jQuery in noConflict mode and plugin/theme developers (who are doing it right) rely on jQuery being loaded that way, choosing to force WordPress to use a Google library that is NOT in noConflict mode is hugely irresponsible as it can often result in jQuery errors getting thrown when plugins expecting jQuery to be loaded as default from WordPress are used.

2. Increased Support Load for Other Developers

One of the arguments I often see for loading jQuery from Google (and ignoring the advice of many, many prominent members of the WordPress community) is that "it doesn't cause any problems".

Theme developers (sometimes plugins) often feel it's perfectly acceptable to load jQuery from Google because they have not personally received support tickets indicating there is a problem.

If developers of the themes loading jQuery don't get problem reports, how do they know there is a problem? It's simple: plugin developers get support tickets from users of the theme.

Plugin developers are almost always blamed (by the users) for problems in themes because the plugin is installed after the theme, so when a problem pops up after a plugin is installed, it is naturally assumed that the plugin caused it. When in the case of jQuery conflicts, however, it is nearly always the theme causing the problem. I say it's nearly always the theme simply because plugins that have a need for loading custom jQuery are much further and far between, but that doesn't mean plugins aren't the culprits too.

I have personally spent 100 hours or more on support tickets related to problems caused by themes or plugins loading custom jQuery.

Yesterday a theme developer told me "I have never gotten problem reports about jQuery, so how can it be bad?". He can think that but I know for fact that I (and my support team) have received at least 10 tickets directly related to jQuery conflicts caused by his theme.

It is hugely irresponsible as a developer to assume your code doesn't cause problems simply because you don't get reports of it when other developers are giving you report after report.

3. Themes Should Not Modify Core WordPress Behavior

Another topic that has been discussed at length is whether themes should add functional "features" to (or take away from) WordPress. Here's an article I wrote on it for WP Tuts+.

The key point of the discussion is simply that themes should mostly control the appearance of your site and plugins should control the functionality (e-commerce, custom post types, sliders, etc).

Plugins and WordPress itself rely on jQuery for tons of tasks, which means that when jQuery is modified the hundreds of tasks performed by plugins or WordPress core are also modified. In short, swapping out the default jQuery for a different version is a direct modification of the default behavior of WordPress, and a behavior that plugins rely on (and should be able to rely on).

Themes should never take it upon themselves to try and improve the performance of a site, except to ensure that all queries and layouts in the theme are performant. Attempting to improve performance of plugins or WordPress core itself is something themes have no business doing.

Assuming that your needs in a theme are more important than the needs of WordPress core and thousands of possible plugins is hugely irresponsible. There is a very good reason WordPress ships with its own version of jQuery: all developers can safely rely on it.

4. WordPress Updates the Bundled jQuery Version Frequently

One of the other reasons I've heard for loading your own jQuery is that WordPress doesn't always use the latest version available. This is a fair point, especially if the jQuery you are writing requires a newer version.

Interestingly, this is pretty ironic. Want to know what version of jQuery is almost always being loaded on sites that have conflicts? 1.4.4.

Yes, that's right, 1.4.4 (or other similarly old versions).

So the same developers that are arguing that they need newer versions than WordPress ships with are neglecting to update their code to load the new versions?

This is actually probably not so much because of the developers forgetting to update their versions (sometimes it is), but is more likely because a user of the theme has never updated to the new version that includes the updated jQuery. This is really, really common because users simply don't like to update. They especially do not like to update their theme.

A user is much more likely to update WordPress core than they are to update their theme. Know what happens when WordPress core is updated? jQuery is updated. Know what happens when a theme that loads an old version of jQuery is not updated? Conflicts galore.

The easy way to avoid this problem is to simply not offload jQuery.

5. There is One Good Way to Load Custom jQuery

If you absolutely must use a new version of jQuery, then I implore you to please, please do it only via the Use Google Libraries plugin. This is a plugin that will retrieve the Google libraries you need and load them exactly as WordPress code does (jQuery in noConflict mode for example), meaning that plugins relying on one of the core WordPress scripts will continue to function perfectly fine.

It is trivial to require a plugin in a theme.

There is only one reason a theme should ever need to require a newer version of jQuery, and that is simply if the newer version includes methods used in the theme that do not exist in the current version loaded in WordPress.
If you do not believe or agree with any of this, I strongly encourage you to write a plugin that relies on jQuery and release it. Once the plugin has been used by a large number of users, I guarantee you that conflicts with themes or plugins loading their own jQuery will be encountered and you will then fully understand why this is so incredibly frustrating.

6. Addendum: Theme Repositories Do Not Permit Replacing jQuery

Many theme repositories, including the official repository and, do not permit themes to replace the default version of jQuery. If you wish to have your theme listed in one of the large, popular repositories, do yourself a favor and don't even try.

  1. Helms

    Does WordPress only include jquery-ui core or does it include all the interactions, widgets and efffects as well?

  2. Todd Lahman

    I’ve dealt with this myself, and I agree with everything you wrote 1,000%. This would make a good WordCamp presentation for theme developers, so they can be better informed on good practice.

  3. Ben Gillbanks

    In regards to point 2 – I can assure you that, as a theme developer, we get blamed for the failings of plugins as well! 🙂

    Agreed on the principals though. I used to do the Google include thing – but now I always use WordPress defaults/ standards as much as possible. It just makes everything so much more straight forward.

    • Pippin

      Definitely. Theme and plugins developers all get blamed incorrectly 🙂

  4. Alexis

    I was having a “Uncaught SyntaxError”, and I couldn’t understand why. Everything was working fine, including complex plugins as EDD. But I couldn’t get working a tiny simple script I added.

    In fact it was only because I was not loading jquery properly !

    Thanks a lot for sharing best practices, that’s lifesaving.

  5. Alex

    Most of the points you made are terribly wrong!

    “Uncaught ReferenceError: jQuery is not defined and Uncaught SyntaxError: Unexpected token <"
    "jQuery is not defined" this cannot happen if you have loaded jQuery properly IN ANY mode. No conflict means whether to have $ variable or not, "jQuery" var is always there!
    "Unexpected token <" is your fault when you load jquery from wrong path and it brings the 404 html instead of javascript content…

    All this still doesn't change the fact that you can download a copy of personalized jQuery (whether from google cdn or not) and load it in noconflict mode (if you need it that much… never met a case when people used both jquery and other similar library at the same time and they conflict – this is usually sign of a terrible code and architecture).

    Updating wordpress core? This should not have been even related to this article!!! You should know what you load! And still you can load the latest from cdn or if the theme is never updated you keep the static old version – and this CAN NEVER CONFLICT with ANYTHING, as long as you've dequeued wp's jQuery.

    So, please, stop misleading people here…
    Lack of knowledge usually leads to such articles.

    • Kon

      Thank you so much, I though I was the only one reading the article and going “Whaaa… ??”

      Indeed, one needs to at least understand how things on the web work and not just “the wordpress way” (a way that often leads in the opposite direction of best practices of web development) in order to write articles that advice people on the said practices.

  6. Ed

    Spot on as usual. All points are accurate and valid of course.

  7. Kon

    OK, your first point is completely wrong. jQuery without the ‘noConflict’ mode works both ways: $() and jQuery();

    Off-loading jQuery has many benefits like performance improvements, latency reduction, etc.

    For example one may want to load jQuery in the footer instead of the section of the website, thus taking advantage of the page being parsed before downloading and executing the entire jQuery.
    In addition using Google’s cdn is much preferable to hosting it yourself. It will most definitely download faster and has a great chance of not needing to be downloaded at all since it may already be present in the user’s cache from visiting other websites that included jQuery from Google’s cdn.

    In the end it all boils down to doing it “the right way” or “the wordpress way” – you pick

    • Kon

      “instead of the section of the website”
      sorry, its supposed to say “instead of the [ HEAD ] section of the website”

  8. John Smith

    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.

  9. Julio

    It’s remkarkable in support of me to have a web page, which is useful designed for my knowledge.

    thanks admin

Comments are closed.