Presentation is loading. Please wait.

Presentation is loading. Please wait.

High Performance Web Sites 14 rules for faster pages

Similar presentations


Presentation on theme: "High Performance Web Sites 14 rules for faster pages"— Presentation transcript:

1 High Performance Web Sites 14 rules for faster pages
Steve Souders Chief Performance Yahoo!

2 Exceptional Performance
quantify and improve the performance of all Yahoo! products worldwide center of expertise build tools, analyze data gather, research, and evangelize best practices

3 Scope performance breaks into two categories
response time efficiency current focus is response time of web products coming up next: mobile, backend

4 The Importance of Frontend Performance
Backend = 5% Frontend = 95% Even primed cache, frontend = 88%

5 Time Spent on the Frontend
Empty Cache Primed Cache amazon.com 82% 86% aol.com 94% cnn.com 81% 92% ebay.com 98% google.com 64% msn.com 97% 95% myspace.com 96% wikipedia.org 80% 88% yahoo.com youtube.com

6 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 If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

7 Agenda Performance Research 14 Rules (plus more) Case Studies
Evangelism Live Analysis

8 Performance Research If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

9 Browser Cache Experiment
Add an image to the page: Expires: Thu, 15 Apr :00:00 GMT Last-Modified: Wed, 28 Sep :49:57 GMT # users with at least one 200 response total # unique users Percentage of users with an empty cache? Percentage of page views with an empty cache? # of 200 responses total # responses

10 Browser Cache Expt Results
users with empty cache page views with empty cache 40-60% ~20% On the first day of the experiment, no one had these images cached so the empty cache percentage was 100%. As the days passed more users had the images cached, so the percentages dropped until at some point it reached a constant steady state.

11 Experiment Takeaways The empty cache user experience is more prevalent than you think! Optimize for both primed cache and empty cache experience. Strategies such as combining scripts, stylesheets, or images reduce the number of HTTP requests for both an empty and a full cache page view. Configuring components to have an Expires header with a date in the future reduces the number of HTTP requests for only the full cache page view.

12 Impact of Cookies on Response Time
Cookie Size Time Delta 0 bytes 78 ms 0 ms 500 bytes 79 ms +1 ms 1000 bytes 94 ms +16 ms 1500 bytes 109 ms +31 ms 2000 bytes 125 ms +47 ms 2500 bytes 141 ms +63 ms 3000 bytes 156 ms +78 ms The performance team at Yahoo! ran an experiment to measure the impact of retrieving a document with various cookie sizes. The experiment measured a static HTML document with no elements in the page. The primary variable in the experiment was the cookie size. We ran the experiment using a test harness that fetches a set of URLs repeatedly while measuring how long it takes to load the page on DSL. These results highlight the importance of keeping the size of cookies as low as possible to minimize the impact on the user’s response time. A 3000 byte cookie, or multiple cookies that total 3000 bytes, could add as much as an 80 ms delay for users on DSL bandwidth speeds. The delay is even worse for users on dial-up. keep sizes low 80 ms delay dialup users

13 Experiment Takeaways eliminate unnecessary cookies
keep cookie sizes low set cookies at appropriate domain level set Expires date appropriately earlier date or none removes cookie sooner Setting cookies at the appropriate path and domain is just as important as the size of the cookie, if not more. A cookie set at the .yahoo.com domain impacts the response time for every Yahoo! page in the .yahoo.com domain that a user visits. Eliminate unnecessary cookies. Keep cookie sizes as low as possible to minimize the impact on the user response time. Be mindful of setting cookies at the appropriate domain level so other sub-domains are not affected. Set an Expires date appropriately. An earlier Expires date or none removes the cookie sooner, improving the user response time.

