Web performance optimisation has been gaining ground and is slowly getting more of its deserved recognition. Nevertheless, much of our time on the web is still used up by waiting. To decrease our wait time and improve the web’s overall performance, this integral part of user experience needs further promotion. Waiting and the perception of time itself, is reason enough to explore some of the psychological effects time has on our users, too. Passing time also plays a big role in the evolution of technologies. Through the history of HTTP we have reached the latest version as HTTP/2, which will turn some of our existing web performance best practices on their head and into the new anti-patterns of today.

1. Web Performance
in the Age of HTTP/2
Holger Bartel | @foobartel | Topconf Tallinn 2016

2. From 🐢 to 🚀.

3. Your mileage may vary.
It really depends sometimes…
As with most things:

5. Performance is
Design

6. We've come a long way!
Source

7. A World of Bloat

8. Total Page Weight: 13.1 Mb

12. – FACEBOOK
“… This change improves the consumption
experience in emerging markets because
people will see fewer grey boxes, spinners
and incomplete stories.”
Source

15. 50% of people say they'll abandon a
page that takes longer than 4 seconds
to load.

16. Delay User perception
0–100 ms Instant
100–300 ms Small perceptible delay
300–1000 ms Machine is working
1,000+ ms Mental context switch likely
10,000+ ms Task is abandoned
Source

17. Conclusion
Faster is Better!

18. Perception of time

23. And it’s been like that for a long time.
Nobody likes to wait.
Source

24. waiting
ˈweɪtɪŋ/
noun
1. the action of staying where one is
or delaying action until a particular
time or event.
Source

25. Source
waiting
ˈweɪtɪŋ/
noun
1. the action of staying where one is
or delaying action until a particular
time or event.

26. Perception & the Brain

27. Fact
Fast Websites Create Happier Users
Unhappy users — those experiencing even
only a 2-second slowdown in how a web page
loads — simply do less.
Source

28. 78% felt some kind of negative
emotion due to slow or
unreliable websites.
Source
71% of people surveyed feel
regularly inconvenienced by
slow websites
50% believe websites have either not
improved in speed or have become
slower over the past several years.

29. Today, 49% expect load times of 2
seconds or less, and 18%—one out of
five—expect pages to load instantly
Source
The average web user
perceives load times as
being 15% slower than they
actually are.

30. Today, 49% expect load times of 2
seconds or less, and 18%—one out of
five—expect pages to load instantly
Source
The average web user
perceives load times as
being 15% slower than they
actually are.
Later, when recalling the experience,
they remember load times as being
35% slower.

31. The average person believes they
spend 9 minutes per day waiting for slow
websites. This translates to two full days
every year.
Adding indicators like spinners and
progress bars can trick us into believing
that pages are up to 10% faster than they
actually are.

32. The Internet may change, and web pages may
grow and evolve, but user expectations stay
constant.
The numbers about human perception and
response times have been consistent for more
than 45 years.
Source

33. These numbers are hard-wired.
They’re consistent regardless of the type of
device, application, or connection we’re using at
any given moment.

34. 3 types of memory processing
• Sensory memory
• Short-term memory
• Working memory
Source

35. SENSORY MEMORY
… The wheel was spun faster and faster until observers
perceived an unbroken circle of light. The study concluded
that the glowing coal had to perform a complete cycle in
100 milliseconds or less in order to create the illusion of a
fiery circle.
3 types of sensory memories (vision, sound and touch).
Source

36. Flow
For hundreds of thousands of years, human beings have
evolved to perform actions in beautiful, sequential flows.
Actions “flow” seamlessly into the next.
Source

37. Faster pages correlated with increased
user engagement.
Slowness affected the entire perception of the brand, even
non-performance aspects of the site such as design, content
and navigation.
Source

38. Over the decades, research results has
always been the same:
We function at our best when websites and
apps respond in fractions of a second.
We may adapt to slower response times,
but this adaptation will never be perfect.
Source

48. Respect your users’ time
they will end up as happier users who
might more likely forgive your slowness.

49. Real vs. perceived performance
Sometimes it’s hard to tell what the best optimisation is.
Perceived performance can be more important than
actual load times.
The sooner the user can interact with your site, the
better.
User testing is essential for validation.

50. Performance Basics

51. Planning & Strategy

52. Web Performance Optimisation
is an ongoing process, needs
testing, validation and
continuous analysis.

54. Front End Development (~75%)Network/Server

55. What’s the best
performance strategy,
you ask?

56. – CHRIS COYIER, CSS-TRICKS
“Step one is caring about the performance of
your websites.
Step two is doing things to make it better.
Step three is staying on top of performance
for the long haul.”

57. Analysing your project
TFDI

