This document outlines 10 web performance lessons for the 21st century. The lessons are: 1) Measure first, optimize bottlenecks second 2) Measure what matters 3) Get a performance budget 4) Write JavaScript efficiently using mostly functions 5) Write code efficiently using mostly HTML 6) Consider static functional programming as JavaScript may not be enough 7) Observe how browsers work behind the scenes 8) Build fast organizations 9) Have courage in your minimalism 10) Sometimes keeping it simple with 9 lessons is enough. The document provides explanations and examples for each lesson along with relevant links to additional resources.

1. 10 Web Performance Lessons
For the
21st Century*
*Title loosely inspired by this bookkwasniew.com

2. Using the Web in 2008
•Go to website
•Do things (post a comment, read news etc.)

3. Using the Web nowadays
•Go to website
•Do things (post a message, read news etc.)

11. Using the Web nowadays
•Go to website
•Not what I intended to do
•…
•Not what I intended to do
•Do things (post a message, read news etc.)

13. http://requestmap.webperf.tools/

17. http://www.geek.com/games/the-average-web-page-is-now-larger-than-the-original-doom-1653097/
2.3MB
*Floppy disk, not a save icon

21. missed opportunity

22. 10 lessons

23. Mateusz Kwaśniewski (kwasniew.com)
2007 2019

24. 2013 2019
Mateusz Kwaśniewski (kwasniew.com)

25. 2013 20192004
Mateusz Kwaśniewski (kwasniew.com)

29. Lesson I

36. “Programmers at work maintaining
a legacy web application"

41. My first big mistake
• Applying random optimisation without identifying a bottleneck
• There’s opportunity cost of doing useless optimisations

42. Theory of Constraints

43. Lesson 1: Measure first,
optimise bottleneck second
Practical Performance: https://www.youtube.com/watch?v=6m_E-mC0y3Y

44. One Metric That Matters?

45. 1st generation

46. 1st generation

47. 1st generation
Lab/Synthetic
Real User Monitoring (RUM)

48. Raiders of the fast start: https://www.youtube.com/watch?v=qts9gPYoANU

50. Just after
DOMContentLoaded

51. 7 seconds before
Load

53. 2nd generation
Speed Index
Custom Metrics

54. https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

57. https://blog.twitter.com/engineering/en_us/a/2012/improving-performance-on-twittercom.html

60. Custom Metric: Hero Image
https://speedcurve.com/blog/user-timing-and-custom-metrics/

61. Custom Metric: Hero Image
Image loaded early but render was blocked by the script

62. 3rd generation
First Contentful Paint
Time to Interactive
First Meaningful Paint
First CPU Idle

63. 3rd generation
First Contentful Paint
Time to Interactive
First Meaningful Paint
First CPU Idle

64. 3rd generation
First Contentful Paint
Time to Interactive
First Meaningful Paint
First CPU Idle

65. speed index

66. speed index

69. Show it to your CEO

72. Interactivity metric in RUM?

74. Web Performance: Leveraging the Metrics that Most Affect User Experience: https://www.youtube.com/watch?v=6Ljq-Jn-EgU&t=898s
First (Contentful) Paint
Custom Metric
Lighthouse metrics
This process we follow, this cycle we ride

75. The search is not over
Last Painted Hero = max(largest heading, largest image)

76. Lesson 2:
Measure
what
matters
How I learned to stop worrying and love UX metrics:
https://www.youtube.com/watch?v=lLR_nGA5t5g
WEB PERFORMANCE METRICS

77. What does good look like?

80. 20% faster

81. https://treo.sh/demo/1?interval=1month

82. Performance Budget
Be specific
https://timkadlec.com/remembers/2019-03-07-performance-budgets-that-stick/

83. Continuous Web Performance Testing

85. Performance bankruptcy
https://product.voxmedia.com/2015/5/6/8561867/declaring-performance-bankruptcy

86. https://blog.radware.com/applicationdelivery/applicationaccelerationoptimization/2013/06/web-performance-poverty-line/

88. https://www.youtube.com/watch?v=Lx1cYJAVnzA
Time to Interactive < 5s for the first load

89. https://addyosmani.com/blog/performance-budgets/

92. 100ms 1000ms

93. Magic numbers
https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Perceived_Performance
100ms 1000ms
https://calendar.perfplanet.com/2018/magic-numbers/

94. Lesson 3: Get yourself
performance budget