14 Parallel Downloads Two in parallel Four in parallel Eight in parallel
If a web page evenly distributed its components across two hostnames, the overall response time would be about twice as fast. The HTTP requests would look as shown in Figure 2, with four components downloaded in parallel (two per hostname). The horizontal width of the box is the same, to give a visual cue as to how much faster this page loads. Limiting parallel downloads to two per hostname is a guideline. By default, both Internet Explorer and Firefox follow the guideline, but users can override this default behavior. Internet Explorer stores the value in the Registry Editor. (See Microsoft Help and Support.) Firefox’s setting is controlled by the network.http.max-persistent-connections-per-server setting, accessible in the about:config page. It’s interesting to note that for HTTP/1.0, Firefox’s default is to download eight components in parallel per hostname. Figure 3 shows what it would look like to download these ten images if Firefox’s HTTP/1.0 settings are used. It’s even faster than Figure 2, and we didn’t have to split the images across two hostnames. Instead of relying on users to modify their browser settings, front-end engineers could simply use CNAMEs (DNS aliases) to split their components across multiple hostnames.

15 Maximizing Parallel Downloads
response time (seconds) In our experiment, we vary the number of aliases: 1, 2, 4, 5, and 10. This increases the number of parallel downloads to 2, 4, 8, 10, and 20 respectively. We fetch 20 smaller-sized images (36 x 36 px) and 20 medium-sized images (116 x 61 px). To our surprise, increasing the number of aliases for loading the medium-size images (116 x 61px) worsens the response times using four or more aliases. Increasing the number of aliases by more than two for smaller-sized images (36 x 36px) doesn’t make much of an impact on the overall response time. aliases

16 Maximizing Parallel Downloads
response time (seconds) On average, using two aliases is best. One possible contributor for slower response times is the amount of CPU thrashing on the client caused by increasing the number of parallel downloads. The more images that are downloaded in parallel, the greater the amount of CPU thrashing on the client. On my laptop at work, the CPU jumped from 25% usage for 2 parallel downloads to 40% usage for 20 parallel downloads. These values can vary significantly across users’ computers but is just another factor to consider before increasing the number of aliases to maximize parallel downloads. These results are for the case where the domains are already cached in the browser. In the case where the domains are not cached, the response times get significantly worse as the number of hostname aliases increases. For web pages desiring to optimize the experience for first time users, we recommend not to increase the number of domains. To optimize for the second page view, where the domains are most likely cached, increasing parallel downloads does improve response times. The choice depends on which scenario was most typical. domain names caching. Another issue to consider is that DNS lookup times vary significantly across ISPs and geographic locations. Typically, DNS lookup times for users from non-US cities are significantly higher than those for users within the US. If a good percentage of your users are coming from outside the US, the benefits of increasing parallel downloads is offset by the time to make many DNS lookups. rule of thumb: use at least two but no more than four aliases aliases

17 Experiment Takeaways consider the effects of CPU thrashing
DNS lookup times vary across ISPs and geographic locations domain names may not be cached

18 14 Rules

19 14 Rules Make fewer HTTP requests Use a CDN Add an Expires header
Gzip components Put stylesheets at the top Move scripts to the bottom Avoid CSS expressions Make JS and CSS external Reduce DNS lookups Minify JS Avoid redirects Remove duplicate scripts Configure ETags Make AJAX cacheable in priority order addressing these rules improve response times

20 Rule 1: Make fewer HTTP requests
CSS sprites combined scripts, combined stylesheets preloading image maps inline images CSS sprites is the best soln, but I arranged these in order of complexity. Sometimes there's a tension or tradeoff between richer content and performance. One of the few rules that improves response times for first-time (empty cache) visitors (~20% of page views, 40-60% of unique users).

21 CSS Sprites size of combined image is less <span style="
background-image: url('sprites.gif'); background-position: -260px -90px;"> </span> Size of combined image actually decreases due to reduced image overhead (color tables, formatting info, etc.). size of combined image is less

