Monday, November 22, 2010

Edmunds partners with Google to make the web faster

Note: This is a guest post from Ismail Elshareef, who is the Principal Architect at 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, 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 (and now on our are:
  1. 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
  2. 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
  3. Using Expires headers: Caching static files in the client's browser to eliminate unnecessary, redundant requests to our servers
  4. 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.
  5. 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
  6. 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 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, 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.


  1. This comment has been removed by the author.

  2. Great article! I was wondering why you needed to load 3rd party JavaScript before the window.onload event. Is this a business or technical requirement/decision? We load a number of pixel trackers on and I'm trying to create a system of intelligently loading all of them and actually ran into issues when attempting to attach my loaded to the onload event. When I dropped that requirement everything consistently worked as expected.

  3. Rendering third party banners can impact your website performance, how did you address this?

  4. I'm trying to grok the nature of the partnership with Google here. It seems like everything in this article could have been done without talking to Google.

  5. I wrote a response earlier that seems to have vanished. Four attempts to publish and it still disappears.

  6. Jon: We are able to determine the type of the 3rd-party component in our CMS. So if it is an ad in a JavaScript format, we load it before the onload event. This is due to the fact that ads use document.write, which has to be executed before the onload event is fired otherwise bad things happen. More on that is discussed in our blog post.

  7. Courier: If the banner is called in an iFrame, we lazy loaded like the rest of the page components. Otherwise, we call it at the bottom of the page and then relocate it to its original position. I hope this answers your question :-)

  8. Christopher: Google has been a leader in promoting and evangelizing web performance and so is Edmunds. Our shared interest and passion for making the web faster makes all of us natural partners by default.

  9. Estoy de acuerdo con Ismael. El interes de todos es hacer assecible y rapida la rendicion de la web. Gracias por tu explicacion Edmunds.Lo intentare.Carin,

  10. Interesting article, but why the misleading title? Following Google's guidelines doesn't make you a partner with Google, by any normal interpretation of the word "partner".