95. Web Performance Advocates
and JS Frameworkers
debating on Twitter

96. Web Performance Advocates
and JS Frameworkers
debating on Twitter
Platform!
React!

97. Web Performance Advocates
and JS Frameworkers
debating on Twitter
#perfmatters
#DX matters

98. Lesson 4

99. Disclaimer: JS startup time may not
be an issue for your type of app

100. Make JavaScript Faster: https://www.youtube.com/watch?v=RwSlubTBnew

104. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e

107. Optimization: use lighter framework

108. Optimization: use lighter framework
this looks small

109. Hyperapp
•Standalone React+Redux
•400 lines of code I can reason about
•Elm architecture, very few concepts to learn - fits in my head
•Matches my JS preferences - no this/new/classes
•Loads fast by default

110. Hyperapp
•Standalone React+Redux
•400 lines of code I can reason about
•Elm architecture, very few concepts to learn - fits in my head
•Matches my JS preferences - no this/new/classes
•Loads fast by default

111. Hyperapp
•Standalone React+Redux
•400 lines of code I can reason about
•Elm architecture, very few concepts to learn - fits in my head
•Matches my JS preferences - no this/new/classes
•Loads fast by default

113. Hyperapp
•Standalone React+Redux
•400 lines of code I can reason about
•Inspired by Elm architecture, very few concepts to learn - fits in my head
•Matches my JS preferences - no this/new/classes
•Loads fast by default

114. Hyperapp
•Standalone React+Redux
•400 lines of code I can reason about
•Inspired by Elm architecture, very few concepts to learn - fits in my head
•Matches my JS preferences - no this/new/classes
•Loads fast by default
____ extends Component
@Component

115. Hyperapp
•Standalone React+Redux
•400 lines of code I can reason about
•Inspired by Elm architecture, very few concepts to learn - fits in my head
•Matches my JS preferences - no this/new/classes
•Loads fast by default

116. Hyperapp
•Standalone React+Redux
•400 lines of code I can reason about
•Inspired by Elm architecture, very few concepts to learn - fits in my head
•Matches my JS preferences - no this/new/classes
•Loads fast by default

117. https://github.com/kwasniew/hyperapp-realworld-example-app

118. 27kb

119. 14kb

120. 13kb

121. 1kB

122. https://github.com/krausest/js-framework-benchmark

125. Lesson 4: Write JS. Not too
much. Mostly _____.

126. Lesson 4: Write JS. Not too
much. Mostly functions.

128. https://medium.com/dev-channel/a-netflix-web-performance-case-study-c0bcde26a9d9

133. I don’t know

134. I guess it was
popular

135. Availability heuristic

137. Boring
solution
to my
boring
problem
Oh
Shiny
Shiny

138. Choose boring technology?

139. Choose boring technology.
https://mcfunley.com/choose-boring-technology

142. https://superuser.com/questions/927585/on-some-websites-why-doesnt-ctrl-click-work-but-right-click-open-in-new-t

143. Back button amnesia

147. Browsers help you with HTML
optimisations for free

148. Progressive rendering
out of the box