22 Combined Scripts, Combined Stylesheets
amazon.com 3 1 aol.com 18 cnn.com 11 2 ebay.com 7 froogle.google.com msn.com 9 myspace.com wikipedia.org yahoo.com 4 youtube.com Average 6.5 1.5

23 Combined Scripts, Combined Stylesheets
combining six scripts into one eliminates five HTTP requests challenges: develop as separate modules number of possible combinations vs. loading more than needed maximize browser cache one solution: dynamically combine and cache

24 Preloading Download resources for the next page after the current page is done loading. Examples:

25 Image maps server-side client-side – preferred drawbacks:
<a href="navbar.cgi"><img ismap src="imagemap.gif"></a> client-side – preferred <img usemap="#map1" border=0 src="/images/imagemap.gif"> <map name="map1"> <area shape="rect" coords="0,0,31,31" href="home.html" title="Home"> </map> drawbacks: must be contiguous defining area coordinates – tedious, errors Client-side is preferred: provide visual feedback of what image portions are active, accessible to people with non-graphical browsers

26 Inline Images data: URL scheme not supported in IE
data:[<mediatype>][;base64],<data> <IMG ALT=”Red Star” SRC="data:image/gif;base64,R0lGODlhDAAMALMLAPN8ffBiYvWWlvrKy/FvcPewsO9VVfajo+w6O/zl5estLv/8/AAAAAAAAAAAAAAAACH5BAEAAAsALAAAAAAMAAwAAAQzcElZyryTEHyTUgknHd9xGV+qKsYirKkwDYiKDBiatt2H1KBLQRFIJAIKywRgmhwAIlEEADs="> not supported in IE avoid increasing size of HTML pages: put inline images in cached stylesheets Spec says "allows inclusion of small data items as 'immediate' data." Mostly used for images, but can be used anywhere a URL is specified: A and SCRIPT They say there are size limitations, but FF supports up to 100K base64 encoding increases size of images Since HTML pages are typically not cached, move inline images to cached stylesheets.

27 Rule 2: Use a CDN amazon.com Akamai aol.com cnn.com ebay.com Akamai, Mirror Image google.com msn.com SAVVIS myspace.com Akamai, Limelight wikipedia.org yahoo.com youtube.com distribute your static content before distributing your dynamic content backups, extended storage capacity, caching, absorb spikes drawbacks: affected by other sites, no direct control Homegrown solutions are also used. Cut 20% for Shopping.

28 Rule 2: Use a CDN Adding your CDN(s) to YSlow Go to about:config
Right-click in the window and choose New and String to create a new string preference. Enter extensions.firebug.yslow.cdnHostnames for the preference name. For the string value, enter the hostname of your CDN, for example, mycdn.com. Do not use quotes. If you have multiple CDN hostnames, separate them with commas. backups, extended storage capacity, caching, absorb spikes drawbacks: affected by other sites, no direct control Homegrown solutions are also used. Cut 20% for Shopping.

29 Rule 3: Add an Expires header
not just for images Images Stylesheets Scripts % with Expires Median Age amazon.com 0/62 0/1 0/3 0% 114 days aol.com 23/43 1/1 6/18 48% 217 days cnn.com 0/138 0/2 2/11 1% 227 days ebay.com 16/20 0/7 55% 140 days froogle.google.com 1/23 4% 454 days msn.com 32/35 3/9 80% 34 days myspace.com 0/18 1 day wikipedia.org 6/8 2/3 75% yahoo.com 23/23 4/4 100% n/a youtube.com 0/32 26 days One thought: you can't put an Expires header because the content is constantly changing. But when we look at the Last-Modified header we see that's not the case. For MySpace it is, but Amazon, CNN, Froogle and YouTube all have lengthier Last_modified values.

30 you can affect users' download times
Rule 4: Gzip components you can affect users' download times 90%+ of browsers support compression

