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

4.
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.)

5.
http://requestmap.webperf.tools/

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

7.
missed opportunity

8.
10 lessons

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

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

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

12.
Lesson I

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

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

15.
Theory of Constraints

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

17.
One Metric That Matters?

18.
1st generation

19.
1st generation

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

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

22.
Just after
DOMContentLoaded

23.
7 seconds before
Load

24.
2nd generation
Speed Index
Custom Metrics

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

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

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

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

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

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

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

32.
speed index

33.
speed index

34.
Show it to your CEO

35.
Interactivity metric in RUM?

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

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

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

39.
What does good look like?

40.
20% faster

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

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

43.
Continuous Web Performance Testing

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

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

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

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

48.
100ms 1000ms

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

50.
Lesson 3: Get yourself
performance budget

51.
Web Performance Advocates
and JS Frameworkers
debating on Twitter

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

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

54.
Lesson 4

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

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

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

58.
Optimization: use lighter framework

59.
Optimization: use lighter framework
this looks small

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

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

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

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

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

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

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

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

68.
27kb

69.
14kb

70.
13kb

71.
1kB

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

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

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

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

76.
I don’t know

77.
I guess it was
popular

78.
Availability heuristic

79.
Boring
solution
to my
boring
problem
Oh
Shiny
Shiny

80.
Choose boring technology?

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

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

83.
Back button amnesia

84.
Browsers help you with HTML
optimisations for free

85.
Progressive rendering
out of the box

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

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

88.
But HTML is bigger
than JSON

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

90.
But my framework
can do SSR

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

92.
Server-Side Render (SSR) + CSR

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

94.
well-executed SPA

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

96.
Lesson 6

97.
CSS

98.
JS

99.
Compiled to JS languages

100.
Statically typed FP langs

101.
Elm

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

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

104.
Hyperapp
28kb

105.
Hyperapp
28kb32kb

106.
🌳

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

108.
Array.prototype.smoosh = …

109.
Optimisations taxonomy
• load time
• runtime

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

111.
Pure functions
+
Immutable data structures

112.
String -> Html

113.
lazy String -> Html

114.
Making stupid things impossible

115.
lazy [Item] -> Html

116.
What capabilities are enabled
by my language constraints?

117.
Lesson 6: You may need more
than JS

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

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

120.
Flame Chart

121.
render

122.
Comments
Comment

123.
Hypothesis

124.
View optimisation strategies

125.
Windowing/
Virtualized long list

126.
Align work
(keyed lists)

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

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

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

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

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

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

133.
GitHub uses no web fonts

134.
Parallax lag

135.
Lesson 8: Have courage in your
minimalism

136.
Go make the Web faster

137.
DEV OPS

138.
DEV OPSDesign Marketing

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

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

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

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

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

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

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

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

147.
Delivered with ❤ by @kwasniew
Thank you