Yahoo! Search – new features, faster performance

September 28, 2009 8:24 pm | 4 Comments

My last blog post was about Mobile Gmail performance best practices. It’s nice to follow that up with a review of a recent YDN blog post: Not Just a Pretty Face: Performance and the New Yahoo! Search. It’s great to see these industry leaders sharing their performance tips with the developer community and showing the high value they put on making web pages faster.

Yahoo! Search recently added several rich new features. Along with that came many performance improvements, resulting in a launch that not only had more features but was faster than the old version. What?! More features and faster performance?! Yes, you can have your cake and eat it, too. Here are some of the performance optimizations you can find in the new Yahoo! Search:

data: URIs

Any HTML attribute that accepts a URL can also accept a data: URI – an encoded version of the actual HTTP response. This is a best practice for reducing the number of HTTP requests. Yahoo! Search converted several of their CSS background images into data: URIs. For example, the gold Search button’s background looks like this:

If you look at their stylesheet, you’ll see that the background image uses a data: URI rather than an image URL:

.sbb {background-image: url('data:image/png;base64,iVBORw0KGgoAAAANSU...rkJggg==');}

Using data: URIs instead of separate images eliminates HTTP requests. Even better, because the data: URI is in an external stylesheet (as opposed to the HTML document itself), it can be cached.

page flushing

Flushing the document early is a best practice I evangelize in Even Faster Web Sites. Sending the HTML header and top navbar as quickly as possible allows the browser to start rendering the page more quickly. This visual feedback gives the user an experience that feels faster. If there are any resources in the head, the browser can get a jump on downloading them while the rest of page is still being stitched together. Yahoo! Search! sends down an initial chunk that includes the page header and search box. This HTML is fairly static, so the backend server can generate it quickly, before starting on the actual search results.

Yahoo! Search goes even farther. The next chunk contains the remaining visible page content, but no JavaScript. The JavaScript is downloaded last, progressively enhancing the functionality of the page. This is a pattern I’m seeing more and more, especially in JavaScript-intensive web apps.

lazy loading

Yahoo! Search divided the JavaScript and CSS in the search results page into two categories: the bare minimum required to render the basic page and additional (heavy) functionality such as Search Assist and Search Pad. This is similar to another of my performance best practices: Splitting the Initial Payload. My advice focuses on JavaScript, but Yahoo! Search has extended the optimization to include CSS.

My post on Mobile GMail talked about their approach to lazy-loading JavaScript that avoids locking up the browser. Yahoo! Search uses the Script DOM Element approach – create a script element, set its src, and append it to the head element. This is a great approach for loading scripts in parallel. Yahoo! Search lazy-loads three scripts, so parallel loading is important. This technique does cause the JavaScript to be parsed and executed immediately. This isn’t an issue if it’s a small amount of code or the functionality is needed immediately. Otherwise, downloading the JavaScript and delaying the parsing and execution might lead to an even faster user experience.

Kudos to the Yahoo! Search team. Great work, and thanks for sharing!

4 Responses to Yahoo! Search – new features, faster performance

  1. Sergey Chernyshev | 29-Sep-09 at 6:12 am | Permalink |

    Steve, data URIs are great for small interface images, no questions here, but what do you do with browsers that don’t support them? Does this mean you need to sniff the browsers for this to work and use different CSS files?

  2. Steve Souders | 29-Sep-09 at 3:01 pm | Permalink |

    @Sergey: Here’s what the original blog post said: “To maintain backwards compatibility, we provided a separate gradient-only sprite for IE6 and IE7. This means that those browsers encounter slightly worse performance than more modern browsers, but the net effect is still an overall win. Of course, managing a split code base is a little risky.”

  3. sunnybear | 30-Sep-09 at 3:43 am | Permalink |

    A lof of data:URI usage can decrease page rendering time, which is more important (in case of cached files) than HTTP requests reducing (that are also eliminated in case of cached files).

    Cached views are about 70-80% by Yahoo! researches.

    After preliminary tests data:URI was about 30-50% slower that raw images (for Chrome — 80-100x slower) and 80-100% slower than CSS images. I’m going to prepare correct test environment to track this.

  4. Dan Coppen | 11-Oct-09 at 5:14 pm | Permalink |

    Thanks for the post, learned a lot from the series.

    @sunnybear. thanks, waiting for your results. Great product, btw.