Making Your App Faster on the Front End

By Deane Barker on October 30, 2007

Best Practices for Speeding Up Your Web Site: This is a phenomenal page at the Yahoo! Developers Network about how to speed up pages on the front end.

The “front end” means everything after code execution is complete on the server. As developers, we tend to concentrate on server-side rendering, but we’re missing over half the problem. The front-end encompasses things like client-side caching, page rendering speed, etc.

This gets ignored too much. I just completed an CMS install using a system that’s fairly slow. But by spending three or four hours really tuning the page delivery, I was able to make up a lot of time lost to server-side execution. In particular, I managed to get the browser to consistently cache 90% of the total page weight. That helps more than you know.

An example of the tips in the article.

The second problem caused by scripts is blocking parallel downloads. The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel. (I’ve gotten Internet Explorer to download over 100 images in parallel.) While a script is downloading, however, the browser won’t start any other downloads, even on different hostnames.

In particular, the eTag spec is something I’ve seen but never quite understood. Using it, you can have the browser check if the page it has in cache has changed, and pull it from cache if it hasn’t. Rather than using Last-Modified dates (hard with dynamically generated pages), it actually calcs a checksum on the content.

What Links Here


  1. An etag is like a serial number on content. A user agent should check the head for an etag and only download the full content if the page’s etag has changed since the last time it was served. For static content, many web servers will calculate a checksum and set that as the etag. If you’re serving dynamic content, you’ll generally need to set the etag header yourself.

    For content that is the same to everyone (an unpersonalized news article page, for instance), you can simply generate an MD5 hash of the page contents and set that as the etag. For personalized pages, hashing the user’s name and the page contents can be an effective method to ensure unique etags for each page.

    Feed Crier used to use etags to detect duplicate feeds. If we had multiple feeds with the same etag in our database, we’d merge them into a single subscription. We had to stop doing that, however, when we discovered Jaiku was serving an identical etag for every one of their feeds. This caused us to merge update feeds that were in fact very different. We’ve since changed the duplicate detection to use other methods.

Comments are closed. If you have something you really want to say, email and we‘ll get it added for you.