High Performance Web Sites 14 rules for faster-loading pages

1. High Performance Web Sites14 rules for faster-loading pages Steve Souders souders@yahoo-inc.com Tenni Theurer tenni@yahoo-inc.com

2. Introduction

3. Exceptional Performance • started in 2004 • quantify and improve the performance of all Yahoo! products worldwide • center of expertise • build tools, analyze data • gather, research, and evangelize best practices

4. Scope • performance breaks into two categories • response time • efficiency • current focus is response time • of web products

5. Rough Cuts: now • Hardcopy: Summer 2007 • http://www.oreilly.com/catalog/9780596514211/

6. The Importance of Front-End Performance

7. Back-end vs. Front-end • percentage of time spent on the front-end

8. The Performance Golden Rule • 80-90% of the end-user response time is spent on the front-end. Start there. • Greater potential for improvement • Simpler • Proven to work

9. Schedule • Performance Research • break • 14 Rules • break • Case Studies • Live Analysis

10. Performance Research

11. perceived response time slowcrawlboringsnailstagnantunexceptionalyawnunresponsiveimpatientdelaymoderateblahsubduedragapatheticprolongslackloadsluggishsleepylateunexcitingreducedlagcomplex heavyunmemorableobscurewhy wait performance speed enjoyable urgentinstantaccelerateperceptionsnapachievement betterimproveaction pleasantpacequickpromoteswiftcoolmaximumdriveprompt advance fast hurryrushsatisfyingfeelexceptionalbriskrapid exciting what is the end user’s experience?

12. User Perception • Usability and perception are important for performance. • The user’s perception is more relevant than actual unload-to-onload response time. • Definition of "user onload" is undefined or varies from one web page to the next.

13. http://yuiblog.com/blog/2006/11/28/performance-research-part-1/http://yuiblog.com/blog/2006/11/28/performance-research-part-1/

14. 80/20 Performance Rule • Vilfredo Pareto: • 80% of consequences come from 20% of causes • Focus on the 20% that affects 80% of the end-user response time. • Start at the front-end.

15. 2 3 1 user re-requests www.yahoo.com user requests www.yahoo.com user requests other web pages Empty vs. Full Cache

16. 2 3 1 user re-requests www.yahoo.com user requests www.yahoo.com user requests other web pages Empty vs. Full Cache with an empty cache

17. 2 3 1 user re-requests www.yahoo.com user requests www.yahoo.com user requests other web pages Empty vs. Full Cache

18. 2 1 user requests www.yahoo.com user requests other web pages Empty vs. Full Cache 3 user re-requests www.yahoo.com Expires header with a full cache

19. Empty vs. Full Cache • empty cache • 2.4 seconds • full cache • 0.9 seconds • 83% fewer bytes • 90% fewer HTTP requests

20. How much does this benefit our users? • It depends on how many users have components in cache. • What percentage of users view a page with an empty cache*? • * “Empty cache” means the browser has to request the componentsinstead of pulling them from the browser disk cache. • What percentage of page viewsare done with an empty cache*?

21. http://yuiblog.com/blog/2007/01/04/performance-research-part-2/http://yuiblog.com/blog/2007/01/04/performance-research-part-2/

22. }1 px Browser Cache Experiment • Add a new image to your page • <img src="image/blank.gif" height="1" width="1"/> • with the following response headers: Expires: Thu, 15 Apr 2004 20:00:00 GMT Last-Modified: Wed, 28 Sep 2006 23:49:57 GMT

23. Browser Cache Experiment • Requests from the browser will have one of these response status codes: 200 – The browser does not have the image in its cache. 304 – The browser has the image in its cache, but needs to verify the last modified date.

24. }1 px Browser Cache Experiment

25. users withempty cache page views withempty cache Surprising Results 40-60% ~20%

26. Experiment Takeaways • Keep in mind the empty cache user experience. It might be more prevalent than you think! • Use different techniques to optimize full versus empty cache experience.

27. http://yuiblog.com/blog/2007/03/01/performance-research-part-3http://yuiblog.com/blog/2007/03/01/performance-research-part-3

28. 1 user requests www.yahoo.com HTTP Quick Review HTTP response header sent by the web server: HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Set-Cookie: C=abcdefghijklmnopqrstuvwxyz; domain=.yahoo.com

29. 2 1 user requests finance.yahoo.com user requests www.yahoo.com HTTP Quick Review HTTP request header sent by the browser: GET / HTTP/1.1 Host: finance.yahoo.com User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; … Cookie: C=abcdefghijklmnopqrstuvwxyz;

30. 3 1 user requests autos.yahoo.com user requests www.yahoo.com HTTP Quick Review HTTP request header sent by the browser: GET / HTTP/1.1 Host: autos.yahoo.com User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; … Cookie: C=abcdefghijklmnopqrstuvwxyz;

31. 4 1 user requests mail.yahoo.com user requests www.yahoo.com HTTP Quick Review HTTP request header sent by the browser: GET / HTTP/1.1 Host: mail.yahoo.com User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; … Cookie: C=abcdefghijklmnopqrstuvwxyz;

32. 5 1 user requests tech.yahoo.com user requests www.yahoo.com HTTP Quick Review HTTP request header sent by the browser: GET / HTTP/1.1 Host: tech.yahoo.com User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; … Cookie: C=abcdefghijklmnopqrstuvwxyz;

33. dialup users 80 ms delay keep sizes low Impact of Cookies on Response Time

34. .yahoo.com cookie sizes

35. Analysis of Cookie Sizes across the Web

36. 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

37. http://yuiblog.com/blog/2007/04/11/performance-research-part-4/http://yuiblog.com/blog/2007/04/11/performance-research-part-4/

38. GIF GIF GIF GIF GIF GIF Parallel Downloads Two components in parallel per hostname HTTP/1.1

39. Parallel Downloads • Two in parallel • Four in parallel • Eight in parallel

40. Maximizing Parallel Downloads response time (seconds) aliases

41. Maximizing Parallel Downloads response time (seconds) aliases

42. Maximizing Parallel Downloads response time (seconds) aliases

43. Maximizing Parallel Downloads response time (seconds) rule of thumb: use at least two but no more than four aliases

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

45. Summary • What the 80/20 Rule Tells Us about Reducing HTTP Requests • http://yuiblog.com/blog/2007/04/11/performance-research-part-4/ • Browser Cache Usage – Exposed! • http://yuiblog.com/blog/2007/01/04/performance-research-part-2/ • When the Cookie Crumbles • http://yuiblog.com/blog/2007/01/04/performance-research-part-2/ • Maximizing Parallel Downloads in the Carpool Lane • http://yuiblog.com/blog/2007/04/11/performance-research-part-4/

46. 14 Rules

47. 14 Rules • Make fewer HTTP requests • Use a CDN • Add an Expires header • Gzip components • Put CSS at the top • Move JS to the bottom • Avoid CSS expressions • Make JS and CSS external • Reduce DNS lookups • Minify JS • Avoid redirects • Remove duplicate scripts • Turn off ETags • Make AJAX cacheable and small

48. Rule 1: Make fewer HTTP requests • image maps • CSS sprites • inline images • combined scripts, combined stylesheets

49. Image maps • server-side • <a href="navbar.cgi"><img ismap src="imagemap.gif"></a> • → http://.../navbar.cgi?127,13 • 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 http://www.w3.org/TR/html401/struct/objects.html#h-13.6

50. CSS Sprites – Preferred • size of combined image is less • not supported in Opera 6 <span style=" background-image: url('sprites.gif'); background-position: -260px -90px;"> </span> http://alistapart.com/articles/sprites