Steve Souders [email protected] Even Faster Web Sites Disclaimer: This content does not...
-
Upload
michael-mackenzie -
Category
Documents
-
view
224 -
download
2
Transcript of Steve Souders [email protected] Even Faster Web Sites Disclaimer: This content does not...
Steve [email protected]
http://stevesouders.com/docs/ebay-20090416.ppt
Even Faster Web Sites
Disclaimer: This content does not necessarily reflect the opinions of my employer.
17%
83%
iGoogle, primed cache
the importance of frontend performance
9% 91%
iGoogle, empty cache
time spent on the frontend
Empty Cache
Primed Cache
www.aol.com 97% 97%
www.ebay.com 95% 81%
www.facebook.com 95% 81%
www.google.com/search
47% 0%
search.live.com/results 67% 0%
www.msn.com 98% 94%
www.myspace.com 98% 98%
en.wikipedia.org/wiki 94% 91%
www.yahoo.com 97% 96%
www.youtube.com 98% 97%April 2008
The Performance Golden Rule
80-90% of the end-user response time is spent on the frontend. Start there.
greater potential for improvement
simpler
proven to work
14 RULES
1. MAKE FEWER HTTP REQUESTS
2. USE A CDN3. ADD AN EXPIRES HEADER4. GZIP COMPONENTS5. PUT STYLESHEETS AT THE
TOP6. PUT SCRIPTS AT THE
BOTTOM7. AVOID CSS EXPRESSIONS8. MAKE JS AND CSS
EXTERNAL9. REDUCE DNS LOOKUPS10.MINIFY JS11.AVOID REDIRECTS12.REMOVE DUPLICATE
SCRIPTS13.CONFIGURE ETAGS14.MAKE AJAX CACHEABLE
Sept 2007
June 2009
Even Faster Web SitesSplitting the initial payloadLoading scripts without blockingCoupling asynchronous scripts
Positioning inline scriptsSharding dominant domainsFlushing the document early
Using iframes sparingly
Simplifying CSS Selectors
Understanding Ajax performance...Doug Crockford
Creating responsive web apps......Ben Galbraith, Dion Almaer
Writing efficient JavaScript...........Nicholas Zakas
Scaling with Comet......................Dylan Schiemann
Going beyond gzipping...............Tony Gentilcore
Optimizing images.....................Stoyan Stefanov, Nicole Sullivan
AOLeBayFacebookMySpaceWikipediaYahoo!
Why focus on JavaScript?
YouTube
scripts block
<script src="A.js"> blocks parallel downloads and rendering
What's "Cuzillion"?
http://stevesouders.com/cuzillion/?ex=10008
a tool for quickly constructing web pages to see how components interact
Open Source
http://stevesouders.com/cuzillion/
Cuzillion'cuz there are a zillion pages to check
JavaScript
Functions Executed before
onload
www.aol.com 115K 30%
www.ebay.com 183K 44%
www.facebook.com 1088K 9%
www.google.com/search
15K 45%
search.live.com/results
17K 24%
www.msn.com 131K 31%
www.myspace.com 297K 18%
en.wikipedia.org/wiki 114K 32%
www.yahoo.com 321K 13%
www.youtube.com 240K 18%
26% avg252K avg
initial payload and execution
Splitting the initial payload
split your JavaScript between what's needed to render the page and everything else
load "everything else" after the page is rendered
separate manually (Firebug); tools needed to automate this (Doloto from Microsoft)
load scripts without blocking – how?
MSNScripts and other resources downloaded in parallel! How? Secret sauce?!var p= g.getElementsByTagName("HEAD")[0];var c=g.createElement("script");c.type="text/javascript";c.onreadystatechange=n;c.onerror=c.onload=k;c.src=e;p.appendChild(c)
MSN.com: parallel scripts
Loading Scripts Without Blocking
XHR Eval
XHR Injection
Script in Iframe
Script DOM Element
Script Defer
document.write Script Tag
XHR Eval
script must have same domain as main page
must refactor script
var xhrObj = getXHRObject();xhrObj.onreadystatechange = function() { if ( xhrObj.readyState != 4 ) return; eval(xhrObj.responseText); };xhrObj.open('GET', 'A.js', true);xhrObj.send('');
http://stevesouders.com/cuzillion/?ex=10009
XHR Injectionvar xhrObj = getXHRObject();xhrObj.onreadystatechange = function() { if ( xhrObj.readyState != 4 ) return; var se=document.createElement('script'); document.getElementsByTagName('head') [0].appendChild(se); se.text = xhrObj.responseText; };xhrObj.open('GET', 'A.js', true);xhrObj.send('');
script must have same domain as main pagehttp://stevesouders.com/cuzillion/?ex=10015
Script in Iframe<iframe src='A.html' width=0 height=0 frameborder=0 id=frame1></iframe>
iframe must have same domain as main page
must refactor script:// access iframe from main pagewindow.frames[0].createNewDiv();
// access main page from iframeparent.document.createElement('div');
http://stevesouders.com/cuzillion/?ex=10012
Script DOM Elementvar se = document.createElement('script');se.src = 'http://anydomain.com/A.js';document.getElementsByTagName('head')[0].appendChild(se);
script and main page domains can differ
no need to refactor JavaScript
http://stevesouders.com/cuzillion/?ex=10010
Script Defer<script defer src='A.js'></script>
only supported in IE (just landed in FF 3.1)
script and main page domains can differ
no need to refactor JavaScript
http://stevesouders.com/cuzillion/?ex=10013
document.write Script Tagdocument.write("<script type='text/javascript' src='A.js'> <\/script>");
parallelization only works in IE
parallel downloads for scripts, nothing else
all document.writes must be in same script block
http://stevesouders.com/cuzillion/?ex=10014
browser busy indicators
browser busy indicators
good to show busy indicators when the user needs feedback
bad when downloading in the background
Loading Scripts Without Blocking
*Only other document.write scripts are downloaded in parallel (in the same script block).
and the winner is...XHR EvalXHR InjectionScript in iframeScript DOM ElementScript Defer
Script DOM ElementScript Defer
Script DOM Element
Script DOM Element (FF)Script Defer (IE)
XHR EvalXHR InjectionScript in iframeScript DOM Element (IE)
XHR InjectionXHR EvalScript DOM Element (IE)
Managed XHR InjectionManaged XHR EvalScript DOM Element
Managed XHR InjectionManaged XHR Eval
Script DOM Element (FF)Script Defer (IE)Managed XHR EvalManaged XHR Injection
Script DOM Element (FF)Script Defer (IE)Managed XHR EvalManaged XHR Injection
different domains same domains
no order
preserve order
no order
no busyshow busy
show busyno busy
preserve order
asynchronous JS example: menu.js
<script type="text/javascript">var domscript = document.createElement('script');domscript.src = "menu.js"; document.getElementsByTagName('head')
[0].appendChild(domscript);
var aExamples = [ ['couple-normal.php', 'Normal Script Src'], ['couple-xhr-eval.php', 'XHR Eval'], ... ['managed-xhr.php', 'Managed XHR'] ];
function init() { EFWS.Menu.createMenu('examplesbtn', aExamples);}
init();</script>
script DOM element approach
before
after
Loading Scripts Without Blocking
*Only other document.write scripts are downloaded in parallel (in the same script block).
!IE
what about
inlined code that depends on the script?
coupling techniques
hardcoded callback
window onload
timer
degrading script tags
script onload
technique 5: script onload<script type="text/javascript">var aExamples = [['couple-normal.php', 'Normal Script Src'], ...];
function init() { EFWS.Menu.createMenu('examplesbtn', aExamples);}
var domscript = document.createElement('script');domscript.src = "menu.js";
domscript.onloadDone = false;domscript.onload = function() { if ( ! domscript.onloadDone ) { init(); } domscript.onloadDone = true; };domscript.onreadystatechange = function() { if ( "loaded" === domscript.readyState ) { if ( ! domscript.onloadDone ) { init(); } domscript.onloadDone = true; }}
document.getElementsByTagName('head')[0].appendChild(domscript);</script>
pretty nice, medium complexity
asynchronous loading & coupling
async technique: Script DOM Elementeasy, cross-browserdoesn't ensure script order
coupling technique: script onloadfairly easy, cross-browserensures execution order for external
script and inlined code
multiple interdependent external and inline scripts:much more complex (see hidden slides)concatenate your external scripts into
one!
bad: stylesheet followed by inline script
browsers download stylesheets in parallel with other resources that follow...
...unless the stylesheet is followed by an inline script
http://stevesouders.com/cuzillion/?ex=10021
best to move inline scripts above stylesheets or below other resources
use Link, not @import
eBayMSNMySpaceWikipedia
mispositioned inline scripts
Positioning Inline Scripts
remember inline scripts carry a cost
avoid long-executing inline scripts
don't put inline scripts between stylesheets and other resources
Simplifying CSS Selectors
#toc > LI { font-weight: bold; }
combinator
simple selectors
selector
declaration block
rule
types of CSS selectors
ID selectors#toc { margin-left: 20px; } element whose ID attribute has the value "toc"
class selectors.chapter { font-weight: bold; }elements with class=chapter
type selectorsA { text-decoration: none; }all A elements in the document tree
http://www.w3.org/TR/CSS2/selector.html
types of CSS selectors
adjacent sibling selectorsH1 + #toc { margin-top: 40px; } an element with ID=toc that immediately follows
an H1
child selectors#toc > LI { font-weight: bold; }all LI elements whose parent has id="toc"
descendant selectors#toc A { color: #444; }all A elements that have id="toc" as an ancestor
types of CSS selectors
universal selectors* { font-family: Arial; }all elements
attribute selectors[href="#index"] { font-style: italic; }all elements where the href attribute is "#index"
psuedo classes and elementsA:hover { text-decoration: underline; }non-DOM behaviorothers: :visited, :link, :active, :focus, :first-child, :before, :after
writing efficient CSS
https://developer.mozilla.org/en/Writing_Efficient_CSS
"The style system matches a rule by starting with the rightmost selector and moving to the left through the rule's selectors. As long as your little subtree continues to check out, the style system will continue moving to the left until it either matches the rule or bails out because of a mismatch."
#toc > LI { font-weight: bold; }find every LI whose parent is id="toc"
#toc A { color: #444; }find every A and climb its ancestors until id="toc" or DOM root (!) is found
writing efficient CSS
1.avoid universal selectors2.don't qualify ID selectors
bad: DIV #navbar {}good: #navbar {}
3.don't qualify class selectorsbad: LI .tight {}good: .li-tight {}
4.make rules as specific as possiblebad: #navbar A {}good: .a-navbar {}
https://developer.mozilla.org/en/Writing_Efficient_CSS
writing efficient CSS
5.avoid descendant selectorsbad: UL LI A {}better: UL > LI > A {}
6.avoid tag-child selectorsbad: UL > LI > A {}best: .li-anchor {}
7.be wary of child selectors8.rely on inheritance
http://www.w3.org/TR/CSS21/propidx.html
https://developer.mozilla.org/en/Writing_Efficient_CSSDavid Hyatt4/21/2000
testing massive CSS
20K A elementsno style: controltag:
A {}
class: .a00001 {}.a20000 {}
descender: DIV DIV DIV P A.a00001 {}
child: DIV > DIV > DIV > P > A.a00001 {}
http://jon.sykes.me/153/more-css-performance-testing-pt-3
CSS performance isn't linear
IE 7 "cliff" at 18K rules
real world levels of CSS#
Rules#
elementsAvg
DepthAOL 2289 1628 13
eBay 305 588 14
Facebook 2882 1966 17
Google Search 92 552 8
Live Search 376 449 12
MSN.com 1038 886 11
MySpace 932 444 9
Wikipedia 795 1333 10
Yahoo! 800 564 13
YouTube 821 817 9
average 1033 923 12
testing typical CSS
"costly"selectors aren't always costly (at typical levels)
are these selectors "costly"?DIV DIV DIV P A.class0007 { ... }
1K rules (vs. 20K)same amount of CSS
in all test pages30 ms avg delta
http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
testing expensive selectors
1K rules (vs. 20K)same amount of CSS
in all test pages2126 ms avg delta!
truly expensive selectorA.class0007 * { ... }
compare to:DIV DIV DIV P A.class0007 { ... }
the key is the key selector – the rightmost argument
selectors to avoid
A.class0007 DIV { ... }
#id0007 > A { ... }
.class0007 [href] { ... }
DIV:first-child { ... }
reflow time vs. load time
reflow – time to apply CSS, re-layout elements, and repaint
triggered by DHTML:elem.className = "newclass";elem.style.cssText = "color: red";elem.style.padding = "8px";elem.style.display = "";
reflow can happen multiple times for long-lasting Web 2.0 apps
reflow time by browser
reflow performance varies by browser and action
"1x" is 1-6 seconds depending on browser (1K rules)
DHTML action Chr1 Chr2 FF2 FF3IE6,7 IE 8 Op Saf3 Saf4
className 1x 1x 1x 1x 1x 1x 1x 1x 1x
display none - - - - 1x - - - -
display default
1x 1x 1x 2x 1x 1x - 1x 1x
visibility hidden
1x 1x 1x 1x 1x 1x - 1x 1x
visibility visible
1x 1x 1x 1x 1x 1x - 1x 1x
padding - - 1x 2x 4x 4x - - -
width length - - 1x 2x 1x 1x - 1x -
width percent - - 1x 2x 1x 1x - 1x -
width default 1x - 1x 2x 1x 1x - 1x -
background - - 1x 1x 1x - - - -
font-size 1x 1x 1x 2x 1x 1x - 1x 1x
Simplifying CSS Selectors
efficient CSS comes at a cost – page weight
focus optimization on selectors where the key selector matches many elements
reduce the number of selectors
1. long HTML doc response
2. flush (good)
3. inline script blocks .jsvar pageName='HomePagePortal';
4. scripts block
5. ads .js non-blocking (good)
6. 26 bg images – no sprites
7. sharded domains – pics & rtm (good)
8. compress images by 20%
9. thumbs load slowly – HTTP/1.0?
10. remove ETags (?)
11. ~40 inefficient CSS selectors.playgrnd * {}
1
9
76
54
32
4
4 4
8
www.ebay.com
1. long HTML doc response
2. flush (good)
3. inline script blocks .js
4. scripts block
5. 44 bg images – use sprites
6. sharded domains
7. compress images by 20%
8. thumbs load slowly – HTTP/1.0?
9. remove ETags (?)
10. ~40 inefficient CSS selectors.playgrnd * {}
1
8
65
432
7
shop.ebay.com/ items/Nike
http://cgi.ebay.com/ws/eBayISAPI.dll?
ViewItemNext&Item=2603809159111. long HTML doc response
2. flush (good)
3. put stylesheets above scripts
4. inline script blocks .js
5. scripts block, concatenate scripts, minify
6. sharded domains – pics & rtm (good)
7. remove ETags (?)
8. ~15 inefficient CSS selectors.overlay .contentbox * {}
1
6
5
324
5
3
takeaways
focus on the frontend
run YSlow: http://developer.yahoo.com/yslow
speed matters
impact on revenue
Google:
Yahoo:
Amazon:
1 http://home.blarg.net/~glinden/StanfordDataMining.2006-11-29.ppt2 http://www.slideshare.net/stoyan/yslow-20-presentation
+500 ms -20% traffic1
+400 ms -5-9% full-page traffic2
+100 ms -1% sales1
cost savings
hardware – reduced load
bandwidth – reduced response size
http://billwscott.com/share/presentations/2008/stanford/HPWP-RealWorld.pdf
if you want better user experience more revenue reduced operating expenses
the strategy is clear
Even Faster Web Sites
Steve [email protected]
http://stevesouders.com/docs/ebay-20090416.ppt