Technology, The Web, and Oxford Commas.

by Chris Mallinson


Don't Host Static Assets

Bandwidth concerns for web developers used to be centered around the user. I remember making sure every page loaded no more than about 30k worth of assets, just so dial-up users could see my sites in only a few seconds. Now that most users have fast connections, and the few people using dial-up are used to the wait, you can start thinking about how much data your server is pushing out rather than how much data your clients are pulling. Those two numbers do not have to match.

Most of us are using one of a few of the main JavaScript frameworks, and some of you even use CSS frameworks. Either way, using JS or CSS frameworks means your clients are downloading code from you that is already on their computer – in their browser cache – courtesy of other sites using the same libraries.

This could be solved if we all started loading these frameworks from one place, and Google has provided a solution that does just that. Google hosts all the latest versions of the most popular JavaScript libraries, and keeps a few of the old versions if you need them. You can load the files directly by pointing to the path of the file, or you can use Google’s loader scripts.


Google hosts the following JS Libraries

  • jQuery and jQueryUI
  • Prototype and Script.aculo.us
  • MooTools
  • Dojo
  • SWFObject
  • YUI (Yahoo! UI Library)

This has multiple benefits. First, it reduces the amount of bandwidth you are using with your host. Second, unless you are really rich and like to throw money around, the Google servers are faster than yours, so your clients will load the files faster. Third, your clients may not need to load the files at all. As I mentioned earlier, the files may already be in their browser cache if they have visited a site that uses this technique.

But wait! That’s not all. JavaScript frameworks are the most obvious assets to offload to a faster host, since unless you are totally hard-core, you probably don’t modify them. But there are other files that you may need to load that stay relatively static. CSS is an obvious example, as is external JavaScript files that are not part of a framework. I also know that some of you like to combine and compress your JS files for quick loading, and the contents of those files could be specific to your site.

Amazon Web Services

There are good ways to offload these files as well. The best way that I have found is the use of Amazon Web Services. Create yourself an account, read a little bit about it, and watch some tutorials. There are some very sophisticated ways to host content on AWS, and some great ways to integrate the services with ColdFusion, but for hosting your static assets, you only need to upload your files, and use the generated URLs as the source for your files. It’s not free, but it’s ridiculously cheap – far cheaper than any web hosting company could provide.

5 Responses to Don't Host Static Assets

Russ says: June 4, 2009 at 11:00 am

In theory, this idea sounds good. In practice, I’m less convinced.
Potential issues:

1. Reliance on remote third party servers for core functionality seems like an unnecessary risk. There is no guarantee that those files will always be available.
And what becomes of your site when the remote JS files are unavailable? Users would be able to see your site but not use it, which would hurt your reputation much more than if your server went down and the site was entirely unavailable for a while.

2. Non-standard practices can cause confusion for future developers. If I hadn’t read this article, I would be confused if I came across some code referencing remote JS files, and then I would probably “fix” it, which would be a total waste of time.

Reply
Chris says: June 4, 2009 at 11:27 am

Both good points Russ

As for reliance on third party severs, for many people these third party servers are more reliable than their own servers. Also, I design most of my sites to use JS only to add functionality, keeping the site completely functional for users without JS at all (this also applies to CSS). Progressive enhancement is how JavaScript should be used if you want to reach the biggest audience.

In the case of loading jQuery from the Google code link, the jQuery.com even uses that. I think relying on Google to have their servers up is a pretty good gamble.

And with respect to Amazon Web Services, many many huge websites rely on AWS to host not only static assets, but dynamic assets, and assets that need to be secured. It’s an incredible service.

Crazy things can happen, and I agree that you need to be able to back out of any reliance on a third party, but that can be done easily by changing a couple of settings in your application.

Reply
Rob Dudley says: June 4, 2009 at 1:50 pm

Great idea and I wholeheartedly agree with the concept of progressive enhancement.

That said the DNS for Google reader was fritzed for 5 minutes before reading this and I’m not convinced that some of our clients would understand sporadic outages. Now if there were some way to programmaticly determine availability and include or fail back to local – that would be frickin’ sweet!

Reply
Chris says: June 4, 2009 at 2:48 pm

I think that, given the amount of high profile sites using the Google code version of jQuery, they would make sure that the availability was extremely high.

I would be a cool experiment to work out a way to programatically ensure that your JS files were loaded. The first thing that comes to mind would be a tiny JS file loaded locally that could determine if the jQuery (if that’s what you’re using) namespace existed, and if not, load a local, or alternatively hosted JS file. I think that would work. You could also use some fancy DNS tricks to use your own server as failover for the remote file. I’d build something like that if I was relying on a site for income.

Reply
Russ says: June 4, 2009 at 5:42 pm

The only problem with reverting to local files if remote files are unavailable is that your code could get stuck waiting for the remote files to be found, which would drag down your site speed if you checked for remote file existence upon every request.
However, if you checked for remote file existence at the start of an application or session, then individual page load time wouldn’t be affected. I think that would be the best way to do it.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>