Our eBay Motors homepage has been around for more than 5 years, and we needed to give it a facelift. One of our goals was to make it faster: we wanted the new page to render twice as fast compared to the old one.
We started by running the YSlow and PageSpeed plug-ins and implementing the recommendations. Much better already, as you can see below!
You can run the PageSpeed tests yourself against the old and new homepages:
- Old: http://pagespeed.googlelabs.com/pagespeed/#url=www.motors.ebay.com&mobile=false
- New: http://pagespeed.googlelabs.com/pagespeed/#url=www.ebay.com_2Fmtr&mobile=false
We wanted to do more. Here are the three things we learned along the way:
- Progressive rendering via multiple flushes is a great way to increase perceived performance of a page because the user starts seeing content at the earliest possible time. Using just two chunks– one comprising all content above the fold, and the second everything below the fold — can give you great improvements. Our data indicates that 70% of our users are viewing our pages with a screen resolution of 1024×768, so we can divide the page as shown below (click on images to see enlarged versions).
This approach makes it possible to do very specific site speed optimizations. The first chunk above the fold needs to be optimized for fast server-side processing. By adding smart server caching mechanism, the number of backend HTTP calls needed to retrieve all the data for the above-fold content can be reduced significantly. In contrast, all JavaScript loading, parsing, and binding can be moved below the fold. As a result, a user can already see page content while below-the-fold content and JavaScript behavioral characteristics are still being delivered.
- Data URI for Static Images: Reduce the number of HTTP requests for static images (both sprited and individual) by leveraging the Data URI scheme. The new Motors homepage includes all static images as base64-encoded data URIs in CSS instead of as external URLs. (For IE7 and other browsers that don’t support Data URI, you need to have a CSS fallback to include external URLs.) Because CSS files are cached in the browser, you also get the benefit of image caching – similar to using external image URLs – in addition to reduced HTTP calls.
-
CSS Lint is an open-source tool similar to JS Lint used to identify CSS coding problems. From the wide variety of configurable rules that CSS Lint offers, you can pick a subset based on your application’s needs. Due to the various options available in the CSS Lint source, integration with your CI build system should be pretty straightforward. Look for improvement opportunities in the following areas:
- removing unused and redundant code
- using efficient CSS selectors
- writing reusable and maintainable code
After running CSS Lint on our code base and fixing the reported problems, we improved page rendering by about 200 milliseconds — a big win for us! And now that CSS Lint is a part of our build system, we are sure to catch issues before they become a problem in production. We highly recommend this tool for CSS-heavy websites.
What’s next? With all the performance optimizations, we were able to achieve our goal in our first release. The new page is indeed twice as fast as the old one! We are now testing ideas for the next iteration. One promising approach is displaying images using div tags with the background-image style, rather than using img tags with the src attribute. After reading about this technique we experimented with it in one of our image-heavy projects, and the results were positive. Some tests showed page speed improved by as much as 23%; however, we didn’t see a difference for pages with few images. We are going to test the technique on our image-heavy Motors homepage in one of our upcoming releases.
Go ahead, try out the new eBay Motors homepage! We would love to get your feedback.
Senthil Padmanabhan
Engineering Lead & Site Speed Evangelist