Web Performance in the Age of HTTP2 - Topconf Tallinn 2016 - Holger Bartel

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

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

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

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

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

Conclusion 
Faster is Better!

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

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

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

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

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.

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

Today, 49% expect load times of 2
seconds or less, and 18%—one out of
ﬁve—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.

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.

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

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

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

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
ﬁery circle.
3 types of sensory memories (vision, sound and touch).
Source

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

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

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

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

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.

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

Front End Development (~75%)Network/Server

What’s the best
performance strategy,
you ask?

– 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.”

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

Webpage Test
https://www.webpagetest.org

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.

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

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

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

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

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

https://testmysite.thinkwithgoogle.com/

— 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?”

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

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

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

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

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

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

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 ﬁles are scalable and will
always look sharp and crisp.

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.

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

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

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

Optimising the critical
rendering path

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

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

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
ﬁring DOMContentLoaded.

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

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

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

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.

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

Building for Performance  
with HTTP/2

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

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

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

Serving HTTP/2
Apache Module mod_h p2

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

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

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

New!
Requests are cheap!
• Structure code modularly - deliver only what’s
needed
• Build process simpliﬁcation
• Optimise caching policies - depends on  
the change frequency of ﬁles

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 ﬁle size.

Inline Images
Another workaround for lack of parallelism in HTTP/1.x 
Besides increasing the ﬁle 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

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

<?php
header('Link: </css/app.min.css>; rel=preload');
?>

Pushing 3 resources
First Paint: 287ms

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

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

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

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

Prepare your assets & adjust the build process
for H/2 
Conﬁrm your user’s browser support (Analytics)

Implement your favourite and most
beneﬁcial H/2 best practices

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.

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

Web Performance in the Age of HTTP2 - Topconf Tallinn 2016 - Holger Bartel

More Related Content

What's hot

Viewers also liked

Similar to Web Performance in the Age of HTTP2 - Topconf Tallinn 2016 - Holger Bartel

More from Holger Bartel

Recently uploaded

Web Performance in the Age of HTTP2 - Topconf Tallinn 2016 - Holger Bartel