performance on the yahoo! homepage

Performance on thePerformance on the

Yahoo! HomepageYahoo! Homepage

Nicholas C. ZakasNicholas C. ZakasPrincipal Front End Engineer, Yahoo!Principal Front End Engineer, Yahoo!Velocity, June 24 2010Velocity, June 24 2010

flickr.com/photos/eyesplash/4268550236/

(@slicknet on Twitter)

Principal Front End Engineer

Contributor

Author

The Challenge:Create a new Yahoo! homepage*

*add a ton of new functionality

**without sacrificing performance

By the Numbers

345million

unique users per month worldwide

110million

unique users per month in United States

(no pressure)

The Legacy

We strapped ourselves in, believing we could

make the fastest Yahoo! homepage yet

flickr.com/photos/yodelanecdotal/3620023763/

Performance is hardThe best features for users aren't always the fastest

flickr.com/photos/thetruthabout/2831498922/

Content Optimization Enginedetermines which stories todisplay at request time

Sites can be completelycustomized by the user

Popular search topics aredetermined at request timeto display up-to-date info

Random information aboutother parts of the Yahoo!network

Apps provide more infoon-demand

The Cost of Customization• Spriting is difficult

– Hard to know which images will be on the page together

• Limited image caching– With content constantly changing, getting

images into cache doesn't help much• A lot more JavaScript/CSS

– And very different, depending on how the user has customized the page

Performance reboot

Many of the optimizations made on the previous homepage won't work

flickr.com/photos/thetorpedodog/458336570/

Coming to peace with reality We can't optimize everything – so let's just focus on the parts we can

flickr.com/photos/hape_gera/2123257808/


Areas of Focus• Time to interactivity• Ajax Responsiveness• Perceived performance

The time to interactivity is the time between the initial page

request and when the user can complete an action

Time to Interactivity• For most pages, happens between

DOMContentLoaded and onload– Can actually happen earlier

• Links work, forms can be submitted even while the page is loading– As long as JavaScript isn't running

• Difficult to measure

Net tab reveals some informationWhere DOMContentLoaded and onload occur

YSlow reports onload timeUseful, but doesn't really determine time to interactivity

Goal:Ensure interactivity by DOMContentLoaded

Simple User Actions• Clicking a headline to read the story• Performing a search• Clicking on a favorite

Wait a second!You don't need JavaScript

for any of that!

flickr.com/photos/marcoarment/2035853550/

Progressive Enhancement FTW!The more tasks that don't require JavaScript,

the faster the user can complete an action

alistapart.com/articles/understandingprogressiveenhancement

The page is very functionaleven without JavaScript

Not relying on JavaScript for everything allows us an

opportunity to deliver what appears to be a faster experience

JavaScriptLoading onto the page without pain

Traditional thinking was put scripts at the bottom

Our results were upsetting

Putting scripts at the bottom actually caused other problems

flickr.com/photos/kartik_m/2724121901/

flickr.com/photos/kartik_m/2724121901/

Results• Page would fully render, but be frozen

– User can't interact while JavaScript is being fetched/parsed/executed

• Delayed onload to after 5s on fast connection• Time to interactivity tied to onload• Experience was especially bad over slower

connections– Page was unresponsive for 30s or more

In order to fix things, we had to get lazy

flickr.com/photos/19613690@N05/3687563687/

stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

nczonline.net/blog/2009/07/28/the-best-way-to-load-external-javascript/

