I was under the impression that for the best performance, Javascript should be treated as static content and served from a cookieless domain along with CSS files, images, etc.

But Google says here: Don't serve early loaded external JS files from the cookieless domain

For JavaScript referenced in the head of the document and needed for page startup, it should be served from the same hostname as the main document. Because most browsers block other downloads and rendering until all JavaScript files have been downloaded, parsed and executed, it's better to avoid the risk of an additional DNS lookup at this point of processing.

So now I am conflicted. I am not clear on what "needed for page startup" means.

I typically have two JavaScript references, JQuery served from ajax.googleapis.com and a master.js file that mostly contains event handlers in the $(document).ready() function. Is this needed for page startup?

Given the options available, (ajax.googleapis.com, static cookieless domain, original hostname) where should my JavaScript be served?

5 Answers 5


So now I am conflicted. I am not clear on what "needed for page startup" means.

This very much depends on how your site functions. Basically, it is the JavaScript that needs to run before someone can make use of the web page.

As an example, if you go to http://www.weather.com/, you can see that the fine folks decided to use some JavaScript magic to provide a hint for the weather search form. I.e. the words Enter Zip, City or Place (e.g. Disney World) appear in the text input field. Unfortunately, there's a slight delay when the page is loading, at least on my end. So, if the page is slow enough to load and you're fast enough to start typing in the text input before the JavaScript executes -- which is not a stretch -- your input can be screwed up by the JavaScript that blindly places that hint text in the input box.

Granted, this could be avoided by checking for user input in the text box first or simply giving up on this anachronistic technique. However, then it wouldn't serve as a very good example.

Given the options available, (ajax.googleapis.com, static cookieless domain, original hostname) where should my JavaScript be served?

This can't really be answered without knowing what your JavaScript does. Also, as bpeterson76 alludes, it depends on your site's specific situation. I.e. how large is the page? how well is your host meeting demand? how many CSS files, images, etc does it load? how many external resources is it loading?

Depending on your specific situation, this may be premature optimization.


The "anything required before the page will start rendering should be from the same server" rule generally applies to your servers or other smaller resources - situations where that DNS lookup may taken a noticeable fraction of a second (which can add up quickly if your objects are strewn around many domains). With common public resources like Google's cache of jQuery and other libraries there is a good chance that your visitor's browser has already done that DNS lookup today (because other sites are referencing the content from that service) and probably has the file in cache too so no transfer needs to be done (or if a request is made it may just get back a short "304 - not modified" response). Even if a full download is needed for the object, Google's content delivery network will be faster for most users than your smaller scale operation.

One related rule: objects that are not required for the correct function of the page (as the user sees it) should be referred to as late as possible in the main HTTP response. For instance things like the scripts required for advert/stats services (i.e. Google Analytics and its ilk) - give the user your content as quickly as possible, then load the background stuff that only really interests you. I've blocked a couple of ads/stats services (by mapping them to in my hosts file) because they are often too slow and sites that refer to them early just give me a blank page while the scripts are waited for instead of referring to them late so I can read the content I am there for while the other stuff trundles along in the background.

The usefulness of a cookie-less domain for static content is a matter of scale. If all you have is one 10-byte session ID in the cookies and ten thousand visitors per day requesting ~20 static objects per visit you are only saving ~118Mbyte bandwidth per month (20*20*10000*31/1024/1024). If on the other hand your site keeps one or two Kbytes worth of stuff in the cookies the difference can be much more significant, especially if any of your users access the site via slow connections (i.e. GPRS through tethering to a mobile, or an over-crowded wifi link in a high interference area) or if you get millions of visits per day.

To summarize, for scripts that must be loaded before the page can render my preferences would be:

  1. ajax.googleapis.com, or similar
  2. original hostname of the calling page
  3. static cookie-less domain

For resources that are not essential for initial page rendering, refer to them as late as possible and reverse the above list of preference (though the difference between original hostname and cookie-less domain is most likely not significant unless you are operating on a massive scale).

  • With common public resources ... there is a good chance that your visitor's browser has already done that DNS lookup today Personally, I wouldn't feel comfortable relying on this for my site. I would want it to be as fast as reasonably possible in as many situations as possible. Regardless, you make good points. +1 Aug 3, 2010 at 18:24

Google runs a huge content network distributed all over the world that puts the content closer to the user than any single server that you're likely running (think Akami, but owned by Google) So, from a speed standpoint, it stands to reason that Google is going to get your file to the user faster than your local server...unless they are in very close proximity to your personal server.

This question has gone around and around over at Stackoverflow, and the above answer seems to be always the consensus. But from a realistic standpoint, the gains made by hosting at one vs the other is going to be fairly minimal in the long run. You'll get far better benefits from minifying, optimizing, and reducing overall http requests than you will scrutinizing where things are physically located. In situations where it starts to matter (I did a job where a page was loading 1.5+ million times /day, so a 5k improvement meant 5 gigs in bandwidth savings) there's usually a team of decision makers who are tasked with scrutinizing these decisions.

Personally, I usually host at Google for the sole reason that they're going to give me the most up-to-date copy of what I'm looking for.

  • Where do you host your custom JavaScript? Static cookieless domain or original hostname? Aug 3, 2010 at 17:19
  • Honestly, outside of (mostly) Jquery in-line, there's really not a lot that can't be dynamically linked. I tend to keep the voodoo to a minimum, using (primarily) core Jquery and Jquery UI, with the possible exception of the Datatables plugin. I'm a big believer in the concept of Keep it simple (stupid) and won't put out code if it isn't backwards compatible, which rules out a lot of options. As I said above, putting one file on a non-cookieless domain isn't that big of a deal. Aug 3, 2010 at 18:43

One important thing to remember is that browsers have limits on how many resources that will download simultaneously from the same domain, typically between 2 and 6 depending on the browser. Using a different domain lets the browser download more things simultaneously from your domain.

So the best solution is to use a popular CDN like ajax.googleapis.com as that way there are no cookies. The user has probably already done the DNS lookup and may have even cached the resource. CDN's are optimized for speed and probably have a server close to your user.

If a CDN is not an option then if you have lots of cookies or have lots of resources to download (images etc.) then use a cookie free domain (only needs to do DNS lookup once anyways).

If you have few resources (just one custom javascript file) and few cookies (just a tiny session id) host from the same domain.

Good resources:





Although the answers above have dissected most of your question, I'll contribute on "needed for page startup". I translate this to: is this script essential to using the website? From experience, usually the answer is no. However, cases when I would:

  • Form validation
  • A JavaScript-based navigation (not ideal anyway)
  • If the layout depends on JavaScript
  • If JavaScript, or a library (like jQuery) is used for DOM modifications that are critical

And Yahoo's YSlow performance guidelines for reference.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.