Nicholas' Performance Talk at Google

Nicholas Zakas
Nicholas ZakasFront End Guy at Box
Nicholas' Performance Talk
         at Google




                            Nicholas C. Zakas
         Principal Front End Engineer, Yahoo!
                 Google, September 29, 2010
Who's this guy?




         Principal Front End      Contributor,
              Engineer         Creator of YUI Test




Author         Lead Author     Contributor           Lead Author
Part 1: JavaScript Performance
JavaScript performance
        directly
affects user experience
Nicholas' Performance Talk at Google
The UI Thread
The brains of the operation
The browser UI thread is responsible for
both UI updates and JavaScript execution
           Only one can happen at a time
Jobs for UI updates and JavaScript execution are
  added to a UI queue if the UI thread is busy
         Each job must wait in line for its turn to execute
<button id="btn" style="font-size: 30px; padding: 0.5em
    1em">Click Me</button>

<script type="text/javascript">
window.onload = function(){
   document.getElementById("btn").onclick = function(){
       //do something
   };
};
</script>
Before Click

UI Thread



time
                           UI Queue
When Clicked

UI Thread



time
                           UI Queue

                             UI Update

                             onclick

                             UI Update
When Clicked

UI Thread

 UI Update

time
                                   UI Queue

                                     onclick
        Draw down state
                                     UI Update
When Clicked

UI Thread

 UI Update   onclick

time
                              UI Queue

                                UI Update
When Clicked

UI Thread

 UI Update   onclick       UI Update

time
                                       UI Queue


               Draw up state
No UI updates while JavaScript is
           executing
JavaScript May Cause UI Update
<button id="btn" style="font-size: 30px; padding: 0.5em
    1em">Click Me</button>

<script type="text/javascript">
window.onload = function(){
   document.getElementById("btn").onclick = function(){
       var div = document.createElement(“div”);
       div.className = “tip”;
       div.innerHTML = “You clicked me!”;
       document.body.appendChild(div);
   };
};
</script>
A UI update must use the latest
        info available
Long-running JavaScript
          =
   Unresponsive UI
Responsive UI

UI Thread

 UI Update   JavaScript   UI Update

time
Unresponsive UI

UI Thread

 UI Update       JavaScript    UI Update

time
The longer JavaScript runs,
the worse the user experience
How Long Is Too Long?
“0.1 second [100ms] is about the limit for
having the user feel that the system is reacting
instantaneously, meaning that no special
feedback is necessary except to display the
result.”
                                  - Jakob Nielsen
Translation:
 No single JavaScript job should
execute for more than 100ms to
     ensure a responsive UI
Recommendation:
Limit JavaScript execution to no more
              than 50ms




        measured on IE6 :)
Runtime Techniques
Ways to ensure JavaScript doesn't run away
function processArray(items, process, callback){
    for (var i=0,len=items.length; i < len; i++){
        process(items[i]);
    }
    callback();
}
Technique #1: Timers
JavaScript Timers
• Created using setTimeout()
• Schedules a new JavaScript execution job for
  some time in the future
• When the delay is up, the job is added to the
  UI queue
   – Note: This does not guarantee execution
     after the delay, just that the job is added
     to the UI queue and will be executed when
     appropriate
JavaScript Timers
• For complex processing, split up into timed
  functionality
• Use timers to delay some processing for later
function timedProcessArray(items, process, callback){
    //create a clone of the original
     var todo = items.concat();
    setTimeout(function(){
        var start = +new Date();
        do {
              process(todo.shift());
        } while (todo.length > 0 &&
               (+new Date() - start < 50));
        if (todo.length > 0){
              setTimeout(arguments.callee, 25);
        } else {
              callback(items);
        }
    }, 25);
}
When Clicked

UI Thread



time
                           UI Queue

                             UI Update

                             onclick

                             UI Update
When Clicked

UI Thread

 UI Update

