: Should JavaScript referenced in the head section be served from the same hostname as the main document? I was under the impression that for the best performance, Javascript should be treated

@Jessie594

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.

Vote Up Vote Down

@Vandalay111

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:
www.phpied.com/free-falling-waterfalls/ www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/ developer.yahoo.com/performance/rules.html

Vote Up Vote Down

@YK1175434

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 127.0.0.1 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:


ajax.googleapis.com, or similar
original hostname of the calling page
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).

Vote Up Vote Down

@Kristi941

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 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.

Vote Up Vote Down

@Caterina187

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.

Vote Up Vote Down