Yahoo! Homepage Yahoo! Homepage Nicholas C. Zakas Nicholas C. - - PowerPoint PPT Presentation
flickr.com/photos/eyesplash/4268550236/ Performance on the Performance on the Yahoo! Homepage Yahoo! Homepage Nicholas C. Zakas Nicholas C. Zakas Principal Front End Engineer, Yahoo! Principal Front End Engineer, Yahoo! Velocity, June 24
Performance on the Performance on the
Nicholas C. Zakas Nicholas C. Zakas Principal Front End Engineer, Yahoo! Principal Front End Engineer, Yahoo! Velocity, June 24 2010 Velocity, June 24 2010
flickr.com/photos/eyesplash/4268550236/
*add a ton of new functionality **without sacrificing performance
unique users per month worldwide
unique users per month in United States (no pressure)
We strapped ourselves in, believing we could make the fastest Yahoo! homepage yet
flickr.com/photos/yodelanecdotal/3620023763/
Performance is hard
The best features for users aren't always the fastest
flickr.com/photos/thetruthabout/2831498922/
Content Optimization Engine determines which stories to display at request time
Sites can be completely customized by the user
Popular search topics are determined at request time to display up-to-date info
Random information about
network
Apps provide more info
– Hard to know which images will be on the page together
– With content constantly changing, getting images into cache doesn't help much
– 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/
flickr.com/photos/hape_gera/2123257808/
DOMContentLoaded and onload – Can actually happen earlier
the page is loading – As long as JavaScript isn't running
Where DOMContentLoaded and onload occur
Useful, but doesn't really determine time to interactivity
Wait a second! You don't need JavaScript for any of that!
flickr.com/photos/marcoarment/2035853550/
The more tasks that don't require JavaScript, the faster the user can complete an action
alistapart.com/articles/understandingprogressiveenhancement
The page is very functional even without JavaScript
Loading onto the page without pain
Traditional thinking was put scripts at the bottom
<html> <head> <!-- head contents --> </head> <body> <!-- body contents --> <script type="text/javascript" src="yourfile.js"> </script> <script type="text/javascript" src="yourfile2.js"> </script> </body> </html>
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/
– User can't interact while JavaScript is being fetched/parsed/executed
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/
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 scripts don't block page load
<html> <head> <!-- head contents --> </head> <body> <!-- body contents --> <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
flickr.com/photos/nateandmiranda/2625399653/
soon as each section is rendered
to ~2.5s on fast connections
experience vastly improved
– Everything necessary for core JavaScript interactivity
needed to handle the response – True, on-demand loading
Getting 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
flickr.com/photos/conskeptical/354951028/
<div class="doc"> <div class="hd"> </div> <!-- flushing here does nothing --> <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> <!-- flushing here causes the head to render --> <div class=”bd”> </div>
Removing page-level wrapper <div> allows the head to render as quickly as possible
Flush Flush
Even when the browser can't render yet, it can still start to download other resources such as images
flickr.com/photos/hape_gera/2123257808/
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 Time
The first step is the amount of time between when the browser sends the request and the time it receives the response
start stop
roundtrip
Parse Time
Next, the JSON response returned from the server has to be parsed
start stop
roundtrip parse
JavaScript/CSS Download Time
Each response can indicate it needs more JavaScript/CSS before the content can be used
start stop
roundtrip parse download
Render Time
The amount of time it takes to actually change the display via innerHTML
start stop
roundtrip parse download render
What's taking so damn long?
The right-side ads were a roundtrip issue
The server-side ad call took extra time plus the ad markup represented 50-60% of the returned markup
“Fixing” the ad
Entire right column now renders in an iframe. This defers the ad call until after the app has been loaded in the browser, saving both server time for app rendering and bytes in the response.
What'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 strings
Escapement adds a lot of extra bytes
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
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/
What's taking so (*&#$Q@! long???
Intended 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 to download JavaScript/CSS for the apps on the page
WTF is taking so (*&#$Q@! long?!?!?
flickr.com/photos/hape_gera/2123257808/
To be expected – a lot more JavaScript and CSS
Makes it seem like nothing is happening
– Progressive rendering avoids a lot of blank space
– Ensure it doesn't block rendering
– Decrease time to interactivity
Initially, apps were completely blank while loading (seemed slow)
We changed it to a pseudo- loaded state, which made loading seem faster
experience – Allows for delayed load of JavaScript
blocking manner
– Get more insight by looking at the parts
flickr.com/photos/ficken/1813744832/
– Actually better than previous version
version
www.nczonline.net
nzakas@yahoo-inc.com
@slicknet