Note: This is a guest post from Ismail Elshareef, who is the
Principal Architect at Edmunds.com. Thanks for the post and for making the web faster
Ismail!
In the Fall of 2008, we embarked on a complete
redesign of our car enthusiast site, insideline.com. One of the main redesign
objectives was to deliver the fastest page load possible to our consumers. Leading up to that
point, we have been closely following and implementing the performance best practices
championed by Google's Make the Web
Faster team and others. We understood the impact performance has on user experience
and the bottom line.
Some of the many performance-enhancing features
that have been implemented on insideline.com (and now on our beta.edmunds.com) are:
Reducing the number of HTTP requests: We combined CSS and JavaScript
files as necessary as well as using sprites and data URIs when appropriate. We have also
reduced the number of blocking requests as much as possible to make the pages "feel"
faster
Serving static content from different domains: This helped maximize
the browser parallel download capacity and made the request payload faster since no cookies
were sent over the wire to those domains
Using Expires headers: Caching
static files in the client's browser to eliminate unnecessary, redundant requests to our
servers
Lazy-loading Page Modules: Render the bare minimum page components
first so that the user sees something on the page, and then go through the modules and load
them in order of priority. We developed a JavaScript Loader component to help us accomplish
that which you can read more on the Edmunds
technology blog.
Managing 3rd-party components: iFrame
components could be lazy-loaded without a problem. JavaScript components, on the other hand,
need to be loaded onto the page before the onLoad event fires. That had the potential of
slowing down our pages. The solution we devised was to delay the calling of those components
until we initiate the lazy-loading of modules and right before the onLoad event
fires
Using non-blocking calls: With the browser being a single thread
process, we optimized ways of including resources on the page without affecting page rendering
so that the page is perceived to be fast by the user.
The
results on insideline.com have been
incredbile. Page load time went from 9 seconds on average on the old site to 1.5 seconds on
average on the new one, and that's with loading in much richer content onto the page (measured
with WebPageTest). We have also seen a
3% increase in ad revenue. On the beta.edmunds.com, which will replace our legacy
site fully in December 2010, we have seen a 17% increase in page views and a 2% reduction in
the bounce rate for our landing pages in a controlled
experiment.
Although we have a long way to go in making our
pages and services faster, we are very pleased of the progress we’ve made so far. Working with
Google to make the web faster has been an exciting adventure that will continue with more
improvements and innovations for both our sites and the web as a whole. Get more details on
the Edmunds
technology blog and try these enhancements on your site today.
By Ismail Elshareef,
Principal Architect, Edmunds.com