58. Analysing your project
Test for performance
Find your bottlenecks
Decide what’s important
Identify the low hanging fruit

59. Analysing your project
Test for performance
Find your bottlenecks
Decide what’s important
Identify the low hanging fruit

60. Rinse and Repeat

61. Waterfall Chart

64. Network Throttling

65. Webpage Test
https://www.webpagetest.org

66. Filmstrip

67. Filmstrip - Video Export

68. Speed Index
The Speed Index metric allows to see performance from
a user’s point of view
SI indicates the average time it takes for visual parts of a
page (above the fold) to be displayed
The bigger the area above the curve, the more/longer a
user sees a “blank” screen.

69. Speed Index
Time (ms) % of Visual Completion
100 0
200 0
300 0
400 0
500 30
600 35
700 45
800 65
900 80
1000 90
1100 95
1200 100
Source

70. Speed Index
VisualCompleteness
0
25
50
75
100
Time (ms)
100 200 300 400 500 600 700 800 900 1000 1100 1200
Source

71. VisualCompleteness
0
25
50
75
100
Time (ms)
100 200 300 400 500 600 700 800 900 1000 1100 1200
Speed Index
Source

72. Speed Index (better)
Time (ms) % of Visual Completion
100 0
200 20
300 50
400 60
500 70
600 70
700 75
800 80
900 85
1000 90
1100 95
1200 100
Source

73. Speed Index (better)
0
25
50
75
100
100 200 300 400 500 600 700 800 900 1000 1100 1200
Source

74. Speed Index (better)
0
25
50
75
100
100 200 300 400 500 600 700 800 900 1000 1100 1200
Source

75. Google Page Speed Insights

76. https://testmysite.thinkwithgoogle.com/

78. — BRAIN
“It proved these are some powerful
tools. And now, Pinky, the advance of
technology has brought us an even
more powerful tool. Do you know what
that is?”

79. Navigation Timing API
There are many measured events given in milliseconds that can be
accessed through the PerformanceTiming interface.
The list of events in order of occurrence are:
1. navigationStart
2. unloadEventStart
3. unloadEventEnd
4. redirectStart
5. redirectEnd
6. fetchStart
7. domainLookupStart
8. domainLookupEnd
9. connectStart
10. connectEnd
11. secureConnectionStart
12. requestStart
13. responseStart
14. responseEnd
15. domLoading
16. domInteractive
17. domContentLoadedEventStart
18. domContentLoadedEventEnd
19. domComplete
20. loadEventStart
21. loadEventEnd

81. var timing = performance.timing;
var api = {};
// Total time from start to load
api.loadTime = timing.loadEventEnd - timing.fetchStart;
// Time spent constructing the DOM tree
api.domReadyTime = timing.domComplete - timing.domInteractive;
// Time until first paint
firstPaint = window.chrome.loadTimes().firstPaintTime * 1000;
api.firstPaintTime = firstPaint -
(window.chrome.loadTimes().startLoadTime*1000);

82. Timing.js
https://github.com/addyosmani/timing.js/

83. The “low hanging fruit”

84. First up: Images

85. Average bytes per page by content type
Total: 2552
1%10%
3%
16%
65%
3%2%
HTML CSS Images Scripts Fonts Video Other
HTTP Archive, Data for October 2016

86. Images often account for most of the
downloaded bytes on a page.
Optimising images can often save many bytes
improve performance.

87. http://addyosmani.com/blog/image-optimization-tools/
ImageOptim

90. Scalable Vector Graphics (SVG)
Depending on browser support, SVG is a great way to
save bytes, especially for logos, icons, etc.
Another advantage is that SVG files are scalable and will
always look sharp and crisp.

91. Image Sprites
The main advantage of this technique is about reducing
multiple HTTP requests to only one request for each
sprite.
This saves additional round-trip times for each request.
RTT usually is around 300ms.

92. Data URIs and Base64 encoding
Load base64 images in the first request
Base64 images affect SEO because they will not be
indexed by Google.
Images won’t be cached, which can have negative effects

93. Optimising CSS, JavaScript

94. Taming frameworks
B

95. unCSS
Just what it says on the tin:
Remove unused styles from CSS
https://github.com/giakki/uncss

96. unCSS Caveats
Doesn’t work with dynamic files (PHP etc) and
dynamic class names (JS)
Need to extract all class names from static
pages

97. 15.689 unused rules!!! 😫

98. Good: 55 Unused rules

99. Towards extreme performance

100. Optimising the critical
rendering path

101. Render Blocking Assets
CSS & the “Flash of Unstyled Content” (FOUC)
JavaScript blocks DOM construction unless explicitly
declared as async.

102. Loading JavaScript
Use the async or defer attribute with <script>
to control how JavaScript is being loaded.
<script src=“javascript.js" async> </script>

