Performance Yahoo Homepage - By Nicholas Zakas

8/9/2019 Performance Yahoo Homepage - By Nicholas Zakas

1/99

Performance on thePerformance on the

Yahoo! HomepageYahoo! Homepage

Nicholas C. ZakasNicholas C. Zakas

Principal Front End Engineer, Yahoo!Principal Front End Engineer, Yahoo!

Velocity, June 24 2010Velocity, June 24 2010

flickr.com/photos/eyesplash/4268550236/


2/99

(@slicknet on Twitter)


3/99

Principal Front End Engineer


4/99

Contributor


5/99

Author


6/99

The Challenge:Create a new Yahoo! homepage*

*add a ton of new functionality

**without sacrificing performance


7/99

By the Numbers

345millionunique users per month

worldwide

110millionunique users per month

in United States

(no pressure)


8/99

The Legacy


9/99

1996


10/99

1997


11/99

1999


12/99

2002


13/99

2004


14/99

2006


15/99

Today

flickr com/photos/yodelanecdotal/3620023763/


16/99

We strapped ourselves in, believing we could

make the fastest Yahoo! homepage yet

flickr.com/photos/yodelanecdotal/3620023763/


17/99

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

flickr.com/photos/thetruthabout/2831498922/


18/99

Content Optimization Enginedetermines which stories to

display at request time


19/99

Sites can be completelycustomized by the user


20/99

Popular search topics aredetermined at request time

to display up-to-date info


21/99

Random information aboutother parts of the Yahoo!

network


22/99

Apps provide more infoon-demand


23/99

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 theuser has customized the page

flickr.com/photos/thetorpedodog/458336570/


24/99

Performance rebootMany of the optimizations made on the previous homepage won't work

flickr.com/photos/thetorpedodog/458336570/


25/99

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

flickr.com/photos/hape_gera/2123257808/


26/99


Areas of Focus

Time to interactivity

Ajax Responsiveness

Perceived performance


27/99

The time to interactivity is the

time between the initial pagerequest and when the user can

complete an action


28/99

Time to Interactivity

For most pages, happens betweenDOMContentLoaded and onload

Can actually happen earlier

Links work, forms can be submitted even whilethe page is loading

As long as JavaScript isn't running

Difficult to measure


29/99

Net tab reveals some informationWhere DOMContentLoaded and onload occur


30/99

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


31/99

Goal:

Ensure interactivity byDOMContentLoaded


32/99

Simple User Actions

Clicking a headline to read the story Performing a search

Clicking on a favorite

Wait a second!You don't need JavaScriptfor any of that!

flickr.com/photos/marcoarment/2035853550/

alistapart.com/articles/understandingprogressiveenhancement


33/99

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

the faster the user can complete an action


34/99

The page is very functionaleven without JavaScript


35/99

Not relying on JavaScript for

everything allows us anopportunity to deliver what

appears to be a faster experience


36/99

JavaScriptLoading onto the page without pain


37/99

Traditional thinking was put scripts at the bottom


38/99

flickr.com/photos/kartik_m/2724121901/


39/99

Our results were upsetting

Putting scripts at the bottom actually caused other problems

flickr.com/photos/kartik_m/2724121901/


40/99

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 slowerconnections

Page was unresponsive for 30s or more

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


41/99

In order to fix things, we had to get lazy


42/99

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


43/99

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

function loadScript(url, callback){


44/99

function loadScript(url, callback){

var script = document.createElement("script")

script.type = "text/javascript";

if (script.readyState){ //IE

script.onreadystatechange = function(){

if (script.readyState == "loaded" ||

script.readyState == "complete"){

script.onreadystatechange = null;

callback();}

};

} else { //Others

script.onload = function(){

callback();};

}

script.src = url;

document.getElementsByTagName("head")[0].appendChild(script);

}

Dynamically loaded scriptsdon't block page load


45/99

loadScript(filename, function(){

//initialization

});


46/99

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

{

Y.use("*");

Y.ModulePlatform.init(Y.dali.config, true);

}});


47/99

Everything else

First script file

653/


48/99

flickr.com

