High Performance Web Sites 14 rules for faster pages

1. High Performance Web Sites14 rules for faster pages Steve Souders Tenni Theurer http://developer.yahoo.com/performance/

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

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

5. Time Spent on the Frontend

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

7. Agenda • Performance Research • 14 Rules • Case Studies • Evangelism • Live Analysis

8. Performance Research

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

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

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

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

13. Empty vs. Primed Cache user requests www.yahoo.com with an empty cache

14. Empty vs. Primed Cache user re-requests www.yahoo.com Expires header with a primed cache

15. Empty vs. Primed Cache • empty cache • 2.4 seconds • primed cache • 0.9 seconds • 83% fewer bytes • 90% fewer HTTP requests

16. 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*?

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

18. }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

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

20. }1 px Browser Cache Experiment

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

22. Experiment Takeaways • The empty cache user experience is more prevalent than you think! • Optimize for both primed cache and empty cache experience.

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

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

25. .yahoo.com cookie sizes

26. Analysis of Cookie Sizes across the Web

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

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

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

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

31. Maximizing Parallel Downloads response time (seconds) aliases

32. Maximizing Parallel Downloads response time (seconds) aliases

33. Maximizing Parallel Downloads response time (seconds) aliases

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

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

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

37. 14 Rules

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

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

40. CSS Sprites • size of combined image is less <span style=" background-image: url('sprites.gif'); background-position: -260px -90px;"> </span> http://alistapart.com/articles/sprites

41. Rule 2: Use a CDN • distribute your static content before distributing your dynamic content

42. Rule 3: Add an Expires header • not just for images

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

44. Gzip: not just for HTML • gzip scripts, stylesheets, XML, JSON (not images, PDF)

45. 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 (not @import)

46. Slowest is Fastest • CSS at the bottom: resources load faster, but nothing renders • CSS at the top: resources take longer, but render progressively • right choice • @import at the top: same problems as bottom

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

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

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

50. Rule 9: Reduce DNS lookups • typically 20-120 ms • block parallel downloads • OS and browser both have DNS caches