time
                            UI Queue

                              onclick

                              UI Update
When Clicked

UI Thread

 UI Update   onclick




time
                                  UI Queue

                                    UI Update
When Clicked

UI Thread

 UI Update   onclick   UI Update

time
                                   UI Queue
After 25ms

UI Thread

 UI Update   onclick   UI Update

time
                                    UI Queue

                                      JavaScript
After 25ms

UI Thread

 UI Update   onclick   UI Update   JavaScript




time
                                                UI Queue
After Another 25ms

UI Thread

 UI Update   onclick   UI Update   JavaScript




time
                                                UI Queue

                                                  JavaScript
After Another 25ms

UI Thread

 UI Update   onclick   UI Update   JavaScript         JavaScript




time
                                                UI Queue
Technique #2: Web Workers
Nicholas' Performance Talk at Google
Web Workers
• Asynchronous JavaScript execution
• Execution happens in a separate process
   – Not on the UI thread = no UI delays
• Data-driven API
   – Data is serialized when sending data into
     or out of Worker
   – No access to DOM, BOM
   – Completely separate execution
     environment
//in page
var worker = new Worker("process.js");
worker.onmessage = function(event){
     useData(event.data);
};
worker.postMessage(values);



//in process.js
self.onmessage = function(event){
     var items = event.data;
     for (var i=0,len=items.length; i < len; i++){
         process(items[i]);
     }
     self.postMessage(items);
};
When Clicked

UI Thread



time
                           UI Queue

                             UI Update

                             onclick

                             UI Update
When Clicked

UI Thread

 UI Update

time
                            UI Queue

                              onclick

                              UI Update
When Clicked

UI Thread

 UI Update   onclick




time
                                  UI Queue

                                    UI Update
When Clicked

UI Thread

 UI Update   onclick




time

             Worker Thread        UI Queue

                                    UI Update
When Clicked

UI Thread

 UI Update   onclick       UI Update

time

             Worker Thread             UI Queue

                       JavaScript
Worker Thread Complete

UI Thread

 UI Update    onclick   UI Update

time
                                    UI Queue

                                     onmessage
Worker Thread Complete

UI Thread

 UI Update    onclick   UI Update   onmessage




time
                                           UI Queue
Support for Web Workers




3.5 4.0    4.0      ?   10.6
Part 2: Yahoo! Homepage
      Performance
The Challenge:
Create a new Yahoo! homepage*


     *add a ton of new functionality
    **without sacrificing performance
By the Numbers



     345                           110
     million                       million
unique users per month       unique users per month
      worldwide                  in United States


                   (no pressure)
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
other parts of the Yahoo!
network
Apps provide more info
on-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
Areas of Focus
• Time to interactivity
• Ajax Responsiveness




                          flickr.com/photos/hape_gera/2123257808/
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 information
     Where DOMContentLoaded and onload occur
YSlow reports onload time
Useful, 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/
alistapart.com/articles/understandingprogressiveenhancement




Progressive Enhancement FTW!
    The more tasks that don't require JavaScript,
     the faster the user can complete an action
The page is very functional
even without JavaScript
Not relying on JavaScript for
    everything allows us an
  opportunity to deliver what
appears to be a faster experience
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>
flickr.com/photos/kartik_m/2724121901/




        Our results were upsetting
Putting scripts at the bottom actually caused other problems
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
flickr.com/photos/19613690@N05/3687563687/




In order to fix things, we had to get lazy
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();
        };                                 Dynamically loaded scripts
    }                                      don't block page load

    script.src = url;
    document.getElementsByTagName("head")[0].appendChild(script);
}
<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);
    }});
First script file




      Everything else
flickr.com/photos/nateandmiranda/2625399653/
       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
Areas of Focus
• Time to interactivity
• Ajax Responsiveness




                          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.
start                                                        stop




        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
roundtrip
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
roundtrip      parse
start                                                      stop




                        Parse Time
