Why performance matters: Measuring your websites performance

A brief introduction to client-side performance. How to measure your websites performance bottlenecks. Followed by a few tips and best practices to overcome common client-side performance issues and some examples of how we are tackling these issues at the Guardian.

1. Measuring your websites performance Patrick Hamann Front-end London - April 2013 Why performance matters
2. Who am I? • @patrickhamann • Client-side developer • Performance geek
3. Who I work for
4. What am I going to cover?
5. What am I going to cover? • Why performance matters
6. What am I going to cover? • Why performance matters • How to measure your websites performance bottlenecks
7. What am I going to cover? • Why performance matters • How to measure your websites performance bottlenecks • Myths, tips and best practices
8. Ideal load time?
9. < 3 secs
10. Reality:
11. 7.25 secs
12. Page weight is increasing YoY Source: HTTPArchive
13. 1.4 Mb
14. User load time expectations Source: Web Performance Today
15. 71% of users want your mobile site to load as fast as the desktop equivalent. Source: Gomez
16. "We made the new platform 60% faster and this resulted in a 14% increase in donation conversions." Kyle Rush - Obama Campaign
17. Measuring performance Tools
18. The critical path Network Parse Paint
19. Waterfall analysis
22. Size
23. Size Latency
24. Size Latency Download
25. Size Latency Download DOMContentReady
26. Size Latency Download DOMContentReady Load
27. WebPageTest.org
28. WebPageTest.org
29. WebPageTest.org
30. WebPageTest.org
31. WebPageTest.org
32. WebPageTest.org
33. WebPageTest : Comparison
34. WebPageTest : Video
35. PROBLEMS
36. Common performance bottlenecks • Latency • Payload • Caching • Paint
37. Latency • Time to first byte (TTFB) • Incurred on every request • Much worse on mobile • CDN’s • The closer to the user, the lower the latency • Edge side compression • HTML ?!
38. Reduce payload: 101 • Compression • GZip (mod_deflate mod_pagespeed) • Concatenate CSS/JS • Defer to load event (lazy-load) • Conditional loading • Cache
39. Reduce payload: CSS • Only resource that should block the parser! • Load only bare minimum for page chrome • Conditionally load the rest • Browsers download CSS they don't need : e.g. print, tv, device-ratio... • Serve of same host - no DNS lookup • Inline ?*&%!
41. WTF!
42. Reduce payload: Images • Compression: • Photoshop 60% > ImageOptim 25/70% • Progressive JPEGs • WebP • Base64 icons or icon fonts • Clean SVGs • No images at all?
43. Progressive JPEGs Source: Performance calendar
44. WebP - Content negotiation WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller in size compared to JPEG Source: NetDNA blog
45. Caching • Far-future cache headers • Invalidation • AppCache is broken :( • Mobile is harder • Smaller shared cache • Stuff critical assets in localStorage
47. WTF!
48. Render • Don't use setTimeout • Use request animation frame instead. • CSS Animations get over these issues. • Avoid recalculation • Bisecting slow CSS styles & elements
49. Render: Timeline Source: Addy Osmani
50. Continuous paint mode Source: HTML5 Rocks
51. R.U.M
52. Navigation timing API Source: W3C
53. Navigation timing API Source: W3C
56. Google Analytics: Site Speed
57. HAR
59. Automation: PhantomJS & YSlow Source: Ilya Grigorik
60. Automation: HAR Storage Source: https://code.google.com/p/harstorage/
61. Automation: CI Integration Build Test Deploy Users Monitor
62. Automation: CI Integration Build Test Deploy Users Monitor YSlow
63. The Future
64. The Future • SPDY/HTTP 2.0
65. The Future • SPDY/HTTP 2.0 • Responsive images
66. The Future • SPDY/HTTP 2.0 • Responsive images • <image defer/>
67. The Future • SPDY/HTTP 2.0 • Responsive images • <image defer/> • Application controller
68. The Future • SPDY/HTTP 2.0 • Responsive images • <image defer/> • Application controller • WebP
69. The Future • SPDY/HTTP 2.0 • Responsive images • <image defer/> • Application controller • WebP • Client-hints
70. The Future • SPDY/HTTP 2.0 • Responsive images • <image defer/> • Application controller • WebP • Client-hints • RESS?
71. It sounds easy... • It’s not • Requires a lot of dev time • Maintenance and upkeep • How do you track regression?
72. Performance budget • Optimize an existing feature or asset • Remove an existing feature or asset • Don’t add the new feature or asset
73. PERFORMANCE FIRST
74. Thank you! @patrickhamann Front-end London - April 2013 We’re hiring!