Web Performancein the Age of HTTP/2

Holger Bartel | @foobartel | Topconf Tallinn 2016

From 🐢 to 🚀.

Your mileage may vary.

It really depends sometimes…

As with most things:

Performance is

Design

Design

We've come a long way!

Source

A World of Bloat

Total Page Weight: 13.1 Mb

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

Perception of time

And it’s been like that for a long time.

https://commons.wikimedia.org/wiki/

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.

Perception & the Brain

FactFast 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 five—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 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.

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 fiery 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 flows.

Actions “flow” 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.

Performance Basics

Planning & Strategy

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

TFDI

Analysing your project

Test for performance

Find your bottlenecks

Decide what’s important

Identify the low hanging fruit

Analysing your project

Test for performance

Find your bottlenecks

Decide what’s important

Identify the low hanging fruit

Rinse and Repeat

Waterfall Chart

Network Throttling

Webpage Test

https://www.webpagetest.org

Filmstrip

Filmstrip - Video Export

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 IndexVi

sual

Com

plet

enes

s

0

25

50

75

100

Time (ms)100 200 300 400 500 600 700 800 900 1000 1100 1200

Source

Visu

al C

ompl

eten

ess

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

Speed Index (better)

0

25

50

75

100

100 200 300 400 500 600 700 800 900 1000 1100 1200

Source

Google Page Speed Insights

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

vartiming=performance.timing;varapi={};

//Totaltimefromstarttoloadapi.loadTime=timing.loadEventEnd-timing.fetchStart;

//TimespentconstructingtheDOMtreeapi.domReadyTime=timing.domComplete-timing.domInteractive;

//TimeuntilfirstpaintfirstPaint=window.chrome.loadTimes().firstPaintTime*1000;api.firstPaintTime=firstPaint-(window.chrome.loadTimes().startLoadTime*1000);

Timing.js

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

The “low hanging fruit”

First up: Images

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 files 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 first request

Base64 images affect SEO because they will not be indexed by Google.

Images won’t be cached, which can have negative effects

Optimising CSS, JavaScript

Taming frameworks

B

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 files (PHP etc) and dynamic class names (JS)

Need to extract all class names from static pages

15.689 unused rules!!! 😫

Good: 55 Unused rules

Towards extreme performance

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

firing 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/filamentgroup/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.HT

TP/1

.x

Multiplexing

Compressed headers

Asset Prioritisation & Dependencies

Server Push (saves the time it takes the client to ask for the resources)HT

TP/2

The Road to H/2

SSL/TLS required

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

Serving HTTP/2

Apache Module mod_h!p2

HTTP/2 supporting browsers

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 files into one and fetch with one request.

Need to wait for the entire file/response to arrive.

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

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.

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

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

Preload & Server Push

<link rel="preload" href="/css/style.css" as=“style">

The as attribute can be omitted, important for prioritisation

Preload & Server Push

<?php

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

?>

Pushing 1 resource

Pushing 3 resources

First Paint: 287ms

Loading of required assets, saving the request for those files

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

Running on HTTP/2

Does your server support HTTP/2?

Add SSL/TLS for a secure connection

Prepare your assets & adjust the build process for H/2

Confirm your user’s browser support (Analytics)

Implement your favourite and most beneficial 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