Next, the JSON response returned from the server has to be parsed
roundtrip      parse       download
start                                                       stop




            JavaScript/CSS Download Time
Each response can indicate it needs more JavaScript/CSS before the
                       content can be used
roundtrip        parse       download         render
 start                                                          stop




                          Render Time
The amount of time it takes to actually change the display via innerHTML
Where We Started
Fixing Roundtrip Time
   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.
Fixing Parse Time
 What's taking so freakin' long??
Nicholas' Performance Talk at Google
{
      "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         tt<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>ntttt<ul id="p_26583360-settings-menu"
       class="y-menu medium">ntttttnttttt<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>ntttttnttt      </ul>ntt
       </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

      Very inefficient for large HTML strings
       10:10am PDT</p>n   <table class="index-update">n
       class="med-large">n
       textindent">&nbsp;</td>n"
                                                                 <tbody>n
                                   <td class="hide-contents hide-
                                                                                <tr


}
                     Escapement 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
flickr.com/photos/mattymatt/3017263513/




                 Results were good
But then native JSON parsing hit and a lot of problems went away
Fixing Download Time
  What's taking so (*&#$Q@! long???
On-demand JavaScript/CSS
   downloading hurt app loading
              time
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
After onload




           onload
Fixing Render Time
WTF is taking so (*&#$Q@! long?!?!?
Actually, render time was okay
Results
In the end, user testing showed that
perceived performance of the new page
   was the same as on the old page
Recap
Responsive UI

UI Thread

 UI Update   JavaScript   UI Update

time
Unresponsive UI

UI Thread

 UI Update       JavaScript    UI Update

time
Avoid Slow Loading JavaScript
• Put scripts at the bottom
• Concatenate scripts into as few files as
  possible
• Choose the right way to load your scripts
   – Dynamically created scripts
   – Deferred scripts
   – Asynchronous scripts
Avoid Slow JavaScript
• Don't allow JavaScript to execute for more
  than 50ms
• Break up long JavaScript processes using:
   – Timers
   – Web Workers
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
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




flickr.com/photos/ficken/1813744832/
Questions?
Etcetera
• My blog:
  www.nczonline.net
• My email:
  nzakas@yahoo-inc.com
• Twitter:
  @slicknet
• These Slides:
  http://slideshare.net/nzakas/
Creative Commons Images Used
•   http://www.flickr.com/photos/hippie/2406411610/
•   http://www.flickr.com/photos/55733754@N00/3325000738/
•   http://www.flickr.com/photos/eurleif/255241547/
•   http://www.flickr.com/photos/off_the_wall/3444915939/
•   http://www.flickr.com/photos/wwarby/3296379139/
•   http://www.flickr.com/photos/derekgavey/4358797365/
•   http://www.flickr.com/photos/mulad/286641998/
1 of 122

More Related Content

What's hot(20)

Viewers also liked(8)

JavaScript Variable PerformanceJavaScript Variable Performance
JavaScript Variable Performance
Nicholas Zakas5.2K views
High Performance JavaScript 2011High Performance JavaScript 2011
High Performance JavaScript 2011
Nicholas Zakas10.1K views
Speed Up Your JavaScriptSpeed Up Your JavaScript
Speed Up Your JavaScript
Nicholas Zakas17.6K views
Maintainable JavaScript 2012Maintainable JavaScript 2012
Maintainable JavaScript 2012
Nicholas Zakas90.8K views
Writing Efficient JavaScriptWriting Efficient JavaScript
Writing Efficient JavaScript
Nicholas Zakas88.3K views

Similar to Nicholas' Performance Talk at Google(20)

More from Nicholas Zakas(8)

The Pointerless WebThe Pointerless Web
The Pointerless Web
Nicholas Zakas7K views
Maintainable JavaScript 2011Maintainable JavaScript 2011
Maintainable JavaScript 2011
Nicholas Zakas12.1K views
Maintainable JavaScriptMaintainable JavaScript
Maintainable JavaScript
Nicholas Zakas10.2K views
The New Yahoo! Homepage and YUI 3The New Yahoo! Homepage and YUI 3
The New Yahoo! Homepage and YUI 3
Nicholas Zakas4.7K views

Recently uploaded(20)

Web Dev - 1 PPT.pdfWeb Dev - 1 PPT.pdf
Web Dev - 1 PPT.pdf
gdsczhcet49 views
ThroughputThroughput
Throughput
Moisés Armani Ramírez31 views

Nicholas' Performance Talk at Google

  • 1. Nicholas' Performance Talk at Google Nicholas C. Zakas Principal Front End Engineer, Yahoo! Google, September 29, 2010
  • 2. Who's this guy? Principal Front End Contributor, Engineer Creator of YUI Test Author Lead Author Contributor Lead Author
  • 3. Part 1: JavaScript Performance
  • 4. JavaScript performance directly affects user experience
  • 6. The UI Thread The brains of the operation
  • 7. The browser UI thread is responsible for both UI updates and JavaScript execution Only one can happen at a time
  • 8. Jobs for UI updates and JavaScript execution are added to a UI queue if the UI thread is busy Each job must wait in line for its turn to execute
  • 9. <button id="btn" style="font-size: 30px; padding: 0.5em 1em">Click Me</button> <script type="text/javascript"> window.onload = function(){ document.getElementById("btn").onclick = function(){ //do something }; }; </script>
  • 11. When Clicked UI Thread time UI Queue UI Update onclick UI Update
  • 12. When Clicked UI Thread UI Update time UI Queue onclick Draw down state UI Update
  • 13. When Clicked UI Thread UI Update onclick time UI Queue UI Update
  • 14. When Clicked UI Thread UI Update onclick UI Update time UI Queue Draw up state
  • 15. No UI updates while JavaScript is executing
  • 16. JavaScript May Cause UI Update <button id="btn" style="font-size: 30px; padding: 0.5em 1em">Click Me</button> <script type="text/javascript"> window.onload = function(){ document.getElementById("btn").onclick = function(){ var div = document.createElement(“div”); div.className = “tip”; div.innerHTML = “You clicked me!”; document.body.appendChild(div); }; }; </script>
  • 17. A UI update must use the latest info available
  • 18. Long-running JavaScript = Unresponsive UI
  • 19. Responsive UI UI Thread UI Update JavaScript UI Update time
  • 20. Unresponsive UI UI Thread UI Update JavaScript UI Update time
  • 21. The longer JavaScript runs, the worse the user experience
  • 22. How Long Is Too Long? “0.1 second [100ms] is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.” - Jakob Nielsen
  • 23. Translation: No single JavaScript job should execute for more than 100ms to ensure a responsive UI
  • 24. Recommendation: Limit JavaScript execution to no more than 50ms measured on IE6 :)
  • 25. Runtime Techniques Ways to ensure JavaScript doesn't run away
  • 26. function processArray(items, process, callback){ for (var i=0,len=items.length; i < len; i++){ process(items[i]); } callback(); }
  • 28. JavaScript Timers • Created using setTimeout() • Schedules a new JavaScript execution job for some time in the future • When the delay is up, the job is added to the UI queue – Note: This does not guarantee execution after the delay, just that the job is added to the UI queue and will be executed when appropriate
  • 29. JavaScript Timers • For complex processing, split up into timed functionality • Use timers to delay some processing for later
  • 30. function timedProcessArray(items, process, callback){ //create a clone of the original var todo = items.concat(); setTimeout(function(){ var start = +new Date(); do { process(todo.shift()); } while (todo.length > 0 && (+new Date() - start < 50)); if (todo.length > 0){ setTimeout(arguments.callee, 25); } else { callback(items); } }, 25); }
  • 31. When Clicked UI Thread time UI Queue UI Update onclick UI Update
  • 32. When Clicked UI Thread UI Update time UI Queue onclick UI Update
  • 33. When Clicked UI Thread UI Update onclick time UI Queue UI Update
  • 34. When Clicked UI Thread UI Update onclick UI Update time UI Queue
  • 35. After 25ms UI Thread UI Update onclick UI Update time UI Queue JavaScript
  • 36. After 25ms UI Thread UI Update onclick UI Update JavaScript time UI Queue
  • 37. After Another 25ms UI Thread UI Update onclick UI Update JavaScript time UI Queue JavaScript
  • 38. After Another 25ms UI Thread UI Update onclick UI Update JavaScript JavaScript time UI Queue
  • 39. Technique #2: Web Workers
  • 41. Web Workers • Asynchronous JavaScript execution • Execution happens in a separate process – Not on the UI thread = no UI delays • Data-driven API – Data is serialized when sending data into or out of Worker – No access to DOM, BOM – Completely separate execution environment
  • 42. //in page var worker = new Worker("process.js"); worker.onmessage = function(event){ useData(event.data); }; worker.postMessage(values); //in process.js self.onmessage = function(event){ var items = event.data; for (var i=0,len=items.length; i < len; i++){ process(items[i]); } self.postMessage(items); };
  • 43. When Clicked UI Thread time UI Queue UI Update onclick UI Update
  • 44. When Clicked UI Thread UI Update time UI Queue onclick UI Update
  • 45. When Clicked UI Thread UI Update onclick time UI Queue UI Update
  • 46. When Clicked UI Thread UI Update onclick time Worker Thread UI Queue UI Update
  • 47. When Clicked UI Thread UI Update onclick UI Update time Worker Thread UI Queue JavaScript
  • 48. Worker Thread Complete UI Thread UI Update onclick UI Update time UI Queue onmessage
  • 49. Worker Thread Complete UI Thread UI Update onclick UI Update onmessage time UI Queue
  • 50. Support for Web Workers 3.5 4.0 4.0 ? 10.6
  • 51. Part 2: Yahoo! Homepage Performance
  • 52. The Challenge: Create a new Yahoo! homepage* *add a ton of new functionality **without sacrificing performance
  • 53. By the Numbers 345 110 million million unique users per month unique users per month worldwide in United States (no pressure)
  • 54. Performance is hard The best features for users aren't always the fastest flickr.com/photos/thetruthabout/2831498922/
  • 55. Content Optimization Engine determines which stories to display at request time
  • 56. Sites can be completely customized by the user
  • 57. Popular search topics are determined at request time to display up-to-date info
  • 58. Random information about other parts of the Yahoo! network
  • 59. Apps provide more info on-demand
  • 60. 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
  • 61. Areas of Focus • Time to interactivity • Ajax Responsiveness flickr.com/photos/hape_gera/2123257808/
  • 62. The time to interactivity is the time between the initial page request and when the user can complete an action
  • 63. 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
  • 64. Net tab reveals some information Where DOMContentLoaded and onload occur
  • 65. YSlow reports onload time Useful, but doesn't really determine time to interactivity
  • 66. Goal: Ensure interactivity by DOMContentLoaded
  • 67. 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/
  • 68. alistapart.com/articles/understandingprogressiveenhancement Progressive Enhancement FTW! The more tasks that don't require JavaScript, the faster the user can complete an action
  • 69. The page is very functional even without JavaScript
  • 70. Not relying on JavaScript for everything allows us an opportunity to deliver what appears to be a faster experience
  • 71. JavaScript Loading onto the page without pain
  • 72. Traditional thinking was put scripts at the bottom
  • 73. <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>
  • 74. flickr.com/photos/kartik_m/2724121901/ Our results were upsetting Putting scripts at the bottom actually caused other problems
  • 75. 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
  • 79. 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(); }; Dynamically loaded scripts } don't block page load script.src = url; document.getElementsByTagName("head")[0].appendChild(script); }
  • 80. <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>
  • 81. Y.Get.script(YUI.presentation.lazyScriptList, { onSuccess: function() { Y.use("*"); Y.ModulePlatform.init(Y.dali.config, true); }});
  • 82. First script file Everything else
  • 83. flickr.com/photos/nateandmiranda/2625399653/ 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
  • 84. 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
  • 85. Areas of Focus • Time to interactivity • Ajax Responsiveness flickr.com/photos/hape_gera/2123257808/
  • 86. 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.
  • 87. start stop 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
  • 88. roundtrip 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
  • 89. roundtrip parse start stop Parse Time Next, the JSON response returned from the server has to be parsed
  • 90. roundtrip parse download start stop JavaScript/CSS Download Time Each response can indicate it needs more JavaScript/CSS before the content can be used
  • 91. roundtrip parse download render start stop Render Time The amount of time it takes to actually change the display via innerHTML
  • 93. Fixing Roundtrip Time What's taking so damn long?
  • 94. 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
  • 95. “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.
  • 96. Fixing Parse Time What's taking so freakin' long??
  • 98. { "msg": "Hello world!", "day": 6, "found": true, } JSON is super-efficient for transporting numbers, Booleans, simple strings, objects, and arrays
  • 99. { "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 tt<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>ntttt<ul id="p_26583360-settings-menu" class="y-menu medium">ntttttnttttt<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>ntttttnttt </ul>ntt </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 Very inefficient for large HTML strings 10:10am PDT</p>n <table class="index-update">n class="med-large">n textindent">&nbsp;</td>n" <tbody>n <td class="hide-contents hide- <tr } Escapement adds a lot of extra bytes
  • 100. 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
  • 101. Shrinking the size of the HTML by deferring the ad helped But we still wanted to see if we could eek out better gains
  • 102. [{ "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
  • 103. flickr.com/photos/mattymatt/3017263513/ Results were good But then native JSON parsing hit and a lot of problems went away
  • 104. Fixing Download Time What's taking so (*&#$Q@! long???
  • 105. On-demand JavaScript/CSS downloading hurt app loading time Intended to decrease page load time, and did – but left us with this side effect
  • 106. 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/
  • 107. After page load, we start to download JavaScript/CSS for the apps on the page
  • 108. After onload onload
  • 109. Fixing Render Time WTF is taking so (*&#$Q@! long?!?!?
  • 112. In the end, user testing showed that perceived performance of the new page was the same as on the old page
  • 113. Recap
  • 114. Responsive UI UI Thread UI Update JavaScript UI Update time
  • 115. Unresponsive UI UI Thread UI Update JavaScript UI Update time
  • 116. Avoid Slow Loading JavaScript • Put scripts at the bottom • Concatenate scripts into as few files as possible • Choose the right way to load your scripts – Dynamically created scripts – Deferred scripts – Asynchronous scripts
  • 117. Avoid Slow JavaScript • Don't allow JavaScript to execute for more than 50ms • Break up long JavaScript processes using: – Timers – Web Workers
  • 118. 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
  • 119. 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 flickr.com/photos/ficken/1813744832/
  • 121. Etcetera • My blog: www.nczonline.net • My email: nzakas@yahoo-inc.com • Twitter: @slicknet • These Slides: http://slideshare.net/nzakas/
  • 122. Creative Commons Images Used • http://www.flickr.com/photos/hippie/2406411610/ • http://www.flickr.com/photos/55733754@N00/3325000738/ • http://www.flickr.com/photos/eurleif/255241547/ • http://www.flickr.com/photos/off_the_wall/3444915939/ • http://www.flickr.com/photos/wwarby/3296379139/ • http://www.flickr.com/photos/derekgavey/4358797365/ • http://www.flickr.com/photos/mulad/286641998/