150. {"username": "@username_9","score": 499,"text": “Blah 123"}
{"username": "@username_83","score": 498,"text": “Blah 345"}

151. https://github.com/jakearchibald/streaming-html/blob/master/xhr-ndjson.js

152. But HTML is bigger
than JSON

153. nope.
http://codeartisan.blogspot.com/2012/07/using-html-as-media-type-for-your-api.html

154. But my framework
can do SSR

155. CSR (Client Side Render)
First Paint - 1.7s
Interactive - 2.7s

156. Server-Side Render (SSR) + CSR

157. Server-Side Render (SSR) + CSR
First Paint - 1.5s
Interactive - 4.0s
First Paint - 1.7s
Interactive - 2.7s

158. well-executed SPA

163. Lesson 5:
Write code.
Not too much.
Mostly HTMLstream based partial async hydration
How to Survive the Single Page App-ocalypse: https://www.youtube.com/watch?v=1SRO-1HBE6E

164. Lesson 6

165. CSS

166. JS

168. Compiled to JS languages

169. Statically typed FP langs

170. Elm

171. Elm = Types + Ramda + Immutable.js + React + Redux + …

172. https://elm-lang.org/blog/small-assets-without-the-headache

173. Hyperapp
28kb

174. Hyperapp
28kb32kb

176. 🌳

179. Why can’t we have it in JS and
its supersets?

180. Array.prototype.smoosh = …

181. Optimisations taxonomy
• load time
• runtime

184. Ease and safety of optimisation
https://elm-lang.org/blog/blazing-fast-html-round-two
https://elm-lang.org/blog/blazing-fast-html

185. Pure functions
+
Immutable data structures

187. String -> Html

188. lazy String -> Html

189. Making stupid things impossible

192. lazy [Item] -> Html

196. What capabilities are enabled
by my language constraints?

202. Lesson 6: You may need more
than JS

203. The more you SPA the more you
need to understand the browser
https://developers.google.com/web/updates/2018/09/inside-browser-part1

207. Technique: Pushing random optimisation commit
with your fingers crossed

209. Flame Chart

212. render

213. Comments
Comment

214. Hypothesis

215. View optimisation strategies

216. Windowing/
Virtualized long list

217. Align work
(keyed lists)

218. <ul>
<li key="0">Red</li>
<li key="1">Green</li>
</ul>
<ul>
<li key="2">Refactor</li>
<li key="0">Red</li>
<li key="1">Green</li>
</ul>

219. Skip work
(avoid reconciliation)
lazy
shouldComponentUpdate/PureComponent
memoize

222. Lesson 7: Observe the not so
secret life of your browser
Browser Rendering Optimization: https://eu.udacity.com/course/browser-rendering-optimization--ud860
BROWSER

224. What I need my website to do?
1. Download and render most important elements of the page

225. What I need my website to do?
1. Download and render most important elements of the page
“You don't need all that other crap.
Have courage in your minimalism.”
http://idlewords.com/talks/website_obesity.htm

226. What I need my presentation to do?
1. Cover the most important elements of the talk

227. GitHub uses no web fonts

228. Parallax lag

241. Lesson 8: Have courage in your
minimalism

243. Go make the Web faster

250. DEV OPS

251. DEV OPSDesign Marketing

253. https://kwasniew.com/training/people-and-interactions/

254. What should we teach children today to
prepare them for the world of tomorrow?

255. 1. Measure first, optimise bottleneck second
2. Measure what matters
3. Get yourself performance budget
4. Write JS. Not too much.
5. Write code. Not too much. Mostly HTML.
6. Embrace static FP. You may need more than JS.
7. Observe not so secret live of your browser
8. Bad system will beat good people every single time
9. Have courage in your minimalism
10.Sometimes 9 is enough

256. 1. Measure first, optimise bottleneck second
2. Measure what matters
3. Get yourself performance budget
4. Write JS. Not too much. Mostly functions.
5. Write code. Not too much. Mostly HTML.
6. Embrace static FP. You may need more than JS.
7. Observe not so secret live of your browser
8. Bad system will beat good people every single time
9. Have courage in your minimalism
10.Sometimes 9 is enough

257. 1. Measure first, optimise bottleneck second
2. Measure what matters
3. Get yourself performance budget
4. Write JS. Not too much. Mostly functions.
5. Write code. Not too much. Mostly HTML.
6. Embrace static FP. You may need more than JS.
7. Observe not so secret life of your browser
8. Bad system will beat good people every single time
9. Have courage in your minimalism
10.Sometimes 9 is enough

258. 1. Measure first, optimise bottleneck second
2. Measure what matters
3. Get yourself performance budget
4. Write JS. Not too much. Mostly functions.
5. Write code. Not too much. Mostly HTML.
6. Embrace static FP. You may need more than JS.
7. Observe not so secret life of your browser
8. Make or join faster organisation
9. Have courage in your minimalism
10.Sometimes 9 is enough

259. 1. Measure first, optimise bottleneck second
2. Measure what matters
3. Get yourself performance budget
4. Write JS. Not too much. Mostly functions.
5. Write code. Not too much. Mostly HTML.
6. Embrace static FP. You may need more than JS.
7. Observe not so secret life of your browser
8. Make or join faster organisation
9. Have courage in your minimalism
10.Sometimes 9 is enough

260. 1. Measure first, optimise bottleneck second
2. Measure what matters
3. Get yourself performance budget
4. Write JS. Not too much. Mostly functions.
5. Write code. Not too much. Mostly HTML.
6. Embrace static FP. You may need more than JS.
7. Observe not so secret life of your browser
8. Make or join faster organisation
9. Have courage in your minimalism
10. Sometimes 9 is enough

262. Delivered with ❤ by @kwasniew
Thank you