Why move your Javascript files to a different main domain that you also own?

Answer 1

Limit cookie traffic?

After a cookie is set on a specific domain, every request to that domain will have the cookie sent back to the server. Every request!

That can add up quickly.

Answer 2

It's not just javascript that you can move to different domains but as many assets as possible will yield performance improvements.

Most browsers have a limit to the number of simultanious connections you can make to a single domain (I think it's around 4) so when you have a lot of images, js, css, etc theres often hold up in downloading each file.

You can use something like YSlow and FireBug to view when each file is downloaded from the server.

By having assets on separate domains you lessen the load on your primary and can have more simultanious connections and download more files at any given time.

We recently launched a realestate website which has a lot of images (of the houses, duh :P) which uses this principle for the images, so it's a lot faster to list the data.

We've also used this on many other websites which have high asset volumne.

Answer 3

I think you answered your own question.

I believe your issue is security-related, rather than WHY.

Perhaps a new META tag is in order that would describe valid CDNs for the page in question, then all we need is a browser add-on to read them and behave accordingly.

Answer 4

I think there's something in the CDN theory:

For example:

$ host j.imwx.com
j.imwx.com              CNAME   twc.vo.llnwd.net
twc.vo.llnwd.net        A       87.248.211.218
twc.vo.llnwd.net        A       87.248.211.219
$ whois llnwd.net
<snip ...>
Registrant:
  Limelight Networks Inc.
  2220 W. 14th Street
  Tempe, Arizona 85281-6945
  United States

Limelight is a CDN.

Meanwhile:

$ host s.ytimg.com
s.ytimg.com             CNAME   static.cache.l.google.com
static.cache.l.google.com       A       74.125.100.97

I'm guessing that this is a CDN for static content run internally by Google.

$ host cdn.turner.com
cdn.turner.com A record currently not present

Ah well, can't win 'em all.

By the way, if you use Firefox with the NoScript add-on then it will automate the process of hunting through source, and GUI-fy the process of whitelisting. Basically, click on the NoScript icon in the status bar, you're given a list of domains with options to temporarily or permanently whitelist, including "all on this page".

Answer 5

Would it be because of blocking done by spam and content filters? If they use weird domains then it's harder to figure out and/or you'll end up blocking something you want.

Dunno, just a thought.

Answer 6

If I were a big name, multi-brand company, I think this approach would make sense because you want to make the javascript code available as a library. I would want to make as many pages be as consistent as possible in handling things like addresses, state names, zip codes. AJAX probably makes this concern prominent.

In the current internet business model, domains are brands, not network names. If you get bought or spin-off brands, you end up with a lot of domain changes. This is a problem for even the most prominent sites.

There are still links that point to to useful documents in *.netscape.com and *.mcom.com that are long gone.

Wikipedia for Netscape says:

"On October 12, 2004, the popular developer website Netscape DevEdge was shut down by AOL. DevEdge was an important resource for Internet-related technologies, maintaining definitive documentation on the Netscape browser, documentation on associated technologies like HTML and JavaScript, and popular articles written by industry and technology leaders such as Danny Goodman. Some content from DevEdge has been republished at the Mozilla website."

So, that would be, in less than a 10 year period:

• Mosaic Communications Corporation
• Netscape Communications Corporation
• AOL
• AOL Time Warner
• Time Warner

If you put the code in a domain that is NOT a brand name, you retain a lot of flexibility and you don't have to refactor all the entry points, access control, and code references when the web sites are re-named.

Answer 7

Lots of reasons:

CDN - a different dns name makes it easier to shift static assets to a content distribution network

Parallelism - images, stylesheets, and static javascript are using two other connections which are not going to block other requests, like ajax callbacks or dynamic images

Cookie traffic - exactly correct - especially with sites that have a habit of storing far more than a simple session id in cookies

Load shaping - even without a CDN there are still good reasons to host the static assets on fewer web servers optimized to respond extremely quickly to a huge number of file url requests, while the rest of the site is hosted on a larger number of servers responding to more processor intensive dynamic requests

---

update - two reasons you don't use the CDN's dns name. The client dns name acts as a key to the proper "hive" of assets the CDN is caching. Also since your CDN is a commodity service you can change the provider by altering the dns record - so you can avoid any page changes, reconfiguration, or redeployment on your site.

Answer 8

Your follow-up question is essentially: Assuming a popular website is using a CDN, why would they use their own TLD like imwx.com instead of a subdomain (static.weather.com) or the CDN's domain?

Well, the reason for using a domain they control versus the CDN's domain is that they retain control -- they could potentially even change CDNs entirely and only have to change a DNS record, versus having to update links in 1000s of pages/applications.

So, why use nonsense domain names? Well, a big thing with helper files like .js and .css is that you want them to be cached downstream by proxies and people's browsers as much as possible. If a person hits gmail.com and all the .js is loaded out of their browser cache, the site appears much snappier to them, and it also saves bandwidth on the server end (everybody wins). The problem is that once you send HTTP headers for really aggressive caching (i.e. cache me for a week or a year or forever), these files aren't ever reliably loaded from the server any more and you can't make changes/fixes to them because things will break in people's browsers.

So, what companies have to do is stage these changes and actually change the URLs of all of these files to force people's browsers to reload them. Cycling through domains like "a.imwx.com", "b.imwx.com" etc. is how this gets done.

By using a nonsense domain name, the Javascript developers and their Javascript sysadmin/CDN liaison counterparts can have their own domain name/DNS that they're pushing these changes through, that they're accountable/autonomous for.

Then, if any sort of cookie-blocking or script-blocking starts happening on the TLD, they just change from one nonsense TLD to kyxmlek.com or whatever. They don't have to worry about accidentally doing something evil that has countermeasure side effects on all of *.google.com.

Answer 9

I have worked with a company that does this. They're in a datacenter w/ fairly good peering, so the CDN reasoning isn't as big for them (maybe it would help, but they don't do it for that reason). Their reason is that they run several webservers in parallel which collectively handle their dynamic pages (PHP scripts), and they serve images and some javascript off of a separate domain on which they use a fast, lightweight webserver such as lighttpd or thttpd to serve up images and static javascript.

PHP requires PHP. Static Javascript and images do not. A lot can be stripped out of a full featured webserver when all you need to do is the absolute minimum.

Sure, they could probably use a proxy that redirects requests to a specific subdirectory to a different server, but it's easier to just handle all the static content with a different server.

Answer 10

I implemented this solution about two to three years ago at a previous employer, when the website started getting overloaded due to a legacy web server implementation. By moving the CSS and layout images off to an Apache server, we reduced the load on the main server and increased the speed no end.

However, I've always been under the impression that Javascript functions can only be accessed from within the same domain as the page itself. Newer websites don't seem to have this limitation: as you mention, many have Javascript files on separate sub-domains or even completely detached domains altogether.

Can anyone give me a pointer on why this is now possible, when it wasn't a couple of years ago?