31 Gzip: not just for HTML HTML Scripts Stylesheets amazon.com x aol.com some cnn.com ebay.com froogle.google.com msn.com deflate myspace.com wikipedia.org yahoo.com youtube.com gzip scripts, stylesheets, XML, JSON (not images, PDF) Images and PDF files are already compressed. Gzipping them wastes CPU and can increase file sizes.

32 Gzip vs. Deflate Gzip compresses more Gzip supported in more browsers
Size Savings Script 3.3K 1.1K 67% 66% 39.7K 14.5K 64% 16.6K 58% Stylesheet 1.0K 0.4K 56% 0.5K 52% 14.1K 3.7K 73% 4.7K

33 Gzip Configuration Apache 2.x: mod_deflate HTTP request HTTP response
AddOutputFilterByType DEFLATE text/html text/css application/x-javascript HTTP request Accept-Encoding: gzip, deflate HTTP response Content-Encoding: gzip Vary: Accept-Encoding The Vary header is required for proxies, so they don't server gzip to browsers that don't support it (and vice-versa). The Vary header is added automatically by mod_gzip (not sure about mod_deflate). needed for proxies

34 Gzip Edge Cases <1% of browsers have problems with gzip
IE 5.5: IE 6.0: Netscape 3.x, 4.x consider adding Cache-Control: Private remove ETags (Rule 13) hard to diagnose; problem getting smaller

35 Rule 5: Put stylesheets at the top
stylesheets block rendering in IE solution: put stylesheets in HEAD (per spec) avoids Flash of Unstyled Content use LINK Unfortunately, this is bad for FF because in FF stylesheets block parallel downloads.

36 Slowest is Fastest CSS at the bottom: CSS at the top:
resources load faster, but nothing renders CSS at the top: resources take longer, but render progressively right choice REMEMBER: IE ONLY! css-top seems the fastest, but actually it's the slowest to download all necessary components to render the page css-top-import shows that puts the stylesheet last thus delaying rendering @import at the top: same problems as bottom

37 Rule 6: Move scripts to the bottom
scripts block parallel downloads across all hostnames scripts block rendering of everything below them in the page script defer attribute is not a solution blocks rendering and downloads in FF slight blocking in IE

38 Rule 7: Avoid CSS expressions
used to set CSS properties dynamically in IE width: expression( document.body.clientWidth < 600 ? “600px” : “auto” ); problem: expressions execute many times mouse move, key press, resize, scroll, etc. alternatives: one-time expressions event handlers