/photos/nateandmiranda/26253996

Results

Page is interactive assoon as each sectionis rendered

Reduced onload time

to ~2.5s on fastconnections

Slow connection

experience vastlyimproved


49/99

JavaScript Loads

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

Everything necessary for core JavaScriptinteractivity

Ajax responses can specify more JavaScript isneeded to handle the response

True, on-demand loading


50/99

Page FlushingGetting data out to the browser fast


51/99

Traditional thinking is to flush after


52/99

Flushing after ensures CSSstarts to download as quickly aspossible

But the user still sees a blank screen

until the rest of the HTML is renderedto the browser

Solution: flush after major sectionsof the page have been output

flickr.com/photos/conskeptical/354951028/


53/99

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


54/99

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


55/99

Flush

Flush


56/99


57/99


58/99


59/99

(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


60/99


Areas of Focus

Time to interactivity Ajax Responsiveness



61/99

The biggest area of concern regarding Ajaxperformance was around the apps. For our veryfirst test, it sometimes took as long as 7 seconds

to load a single app.


62/99

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


63/99

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

the request and the time it receives the response

start stop

roundtrip


64/99

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

start stop

roundtrip parse


65/99

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

content can be used

start stop

roundtrip parse download


66/99

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

start stop

roundtrip parse download render


67/99

Where We Started


68/99

Fixing Roundtrip TimeWhat's taking so damn long?


69/99

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


70/99

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.


71/99

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


72/99


73/99

{

"msg": "Hello world!",

"day": 6,

"found": true,

}

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

{

"html":"


74/99

id=\"default-p_26583360-bd\" class=\"bd type_pacontainertype_pacontainer_default\">Finance \t\n \t\tOptions\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\tHelp\n\t\t\t\t\t\n\t\t\t \n\t\t \n Go to: Finance\n Overview MyPortfolios \n \n \n \n \n \n \n

Sat, Jun 12, 201010:10am PDT\n \n \n \n \n"

}

Very inefficient for large HTML strings

Escapement adds a lot of extra bytes


75/99

The larger the JSON string, thelonger it took to parse

Keep in mind there was no native browser JSON parsing when webegan 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


76/99

Shrinking the size of the HTML by

deferring the ad helped

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


77/99

[{

"msg": "Hello world!",

"day": 6,

"found": true,

}]

=====

Yahoo!

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

text

flickr.com/photos/mattymatt/3017263513/


78/99

Results were goodBut then native JSON parsing hit and a lot of problems went away


79/99

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


80/99

On-demand JavaScript/CSSdownloading hurt app loading

time

Intended to decrease page load time, and did but left us with thisside effect


81/99

Waiting until the user takesan action ensures paying thecost of download

What if you knew which

apps the user was going touse?

Solution: predictive fetch ofJavaScript/CSS beforeyouneed it

flickr.com/photos/mcgraths/3248483447/


82/99

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


83/99

After onload

onload


84/99

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


85/99

Actually, render time was okay


86/99

Results


87/99


Areas of Focus

Time to interactivity Ajax Responsiveness



88/99

Don't underestimate the powerof perception


89/99

Initially, the new page wasactually slower to load than the

previous

To be expected a lot more JavaScript and CSS


90/99

Blank space is badMakes it seem like nothing is happening

dj i i


91/99

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


92/99

Initially, apps werecompletely blank whileloading (seemed slow)


93/99

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


94/99

In the end, user testing showed that

perceived performance of the new pagewas the same as on the old page


95/99

Wrap Up

L L d


96/99

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

A hi t


97/99

flickr.com/photos/ficken/1813744832/

Achievements

Reduced time to onload from ~5s to ~2.5sActually better than previous version

Very short time to interactivity

Reduced time to open apps from ~7s to ~2s

Maintained perception of speed from previousversion


98/99

Questions?

Etcetera


99/99

Etcetera

My blog: www.nczonline.net

My email: [email protected]

Twitter: @slicknet

Performance Yahoo Homepage - By Nicholas Zakas

Documents

Transcript of Performance Yahoo Homepage - By Nicholas Zakas