Breaking news at 1000ms - LDN Web Perf

An introduction into how the Guardian are making their next generation website load as fast as possible, and ultimately breaking the news to the user within 1000ms.

During the talk you will discover why performance matters, what are the common performance bottlenecks in the browser from networking to painting and learn how to best optimise and monitor each stage of the critical path to create fast, jank free websites.

This version of the talk was given at the London Web Performance meetup on the 26th August 2014.

Transcript

1. Breaking news at 1000ms @patrickhamann - LWP Google WebPerf – August 2014
2. theguardian.com
3. next.theguardian.com
5. 100million !
6. " # $ 6000
9. User load time expectations are decreasing 0 2.25 4.5 6.75 9 2000 2006 2009 2012 User load time expectations (Secs) Source: Web Performance Today - March 2013
10. 0 5000 10000 15000 20000 Jan Feb Mar Apr 10% Percentile Median 90% Percentile Source: HTTPArchive - May 2014 Average SpeedIndex from top 10,000 websites
11. Maslow's hierarchy of user needs ! % & ' We surveyed 3000 users About 17 key product drivers They rated speed 2nd most important Only after easy to find content
12. Time & user perception Delay User perception 0–100 ms Instant 100–300 ms Small perceptible delay 300–1000 ms Machine is working 1,000+ ms Likely mental context switch 10,000+ ms Task is abandoned Source: Ilya Grigorik – High-Performance Browser Networking
13. 1000ms
14. A performance budget https://flic.kr/p/iQ69Kg
15. Setting a budget https://flic.kr/p/eHsirY
16. 1. Core content should be delivered first 2. Core content should render within 1000ms 3. Every feature must fail gracefully 4. Every request should be measured
17. 1. Core content should be delivered first 2. Core content should render within 1000ms 3. Every feature must fail gracefully 4. Every request should be measured
19. User Content API Popular Comments Article DB DB
20. https://flic.kr/p/77ZtUH
21. User Content API Popular Comments Article DB DB
22. Final progressively enhanced page Initial page payload
24. 1. Core content should be delivered first 2. Core content should render within 1000ms 3. Every feature must fail gracefully 4. Every request should be measured
25. Browser rendering 101
26. Source: Google - Pagespeed Insights
27. Network JavaScript Render tree Layout Paint HTML DOM CSS CSSOM Network JavaScript Render tree Layout Paint HTML DOM CSS CSSOM Network JavaScript Render tree Layout Paint HTML DOM CSS CSSOM DOM Network JavaScript Render tree Layout Paint HTML DOM CSS CSSOM Network JavaScript Render tree Layout Paint HTML DOM CSS CSSOM Network JavaScript Render tree Layout Paint HTML DOM CSS CSSOM
28. JS CSS HTML CSS & JS § HTML async DOMContentReady Start render
29. Get the CSS down as soon as possible.
30. What is your critical CSS?
31. Popular content ✘ Sharing ✘ Comments ✘ Related content ✘ Commercial components ✘ Article ✔
32. What if we inlined our critical CSS?
33. WTF%$?! Inline critical CSS
34. 0.0 0.1 0.2 0.3 0.0 0.1 0.2 0.3
37. Load time First byte Start render Visually complete 3.366s 0.204s 1.113s 3.700s Before Load time First byte Start render Visually complete 3.017s 0.262s 0.759s 2.00s After
38. Use MD5 hash for cache key WTF no stylesheets?
39. What does the future hold?
40. http/2
41.  ) HTML " ) CSS  " HTTP/1.1 * HTML & CSS  " HTTP/2 Server push
42. 1. Core content should be delivered first 2. Core content should render within 1000ms 3. Every feature must fail gracefully 4. Every request should be measured
43. Story of my life
44. – W3C Font Spec ! ! ! User agents may render text as it would be rendered if downloadable font resources are not available or they may render text transparently with fallback fonts to avoid a flash of text using a fallback font. ! In cases where the font download fails user agents must display text, simply leaving transparent text is considered non-conformant behaviour.
45. Font loading 101 IE Firefox WebKit Blink Blocking ✗ ✔ ✔ ✔ Timeout – 3s – – Source: Ian Feather – Web fonts and the Critical Path
46. guardian egyptian
47. progressive enhancement https://flic.kr/p/9RDXVd
48. Is modern browser? Support WOFF? Font in localStorage? Show font Show fallback Download JSON localStorage space? Cache in localStorage
49. Example of base64 json’ifed fonts
50. service worker Webfontjson
51. What does the future hold?
52. Font load events
53. service worker ServiceWorker
54. ServiceWorker  " )  " ) )
55. 1. Core content should be delivered first 2. Core content should render within 1000ms 3. Every feature must fail gracefully 4. Every request should be measured
56. assets radiator
57. R.U.M. (real user metrics)
61. some people don’t like this.
62. speedcurve
65. What does the future hold?
66. Resource Timing
67. Beacon API
68. 1. Core content should be delivered first 2. Core content should render within 1000ms 3. Every feature must fail gracefully 4. Every request should be measured
69. Lessons
70. Everyone must be involved by baking performance into your workflow from day one.
71. Deliver core content first,
 then progressively enhance the extras.
72. Set a performance budget.
 Measure, optimise & repeat!
73. Performance is a requirement; not an extra feature.
74. Thank you. Questions? @patrickhamann - LWP Google WebPerf – August 2014 github.com/guardian/frontend + bit.ly/redevelop-ship-it ,