web performance in the age of http2 - topconf tallinn 2016 - holger bartel
Post on 12-Apr-2017
127 Views
Preview:
TRANSCRIPT
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
“… 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
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
top related