Grow your CSS skills. Land your dream job.

Poll Results: Large file on major CDN or small file local

Published by Chris Coyier

I quite enjoyed this poll because the results were so neck and neck. It was only in the last week or so that a clear winner has emerged.

Local wins with 55%

Like all polls ever run in the history of this website, there is lots of things to consider and the poll was probably too simple for it's own good. Nonetheless, I consider just getting people thinking about this issue a success. At the very surface: 20k is smaller but the CDN is faster and more likely to be cached.

There is a bunch more too it though...

  • The CDN is probably a different domain, so even if a user does need to load the file it doesn't count against the maximum concurrent connections for a single domain.
  • Loading the JS is one thing, but executing the JS is another. Executing 200k of JS will always be slower than 20k.
  • Da_n reminds us they aren't mutually exclusive. You could attempt to load from the CDN and fall back to local.
  • Evert reminds us that some IP address/ranges can be blocked in some countries, so the more different ones we pull from the higher the chances that some resources will be block and lead to problems loading the page.
  • In the case of the Google CDN (the most popular for this sort of thing), the only way the caching is in place is if you link to a very specific version of a library, like 1.8.14. If you link any less specifically (e.g. 1.8 will give you the latest version that is 1.8.something) it's not cached (or not cached very long).
  • CDN saves bandwidth, and those costs can be significant (e.g. The 100k image sprite on the current design of this site used 50+ GB of bandwidth in the last 30 days. That's one file.).
  • Locally, you have the option to merge the 20k into other JS files and load a single resource instead of many.
  • Paul Irish says we should A/B test for speed and pick the fastest.
  • Mobile is a very serious consideration. Mobile browsers have far less room for cache and (sometimes) have less bandwidth.
  • Kent Davidson reminds us that if we are super worried about privacy, the CDN may be out, as it gives referrer strings to the CDN for each person requesting the file.
  • Hosting that small custom file on your own CDN has big advantages. It may not have any chance of being cached coming in, but has the other advantages.

There was another good point brought up in the comments by Jayphen:

Posts like this make me worry about the kind of misinformation spread by these kinds of polls…

If the majority of other developers do the wrong thing, that doesn’t make it right.

Just because "local" won this poll, doesn't make it the right answer all the time (see considerations above).

New poll soonish. If you have an idea for a poll on CSS-Tricks, leave it as a comment below. I'd like to refill the reserves of poll ideas.

Comments

  1. Paul
    Permalink to comment#

    Hi Chris

    Would you consider putting up a poll to see if jQuery should come bundled with browsers ?

    http://css-tricks.com/13261-large-file-on-cdn-or-small-local/#comment-99489

    It makes a lot more sense, and it’s do-able.

    • I think I’d have to hear a compelling argument. Seems slightly weird. Like how do you as a page author indicate you want the “browser version”? Or does the browser hijack requests for it? And how to new version rollouts work?

    • Permalink to comment#

      2 Words: “Version Control”. The biggest pain-in-the-ass about using Flash (besides just using Flash) is making sure that 1. The user has it and 2. They have a current version that supports your SWF.

      I’d much rather be able to code the version and everything that goes along with it than depend on what my visitor has (or doesn’t).

    • Some syntax like this would come in handy:

      if(Bowser.localstorage.frameworks.jquery['1.6.2']) { // The browser ships with a version
          Browser.loadFramework('jquery','1.6.2');
      }
      else { // We need to fetch our own version
          fallback = document.createElement('script'); // Create a new script element
          fallback.async = 1; // Make it load asyncronously
          fallback.id='jquery-script'; // Let's enable ourselves to reference it
          fallback.src=('http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.js');
          s = document.getElementsByTagName('script')[0];  // Get the very first script tag in your HTML
          s.parentNode.insertBefore(fallback,s); // Insert the fallback
      }
      
      window.onload = function(){
          if(!jQuery){
              document.getElementById('jquery-script').src='js/jquery/1.6.2/jquery.js';
          }
      };
      
    • Permalink to comment#

      Yes, thats a good idea.
      Apart from some new features, all the modern browsers can have a basic jQuery version which can perform almost 90% tasks.

      It could highly boost website speed.

    • Evert
      Permalink to comment#

      We will probablky end up with all browsers implementing jQuery, except IE which will use mootools. LOL

    • Permalink to comment#

      seems nice on the surface (even after dealing with versioning – browsers, after all, could conceivably include several recent versions for your scripts to pick between), but my big concern would be that browsers shouldn’t be picking sides when it comes to javascript libraries.

      I think jQuery is awesome, but I won’t lay money on it being the best library forever.

      I use jQuery all the time, but I don’t think people should be left “out in the cold” because they need/prefer some other library that isn’t included in browsers (and that would be a legitimate risk, since native jQuery could have such an advantage as to make pages using other libraries seem sluggish).

    • If you take a look at my implementation, you could surely see there’s room for all the popular libraries

    • Who’s to say jQuery will still be used in 5 years? libraries serve different purposes for different things and unless a browser like chrome or firefox need a specific part of a library’s functionality, it would be built into their respective engines. Unless the browser requires a library to function I see no need to bundle an exclusive js library with the browser.

      jQuery is very popular and has undergone hundreds if not thousands of core updates alone. This being the nature of JS libraries, It’s just not a practical solution for browser vendors to ship the latest jQuery source with each browser update. It’s also a valid concern whether depending on a browser having the correct library version would break your site simply because the user hasn’t updated their browser yet.

  2. I honestly don’t think that Jquery being included within the browser itself is a good idea at all. For one doing so is going to add overhead to the browser. This overhead might not matter for sites that implement Jquery, but for those not using it it’s a completely unnecessary expense.

    Second, browsers become outdated, and we all know that not everyone updates to the latest, or even last latest, release. This means that the web developer would have to take even more time to add legacy support for older browsers that included a Jquery library that didn’t support some of the latest features.

    A third reason against this is something that traq touched on above, Jquery probably won’t always be the best javasript library available.

    • I don’t think it would be a good idea either. However, if browsers supported instructions like “getElementsBySelector” it would speed up dom traversals in jquery (which could use it). I have no other idea right now, but I think it’s up to the w3c to think about new low-level methods to speed up current libraries. That would be the way I’d choose if I was implied in such choices.

    • http://lievheid.nl/examples/prototyping/document.get.html

      Have a look at my implementation for document.get(); It’s the same behaviour you’d expect of something like getElementsBySelector. I don’t think it’s something the W3C should be concerned with, but you should do a feature request for the ECMA 5 development.

  3. Great post! CDN saves bandwidth but costs you mean be significant? I actually want to learn wordpress from you. I hope for the similar content.

  4. I’ve used jQuery and Prototype extensively, and whilst I find jQuery more user-friendly, I think Prototype is more powerful, in terms of instantiating classes and using it in an Object Oriented way.

    I’ll often load jQuery or Prototype from Google’s CDN, since it saves bandwidth and time if the user already has it cached.

    Websites change so quickly and are redesigned/refactored so often that when the time comes there’s bound to be a new version of your JS library which is faster and more stable.

    Interesting that the results were so close though, and stayed neck and neck for a long time.

  5. this is getting pretty interesting. if they could bundle jquery and stuff with new versions we could really speed up our work flow

  6. This pretty much sums up what needs to be seen around some parts of the web today, and even I could benefit from some of it http://www.creativeautomaton.com.

  7. Permalink to comment#

    I’ve only recently started thinking seriously about using CDNs for much other than loading the JQuery library. I understand there is some serious benefit, but the implication of your poll is pretty striking – that the benefits might be worth a 10x difference in file size! You really got me thinking…

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".