103. async: the browser should, if possible,
execute the script asynchronously.
defer: indicates to a browser that the
script is meant to be executed after the
document has been parsed, but before
firing DOMContentLoaded.

104. The Critical Rendering Path
Consists of:
Critical Resource
Critical Path Length
Critical Bytes

105. Limit HTTP Requests
Every request can take roughly ~200ms
Avoid unnecessary redirects
(~100ms +)

106. Optimising the Critical Rendering Path
=
Getting stuff on the screen fast

107. the number of critical resources.
the number of critical bytes.
the critical path length.
Minimise
{
A critical resource is a resource that can block
initial rendering of a page.

109. Grunt Critical CSS
https://github.com/filamentgroup/grunt-criticalcss
https://github.com/addyosmani/critical-path-css-demo

110. Building for Performance
with HTTP/2

111. Limit TCP connections to reduce the load on
the server
“A single-user client should not maintain
more than 2 connections with any server or
proxy.”
In real life, browsers hold ~6 TCP connections
simultaneously per origin.
HTTP/1.x

112. Multiplexing
Compressed headers
Asset Prioritisation & Dependencies
Server Push
(saves the time it takes the client to ask for the resources)
HTTP/2

113. The Road to H/2

114. SSL/TLS required

115. Leveraging additional benefits of SSL
Google uses secure connections as a ranking
signal, and browsers are starting to flag non-
https websites as ‘not secure’.
Some HTML5 APIs will also require secure
connections in the future (e.g. Geolocation).

116. Serving HTTP/2
Apache Module mod_h p2

117. HTTP/2 supporting browsers

118. Under HTTP/2, some of our current
best practices might impact
performance negatively.
Best practices == Anti-patterns

119. What has Changed?
HTTP/1.x HTTP/2

120. Concatenation of Files
This was a workaround for the lack of parallelism in
HTTP/1.x to reduce requests.
Combining multiple files into one and fetch with one
request.
Need to wait for the entire file/response to arrive.

121. New!
Requests are cheap!
• Structure code modularly - deliver only what’s
needed
• Build process simplification
• Optimise caching policies - depends on
the change frequency of files

125. Image Sprites
Thanks to the new multiplexing ability of HTTP/2
resources don’t need to be queued anymore.
Nevertheless, depending on the kind of image, and how
they are used, spriting can still be the better option in
regards to compression and file size.

126. Inline Images
Another workaround for lack of parallelism in HTTP/1.x
Besides increasing the file size of stylesheets etc., the
resource can’t be cached and asset re-use will create
unnecessary overhead
Prioritisation features of HTTP/2 can’t be used

127. Preload & Server Push
Spec is not stable & work in progress.
Initiating server push eliminates the request roundtrip
between client and server for the declared preload link
resource.
Source

128. Preload & Server Push
<link rel="preload" href="/css/style.css" as=“style">
The as attribute can be omitted, important for prioritisation

129. Preload & Server Push
<?php
header('Link: </css/app.min.css>; rel=preload');
?>

131. Pushing 1 resource

132. Pushing 3 resources
First Paint: 287ms

133. Loading of required assets, saving the
request for those files
Predicting possible next pages, they will
load close to instant

134. Domain Sharding
And one more workaround for the lack of multiplexing in HTTP/1.x
Browsers can handle ~6 connections per origin, but domain sharding
allows to (theoretically) extend this to an unlimited amount of
connections.
Domain sharding will have a negative impact when used with HTTP/2.
!

135. HTTP/1.x HTTP/2
Reduce DNS lookups ✓ ✓
Reuse TCP connections ✓ ✓
Use a Content Delivery Network ✓ ✓
Minimize number of HTTP redirects ✓ ✓
Eliminate unnecessary request bytes ✓ ✓
Compress assets during transfer ✓ ✓
Cache resources on the client ✓ ✓
Eliminate unnecessary resources ✓ ✓
Apply domain sharding Max 2 Remove
Concatenate resources Careful & consider caching Remove
Inline resources Careful & consider caching Remove (Server Push)
Source

136. Running on HTTP/2

137. Does your server support HTTP/2?
Add SSL/TLS for a secure connection

138. Prepare your assets & adjust the build process
for H/2
Confirm your user’s browser support (Analytics)

139. Implement your favourite and most
beneficial H/2 best practices

140. It’s Not Only About Technology
Performance optimisation is a philosophy and
starts with understanding & acknowledging its
importance.
Sometimes this might even require some
convincing and possibly cultural change within
your team or organisation.

141. Web Performance Optimisation is
an ongoing & explorative journey,
not just a destination.
Holger Bartel | @foobartel | Topconf Tallinn 2016