39 One-Time Expressions expression overwrites itself <style> P {
background-color: expression(altBgcolor(this)); } </style> <script> function altBgcolor(elem) { elem.style.backgroundColor = (new Date()).getHours()%2 ? "#F08A00" : "#B8D4FF"; </script> ", "width": "800" }

40 Event Handlers tie behavior to (fewer) specific events
window.onresize = setMinWidth; function setMinWidth() { var aElements = document.getElementsByTagName("p"); for ( var i = 0; i < aElements.length; i++ ) { aElements[i].runtimeStyle.width = ( document.body.clientWidth<600 ? "600px" : "auto" ); } Could do this only for MSIE browser type.

41 Rule 8: Make JS and CSS external
inline: HTML document is bigger external: more HTTP requests, but cached variables page views per user (per session) empty vs. primed cache stats component re-use external is typically better extra credit: post-onload download, dynamic inlining

42 Post-Onload Download inline in front page
download external files after onload window.onload = downloadComponents; function downloadComponents() { var elem = document.createElement("script"); elem.src = "http://.../file1.js"; document.body.appendChild(elem); ... } speeds up secondary pages

43 Dynamic Inlining start with post-onload download
set cookie after components downloaded server-side: if cookie, use external else, do inline with post-onload download cookie expiration date is key speeds up all pages

44 Rule 9: Reduce DNS lookups
typically ms block parallel downloads OS and browser both have DNS caches

45 Adding DNS Lookups Increasing parallel downloads is worth an extra DNS lookup.

46 TTL (Time To Live) TTL – how long record can be cached
1 minute 10 minutes 1 hour 5 minutes TTL – how long record can be cached browser settings override TTL

47 Browser DNS Cache IE Firefox DnsCacheTimeout: 30 minutes
KeepAliveTimeout: 1 minute ServerInfoTimeout: 2 minutes Firefox network.dnsCacheExpiration: 1 minute network.dnsCacheEntries: 20 network.http.keep-alive.timeout: 5 minutes Fasterfox: 1 hour, 512 entries, 30 seconds

48 Reducing DNS Lookups fewer hostnames – 2-4 keep-alive

49 Rule 10: Minify JavaScript
Minify External? Minify Inline? no yes froogle.google.com minify inline scripts, too

50 Minify vs. Obfuscate minify – it's safer Original JSMin Savings
Dojo Savings 204K 31K (15%) 48K (24%) 44K 4K (10%) 98K 19K (20%) 24K (25%) 88K 23K (27%) 24K (28%) 42K 14K (34%) 16K (38%) 34K 8K (22%) 10K (29%) Average 85K 17K (21%) 21K (25%) minify – it's safer minify instead of obfuscate: fewer bugs, less maintenance, easier to debug in production after gzipping, no difference between minification and obfuscation not much difference

51 Rule 11: Avoid redirects 3xx status codes – mostly 301 and 302
HTTP/ Moved Permanently Location: add Expires headers to cache redirects worst form of blocking example:

52 Redirects Redirects www.amazon.com no www.aol.com yes – secondary page
yes – initial page froogle.google.com

53 Avoid Redirects missing trailing slash mod_rewrite CNAMEs
use Alias or DirectorySlash mod_rewrite CNAMEs log referer – track internal links outbound links – harder beacons – beware of race condition XHR – bail at readyState 2 With alias, DirectorySlash and mod_rewrite you can't have URIs that are relative to the current directory.

54 Rule 12: Remove duplicate scripts
hurts performance extra HTTP requests (IE only) extra executions atypical? 2 of 10 top sites contain duplicate scripts team size, # of scripts extra HTTP requests happen in IE if the scripts are not cacheable or if the page is Reloaded

55 Script Insertion Functions
<?php function insertScript($jsfile) { if ( alreadyInserted($jsfile) ) { return; } pushInserted($jsfile); if ( hasDependencies($jsfile) ) { $dependencies = getDependencies($jsfile); for ( $i = 0; $i < count($dependencies); $i++ ) { insertScript($dependencies[$i]); } echo '<script type="text/javascript" src="' . getVersion($jsfile) . '"></script>"; ?> avoids dupes, makes sure dependencies are included in the right order, handles versioning could do combining ; > avoids dupes, makes sure dependencies are included in the right order, handles versioning. could do combining.", "width": "800" }

56 Rule 13: Configure ETags unique identifier returned in response
ETag: "c8897e-aee-4165acf0" Last-Modified: Thu, 07 Oct :54:08 GMT used in conditional GET requests If-None-Match: "c8897e-aee-4165acf0" If-Modified-Since: Thu, 07 Oct :54:08 GMT if ETag doesn't match, can't send 304 ETag format Apache: inode-size-timestamp IIS: Filetimestamp:ChangeNumber Use 'em or lose 'em Apache: FileETag none IIS: ETag == entity tag if-none-match overrides if-modified-since

57 Rule 14: Make AJAX cacheable
XHR, JSON, iframe, dynamic scripts can still be cached (and minified, and gzipped) a personalized response should still be cacheable for that person

58 AJAX Example: Yahoo! Mail Beta
address book XML request → GET /yab/[...]&r= HTTP/1.1 Host: us.xxx.mail.yahoo.com ← HTTP/ OK Date: Thu, 12 Apr :39:09 GMT Cache-Control: private,max-age=0 Last-Modified: Sat, 31 Mar :17:17 GMT Content-Type: text/xml; charset=utf-8 Content-Encoding: gzip address book changes infrequently cache it; add last-modified-time in URL 18K for me!

59 Next Rules Split static content across multiple domains
Reduce the size of cookies Host static content on a different domain Minify CSS Avoid IFrames in priority order addressing these rules improve response times

60 Case Studies If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

61 Case Study: move JS to onload remove bottom tabs avoid redirects
image sprites host JS on CDN combine JS files 40-50% top graph: response times over dialup bottom graph: response times over broadband

62 What about performance and Web 2.0 apps?
client-side CPU is more of an issue user expectations are higher these rules still apply, new rules will come out start off on the right foot

63 Case Study: Mail Classic Mail User Workflow mail.yahoo.com
view inbox folder read messages (x3) compose message confirm send total time: Time 2.40 s 4.98 s 6.39 s 2.21 s 2.10 s 18.08 s Time 12.48 s 1.52 s 1.53 s 0.34 s 0s 15.87 s Delta +420% -70% -76% -85% -100% -12%

64 Evangelism If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

65 Evangelism Book Conferences Blogs Open Source YSlow
High Performance Web Sites Conferences Yahoo! F2E Summit Web 2.0 Expo Rich Web Experience Blogs YUI Blog: YDN Blog: Open Source YSlow OSCon Ajax Experience Blogher Future of Web Apps halo effect helps all web users documentation archive hiring communications w/in the company perceived value quality of end product (book, code)

66 YSlow http://developer.yahoo.com/yslow performance lint tool
scores web pages for each rule Firefox add-on integrated with Firebug open source license Knew we couldn't reach all the development teams at Yahoo!. Needed to teach them to fish.

67

68 Ten Top U.S Web Sites Page Weight Response Time YSlow Grade
405K 15.9 sec D 182K 11.5 sec F 502K 22.4 sec 275K 9.6 sec C froogle.google.com 18K 1.7 sec A 221K 9.3 sec 205K 7.8 sec 106K 6.2 sec 178K 5.9 sec 139K

69 Strong Correlation correlation(resp time, page weight) = 0.94
total page weight response time inverse YSlow grade Yahoo! doesn't quite follow the curve. It has the 2nd best YSlow grade[1] and response time, even though it's the 4th heaviest page. The Yahoo! front page team is a long-time consumer of these performance best practices, and therefore scores well in YSlow and is able to squeeze more speed out of their page. Amazon's YSlow grade also doesn't reflect the page weight and response time. The main reason for this is the large number of images in their page (approximately 74 images). YSlow doesn't subtract points for images, so the Amazon page scores well but performs slowly. Web 2.0 challenges correlation(resp time, page weight) = 0.94 correlation(resp time, inverse YSlow) = 0.76

70 Live Analysis If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

71 IBM Page Detailer packet sniffer Windows only IE, FF, any .exe
c:\windows\wd_WS2s.ini Executable=(NETSCAPE.EXE),(NETSCP6.EXE),(firefox.exe) free trial, $300 license

72

73 Firebug web development evolved inspect and edit HTML
tweak and visualize CSS debug and profile JavaScript monitor network activity (caveat) Firefox extension free

74 Takeaways focus on the frontend harvest the low-hanging fruit
you do control user response times small investment up front keeps on giving LOFNO – be an advocate for your users

75 Steve Souders

76 CC Images Used "Need for Speed" by Amnemon: "Max speed 15kmh" by xxxtoff: "maybe" by Tal Bright: "takeout" by dotpolka: "how do they do that" by Fort Photo: "Absolutely Nothing is Allowed Here" by Vicki & Chuck Rogers: "Zipper Pocket" by jogales: "new briefcase" by dcJohn: "Told you it was me!" by Pug!: "Robert's Legion" by dancharvey: "thank you" by nj dodge:


Download ppt "High Performance Web Sites 14 rules for faster pages"

Similar presentations


Ads by Google