<html><head> </head><body>  <script type="text/javascript" src="smallfile.js"> </script> <script type="text/javascript"> loadScript(filename, function(){ //initialization }); </script></body></html>

Y.Get.script(YUI.presentation.lazyScriptList, { onSuccess: function()

{ Y.use("*"); Y.ModulePlatform.init(Y.dali.config, true); }});

Everything else

First script file

flic

kr.c

om/p

hoto

s/n

atea

ndm

iran

da/2

62

539

96

53/

Results• Page is interactive as

soon as each section is rendered

• Reduced onload time to ~2.5s on fast connections

• Slow connection experience vastly improved

JavaScript Loads• Small amount on page load• Larger amount loaded in non-blocking manner

– Everything necessary for core JavaScript interactivity

• Ajax responses can specify more JavaScript is needed to handle the response– True, on-demand loading

Page FlushingGetting data out to the browser fast

Traditional thinking is to flush after <head>

Flushing after <head> ensures CSS starts to download as quickly as possible

But the user still sees a blank screen until the rest of the HTML is rendered to the browser

Solution: flush after major sections of the page have been output

flickr.com/photos/conskeptical/354951028/

<div class="doc"> <div class="hd">

</div>  <div class=”bd”>

</div></div>

The browser won't render a block-level element inside of <body>until the closing tag has been received

<div class="hd">

</div><div class=”bd”>

</div>

Removing page-level wrapper <div> allows the head torender as quickly as possible

Flush

Flush

(Actually, we flush a bunch of times as the page is output)

Even when the browser can't render yet, it can still start to download other resources such as images

The biggest area of concern regarding Ajax performance was around the apps. For our very first test, it sometimes took as long as 7 seconds to load a single app.

What exactly is taking 7 seconds?The measurement itself was a huge black box – before doing anything,

we had to figure out exactly what was happening in that time

start stop

Roundtrip TimeThe first step is the amount of time between when the browser sends

the request and the time it receives the response

start stoproundtrip

Parse TimeNext, the JSON response returned from the server has to be parsed

start stoproundtrip parse

JavaScript/CSS Download TimeEach response can indicate it needs more JavaScript/CSS before the

content can be used

start stoproundtrip parse download

Render TimeThe amount of time it takes to actually change the display via innerHTML

start stoproundtrip parse download render

Where We Started

Fixing Roundtrip TimeWhat's taking so damn long?

The right-side ads were a roundtrip issueThe server-side ad call took extra time plus the ad markup represented

50-60% of the returned markup

“Fixing” the adEntire right column now renders in an iframe. This defers the ad call

until after the app has been loaded in the browser, saving bothserver time for app rendering and bytes in the response.

Fixing Parse TimeWhat's taking so freakin' long??

{ "msg": "Hello world!", "day": 6, "found": true,}

JSON is super-efficient for transporting numbers, Booleans, simple strings, objects, and arrays

{ "html":"<div id=\"default-p_26583360\" class=\"mod view_default\"> <div

id=\"default-p_26583360-bd\" class=\"bd type_pacontainer type_pacontainer_default\"><div class=\" pa-app-col1 y-pa-ln-open-dk \"><div class=\"hd pa-app-hd\"><h2 class=\"x-large\"><a href=\"_ylt=ArPtckll5ytFOZy32_Tg07qbvZx4\/SIG=10u61l0b2\/**http%3A\/\/finance.yahoo.com\/\">Finance<\/a><\/h2> \t<div class=\"pa-menu-options\">\n \t\t<a role=\"button\" class=\"pa-menu-optionsbtn small pa-app-header\" href=\"#\" data-b=\"_ylt=AhzOmRGiUKjiPuGRaW8LrGabvZx4\">Options<span class=\"y-fp-pg-controls arrow\"><\/span><\/a>\n\t\t\t\t<ul id=\"p_26583360-settings-menu\" class=\"y-menu medium\">\n\t\t\t\t\t\n\t\t\t\t\t<li><a href=\"_ylt=AtqN.M70D5mHiPrcLvHF9vibvZx4\/SIG=1254msah3\/**http%3A\/\/help.yahoo.com\/l\/us\/yahoo\/homepage\/homepage\/myapps\/stocks\" class=\"y-link-1 help-option\"><span class=\"y-fp-pg-controls\"><\/span>Help<\/a><\/li>\n\t\t\t\t\t\n\t\t\t <\/ul>\n\t\t <\/div><\/div><div id=\"default-u_93109\" class=\"mod view_default\"> <div id=\"default-u_93109-bd\" class=\"bd type_finance type_finance_default\"> <div class=\"finance-nav clearfix\">\n <a href=\"_ylt=AvKZuIwh_mvmWInFE6c7Zc.bvZx4\/SIG=10u61l0b2\/**http%3A\/\/finance.yahoo.com\/\" class=\"small text-color goto-link\"><span class=\"goto\">Go to:<\/span> <span class=\"property\"><img src=\"http:\/\/d.yimg.com\/a\/i\/ww\/met\/mod\/ybang_22_061509.png\" alt=\"Finance\"> Finance<\/span><\/a>\n <ul class=\"y-tablist med-small\" id=\"u_93109-tabs\"> <li class=\"selected\"><a href=\"#\" data-b=\"_ylt=AhW8HKKgyZxBNcux07hCVxGbvZx4\">Overview<\/a><\/li> <li class=\"\"><a href=\"#\" data-b=\"_ylt=AuEzZyDTq.4N_vTGBXpu2VubvZx4\">My Portfolios<\/a><\/li> <\/ul>\n <\/div>\n <div class=\"y-tabpanels y-tp-default\">\n <div class=\"tabpanel selected\">\n <div class=\"menu menu-empty y-glbl-mod-grad\"><\/div>\n <div class=\"market-overview\">\n <div class=\"holder\">\n <p class=\"x-small date text-color\">Sat, Jun 12, 2010 10:10am PDT<\/p>\n <table class=\"index-update\">\n <tbody>\n <tr class=\"med-large\">\n <td class=\"hide-contents hide-textindent\"> <\/td>\n"

}

Very inefficient for large HTML stringsEscapement adds a lot of extra bytes

The larger the JSON string, the longer it took to parse

Keep in mind there was no native browser JSON parsing when we began testing the new page

The regular expression validation in the YUI JSON utility (based on json2.js) could take up to 40% of the parse time

Shrinking the size of the HTML by deferring the ad helped

But we still wanted to see if we could eek out better gains

[{ "msg": "Hello world!", "day": 6, "found": true,}]=====<div class="foo"><a href="http://www.yahoo.com">Yahoo!

</a></div>

We experimented with an alternate response format where meta data was in JSON form but HTML was included afterward in plain

text

Results were good

But then native JSON parsing hit and a lot of problems went away

flickr.com/photos/mattymatt/3017263513/

Fixing Download TimeWhat's taking so (*&#$Q@! long???

On-demand JavaScript/CSS downloading hurt app loading

timeIntended to decrease page load time, and did – but left us with this

side effect

Waiting until the user takes an action ensures paying the cost of download

What if you knew which apps the user was going to use?

Solution: predictive fetch of JavaScript/CSS before you need it

flickr.com/photos/mcgraths/3248483447/

After page load, we start todownload JavaScript/CSS forthe apps on the page

After onload

onload

Fixing Render TimeWTF is taking so (*&#$Q@! long?!?!?

Actually, render time was okay

Results

Don't underestimate the power of perception

Initially, the new page was actually slower to load than the

previous

To be expected – a lot more JavaScript and CSS

Blank space is badMakes it seem like nothing is happening

Adjusting Perception• Frequent page flushing

– Progressive rendering avoids a lot of blank space

• JavaScript at the bottom– Ensure it doesn't block rendering

• Lazy load JavaScript– Decrease time to interactivity

Initially, apps werecompletely blank whileloading (seemed slow)

We changed it to a pseudo-loaded state, which madeloading seem faster

In the end, user testing showed that perceived performance of the new page

was the same as on the old page

Wrap Up

Lessons Learned• Time to interactivity is a big deal• Progressive enhancement creates a better

experience– Allows for delayed load of JavaScript

• Load as much JavaScript as possible in a non-blocking manner

• Ajax performance is a macro measurement– Get more insight by looking at the parts

• Perceived performance is important

flickr.com/photos/ficken/1813744832/

Achievements• Reduced time to onload from ~5s to ~2.5s

– Actually better than previous version• Very short time to interactivity• Reduced time to open apps from ~7s to ~2s• Maintained perception of speed from previous

version

Questions?

Etcetera• My blog: www.nczonline.net• My email: [email protected]• Twitter: @slicknet

performance on the yahoo! homepage

Technology

comphotoskartik page

page load larger

initial page request

slower connections page

receivedremoving pagelevel

page performance rebootmany

var script

createelementscript