Especially in a mobile-first world, fast loading websites are of utmost importance. Also, Google has been very vocal about anything web performance in the last few years and is pushing hard to innovate repeatedly. But performance is so much more! User satisfaction should be the main goal because expectations are clear: You’ve got two to three seconds maximum to deliver, so make it count. During Bastian's SearchLeeds 2018 talk he walked through various advanced topics around web performance optimisation going way beyond Accelerated Mobile Pages (and other short-term solutions) to make any website really, really fast.

1. Bastian Grimm, Peak Ace AG | @basgr
The latest in #webperf 2018: better metrics, images, custom fonts & CRP
Super speed around the globe

2. I’ve got some serious issues…

3. For me, there is nothing worse than having to wait for anything to load!
I’m not a very patient guy…

4. GDPR is actually pretty cool!

5. 5 @peakaceag pa.ag
USA Today created a superfast GDPR compliant offering
500 vs. 34 requests, 140 vs. 0 JS files, 6 vs. 1 CSS, 5.01 MB vs. 356 kB in size, etc.
EU
0.300 sec
0.345 sec
0.995 sec
443
US
1.700 sec
3.604 sec
19.261 sec
8,792
Start Render
First Interactive
Load Time
Speed Index
34 859Total Requests
356 kB 5,092 kBBytes in

6. Fast loading time plays an important role in overall user experience!
Performance = user experience!

7. 7 @peakaceag pa.ag
Google loves site speed and keeps pushing for faster sites

8. 8 @peakaceag pa.ag
Revisited: PageSpeed (load time) is a ranking factor
Source: http://pa.ag/2iAmA4Y & http://pa.ag/2ERTPYY

9. 9 @peakaceag pa.ag
My favourite statistics regarding web performance
Source: Ericsson ConsumerLab, Neurons Inc. 2015
Solving a math problem
Experiencing mobile delays
Watching a horror movie
Standing at the edge of a virtual cliff
Watching a melodramatic TV show
Waiting in line at a retail store
Level of stress caused by
delays on mobile is
comparable to watching
a horror movie!

10. 10 @peakaceag pa.ag
Let’s get this straight – this is what your users expect:
Obviously, slow page loading time is a major factor in page abandonment.
According to a Nielsen report, 47% of people expect
a website to load within two seconds, and 40%
will leave a website if it does not load fully within
three seconds.”

11. However, details really depend on the individual setup
#1 Absolutely get the basics right

12. 12 @peakaceag pa.ag
▪ Establish a content-first approach: progressive enhancement,
also prioritise visible above the fold content: 14kB (compressed).
▪ Reduce size: implement effective caching and compression.
▪ Whenever possible, use asynchronous requests.
▪ Decrease the size of CSS and JavaScript files (minify).
▪ Lean mark-up: no comments, use inline CSS/JS only where
necessary or useful.
▪ Optimise images: reduce overhead for JPGs & PNGs (metadata,
etc.), request properly sized images and try new formats.
▪ Minimise browser reflow & repaint.
Client-side/front-end optimisation tasks
Use my checklist on SlideShare to double check:
All slides on SlideShare: http://pa.ag/iss18speed

13. 13 @peakaceag pa.ag
▪ Use (DNS) pre-fetching & pre-rendering (resource hints).
▪ Use a content distribution network (CDN)/an asset server (as
well as cookie-less domains) to optimise parallel requests.
▪ Switch to HTTPS, combine by utilising HTTP/2 and HTTP/2
specific features (e.g. ServerPush).
▪ Leverage browser caching, also consider using edge caching.
▪ Enable OCSP stapling (for HTTPS) to speed up CA validation.
▪ Database & query optimisations (e.g. mem-caching)
▪ General code & runtime optimisations (e.g. CPU utilisation)
Server-side/back-end optimisation tasks
Use my checklist on SlideShare to double check:
All slides on SlideShare: http://pa.ag/iss18speed

14. By now everyone should be on HTTPS, right?
#2 HTTP/2

15. 15 @peakaceag pa.ag
Last chance: Chrome goes full HTTPs in July 2018!
Chrome 68 (July) is going to flag every single HTTP URL as “non-secure”!
Chrome 70 (Sept.) will remove “secure” for HTTPs, again.
Source: http://pa.ag/2rmIAjg

16. Because the server does all the work!
Your devs don‘t need to do much

17. 17 @peakaceag pa.ag
Check out Tom Anthony’s great presentation on HTTP/2
All you need to know about the new protocol and how to get the most out of it!
Get the slides: https://pa.ag/2whWhr9

18. 18 @peakaceag pa.ag
HTTP/2 specific optimisation strategies & features
e.g. CSS sprites, but „it really depends“ (on your setup) or domain sharding, etc.
Source: http://pa.ag/2pmhObg

19. Highest quality, (more) efficient data compression & smaller files
#3 Image optimisation

20. 20 @peakaceag pa.ag
62% of all web traffic is made up of images...
… and 51% of all URLs load more than 40 images per request.
Source: http://pa.ag/1SGDOEo
Average bytes per page by content type Image requests per page

21. 21 @peakaceag pa.ag
Basic optimisation for all images: put ‘em on a diet!
tinyPNG & tinyJPG for smart (lossy) compression & removal of metadata et al.
http://tinypng.com | http://tinyjpg.com

22. 22 @peakaceag pa.ag
WebP: Google’s alternative to JPEG, PNG, and GIF
Lossy & lossless compression, transparency, metadata, colour profiles, animation, and
much smaller files (30% vs. JPEG, 80% vs. PNG) – but only in Chrome, Opera & Android
Everything about WebP: http://pa.ag/1EpFWeN / & WebP support: http://pa.ag/2FZK4XS

23. 23 @peakaceag pa.ag
You can still use WebP with on-the-fly replacement
Swap PNG and JPEG images per re-write (i.e., using .htaccess)
VS.

24. 24 @peakaceag pa.ag
There is way more: FLIF, BPG, JPEG-XR, etc.
If you’re “image-heavy”, play around with it!
Further reading: http://pa.ag/1S5OQmX

25. 25 @peakaceag pa.ag
SearchLeeds could save 1.74 (out of 1.90) MB in images!
Better compression combined with modern image formats (i.e. WebP & JPEG-XR)

26. 26 @peakaceag pa.ag
Pretty impressive: 2x growth in purchase conversions
Furnspace doubled their numbers through image optimisation!
Source: https://pa.ag/2wsTn2X
2x growth in purchase conversions
7% increase in share of revenue from mobile visitors,
growing from 38% to 45%
2x longer engagement time on page
65% faster web page download time, saving 11 sec.
86% reduction in image payload

27. Because latency does matter, especially for international sites!
Let’s talk CDNs for a minute

28. 28 @peakaceag pa.ag
Especially for global businesses, CDNs can be a great help
Use CDNPerf.com to find the one that suits you best, depending on where you are and
which regions/countries you‘re mainly serving to:
Give it a try: https://www.cdnperf.com/

29. 29 @peakaceag pa.ag
Test your (CDN) latency from all over the world:
Try it out: https://pa.ag/2HX6aje

30. Pretty, varied, colourful, and often very slow!
#4 Custom web fonts

31. 31 @peakaceag pa.ag
>70% of all websites use at least one non-standard font!
Result: 114 kB of additional data and on average 3 additional HTTP requests
Source: http://pa.ag/1BRUnbe
Font transfer size & font requests Sites with custom fonts
Font transfer size (kB) Font requests

32. 32 @peakaceag pa.ag
Classic scenario: using external CSS
Easy to use with one big disadvantage: it’s render-blocking!
CSS (font) call to Google causes
the render to stop / block until
the download has been finished!

33. FOIT (flash of invisible text) or FOUT (flash of unstyled text)
can cause annoying flickering
Asynchronous?

34. 34 @peakaceag pa.ag
Fighting the flash of unstyled text/content
Make your fall-back font match the intended web font (letter spacing, heights, etc.)
Give it a try: https://pa.ag/2qgE8EH

35. 35 @peakaceag pa.ag
Fighting the flash of invisible text
New stuff to play around with: various “font-display” strategies (no IE/Edge yet)
More: http://pa.ag/2eUwVob
‘font-display’ allows to display text while the font for it is still loading!

36. 36 @peakaceag pa.ag
Don‘t miss Monica Dinculescu‘s great talk titled
„Fontastic Web Performance“
Watch the full talk: https://pa.ag/2qf6hvK

37. 37 pa.ag@peakaceag
If you can only do one thing, I’d recommend doing this:
100ms blocking period, but no swap. Even after it’s downloaded (only on next page view)
Go to your CSS file, look for @font-face and add
’font-display:optional’ - there hasn’t been a
safer & easier gain in #webperf in a long time!

38. Because the PageSpeed Insights score is not enough!
#5 Better measurement

39. 39 @peakaceag pa.ag
Translating experiences to performance metrics
User experience
▪ Is it happening?
› Did the navigation start successfully?
Has the server responded?
▪ Is it useful?
› Has enough content rendered for users
to engage with it?
▪ Is it usable?
› Can users interact with the page or is it
still busy loading?
▪ Is it smooth/delightful?
› Are the interactions smooth and
natural, free of lag and jank?
Corresponding metric
First Paint (FP)/First Contentful Paint (FCP)
First Meaningful Paint (FMP) -> Hero Element Timing
Time to Interactive (TTI)
Long tasks (technically the absence of those long tasks)

40. 40 @peakaceag pa.ag
Optimising and measuring for painting timings
#1 #2
First Paint (FP)
Time to First Paint – marks the point when the
browser starts to render something, the first bit of
content on the screen.

41. 41 @peakaceag pa.ag
Optimising and measuring for painting timings
#1 #2 #3 #4
First Paint (FP) First Contentful
Paint (FCP)
Time to First Paint – marks the point when the
browser starts to render something, the first bit of
content on the screen.
Time to First Contentful Paint – marks the point when
the browser renders the first bit of content from the
DOM, text, an image etc.

42. 42 @peakaceag pa.ag
Optimising and measuring for painting timings
#1 #2 #3 #4 #5 #6
First Paint (FP) First Contentful
Paint (FCP)
First Meaningful
Paint (FMP) / Hero!
Time to Interactive
(TTI)
Time to First Paint – marks the point when the
browser starts to render something, the first bit of
content on the screen.
First Meaningful Paint – the paint after which the
biggest above-the-fold layout change has happened
and your most important element is visible!

43. 43 @peakaceag pa.ag
Watching a video on YouTube? This is your hero element:

44. 44 @peakaceag pa.ag
Chrome Dev Tools > Performance > Profiling (Frames)

45. 45 @peakaceag pa.ag
Track paint timings with Google Analytics (in theory)
Get the tracking code snippets: http://pa.ag/2viHQSz
version 62 and up
You must ensure your
PerformanceObserver is
registered in the <head>
before any stylesheets, so it
runs before FP/FCP happens.
(a buffered flag TBD in v.2)

46. 46 @peakaceag pa.ag
This is how it looks like in Google Analytics
Behaviour > events > pages: performance metrics [first-contentful-paint]
Source: Google Analytics

47. 47 @peakaceag pa.ag
The cool kids’ way of doing this (using GTM)
#1 #3
#2 #4
This needs to go directly
into your HTML mark-up
because GTM doesn’t
support ES6 script atm.

48. 48 @peakaceag pa.ag
Combine it with Google Data Studio
Test it: http://pa.ag/2Ee550q

49. 49 pa.ag@peakaceag
Google just introduced “First Input Delay” (FID)
Measuring how responsive your site is when users try to interact with it!
First Input Delay (FID) measures the time from
when a user first interacts with your site (i.e.
when they click a link, tap on a button, or use a
custom, JavaScript-powered control) to the time
when the browser is actually able to respond to
that interaction.

50. 50 pa.ag@peakaceag
Time to Interactive vs First Input Delay
TTI measures how long it takes a site to load and be capable to respond to interactions.
FID measures the delay when someone interacts while the page is not yet active.
The user just happened to
interact with the page at
the beginning of the main
thread’s busiest period (e.g.
CSS/JS execution). If the
user had interacted just a
moment earlier (during the
idle period), the browser
could have responded right
away.
Main thread is idle
Main thread is busy
Styles are loaded and
browser can paint content
Navigation
start
Main thread is
idle for 5+ seconds
Browser are loaded and
browser can paint content
Browser are loaded and
browser can paint content
FID
TTI
FCP
Network
requests
Main
thread

51. 51 @peakaceag pa.ag
Tracking FID in JavaScript using Google Analytics
More: https://pa.ag/2IlRV7O

52. The code and resources required to render the initial view of a web page
#6 Critical rendering path

53. 53 @peakaceag pa.ag
Critical rendering path optimisation
Initial view
(critical)
Below the fold
(not critical)

54. Some brief, technical background:

55. 55 @peakaceag pa.ag
CSSOM: the CSS Object Model
▪ The CSSOM is a “map” of the CSS styles found
on a web page.
▪ It’s much like the DOM (Document Object
Model), but for CSS rather than HTML.
▪ The CSSOM combined with the DOM is used by
browsers to display web pages.
body
font-size:16px;
h1
font-size:22px;
p
font-size:16px;
p
font-size:12px;
a
font-size:12px;
img
font-size:16px;

56. 56 @peakaceag pa.ag
Web browsers use the CSSOM to render a page
If this is external CSS, the browser
needs to wait for the download.

57. 57 @peakaceag pa.ag
Google doesn’t make a single GET request for its CSS!
Because requesting external CSS is more expensive than inlining everything.

58. 58 @peakaceag pa.ag
How to know which CSS is critically required
“Critical” renders in multiple resolutions & builds a combined/compressed CRP CSS:
Critical & criticalCSS on GitHub: http://pa.ag/2wJTZAu & http://pa.ag/2wT1ST9
▪ Minimum: a snapshot of CSS rules to
render a default desktop resolution
(e.g. 1280x1024).
▪ Better: various snapshots for mobile
phones, pad/s & desktop/s – manually
that’d be a lot of work!

59. 59 @peakaceag pa.ag
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width">
<title>CRP loading demo</title>
<!-- critical CSS goes here -->
<style> h1 { colour: green; } </style>
<!-- use async preload // no IE, Edge & some other unimportant ones (http://caniuse.com/#search=preload) -->
<link rel="preload" href="non-critical.css" as="style" onload="this.rel='stylesheet'" />
<!--noscript for req. without JS -->
<noscript><link rel="stylesheet" href="non-critical.css"></noscript>
<!-- include polyfill for shitty browsers -->
<script>
*! loadCSS. [c]2017 Filament Group, Inc. MIT License */
(function(){ ... } ());
/*! loadCSS rel=preload polyfill. [c] 2017 Filament Group, Inc. MIT License */
(function(){ ... } ());
</script>
</head>
<body>
</body>
</html>
<!-- use async preload // no IE, Edge & some other unimportant ones
(http://caniuse.com/#search=preload) -->
<link rel="preload" href="non-critical.css" as="style" onload="this.rel='stylesheet'" />
<!-- critical CSS goes here -->
<style> h1 { colour: green; } </style>
<!-- use async preload // no IE, Edge & some other unimportant ones
(http://caniuse.com/#search=preload) -->
<link rel="preload" href="non-critical.css" as="style" onload="this.rel='stylesheet'" />
<!--noscript for req. without JS -->
<noscript><link rel="stylesheet" href="non-critical.css"></noscript>
*! loadCSS. [c]2017 Filament Group, Inc. MIT License */
(function(){ ... } ());
/*! loadCSS rel=preload polyfill. [c] 2017 Filament Group, Inc. MIT License */
(function(){ ... } ());
Putting it all together
Fit the HTML, CSS & JS that’s necessary for “Start Render” into that first 14 kB round trip!
Inline your critical CSS.
1
Loading non-critical CSS
async using rel=“preload“.
2
Apply the CSS once it has
finished loading via “onload“.
3
Fallback for non-JS requests.
4
Implement loadCSS script for
older browsers.
5

60. Let’s look at an implementation…
Is it worth all the effort?

61. 61 @peakaceag pa.ag
Before & after: a fresh WordPress setup #1
HTTP, no HTTP/2, Twenty Seventeen theme (1x CSS, 8x JS, custom fonts), no caching
and no other performance optimisations

62. 62 @peakaceag pa.ag
Before & after: a fresh WordPress setup #2
HTTP, no HTTP/2, Twenty Seventeen theme (1x CSS, 8x JS, custom fonts), W3Total (CSS,
JS, HTML minify, caching, compression)

63. 63 @peakaceag pa.ag
Before & after: a fresh WordPress setup #3
HTTP, no HTTP/2, Twenty Seventeen theme (1x CSS, 8x JS, custom fonts), W3Total (CSS,
JS, HTML minify, caching, compression) + CRP CSS inlined

64. 64 @peakaceag pa.ag
Performance metrics comparison at a glance
Rendering starts significantly earlier; this allows for faster interaction with the site.
KPI / MEASUREMENT
Load Time
Time to First Byte (TTFB)
Start Render
Time to Interactive (TTI)
DEFAULT WP
1.357 sec
0.454 sec
1.000 sec
0.956 sec
BASICS (W3TOTAL)
0.791 sec
0.159 sec
0.600 sec
0.931 sec
FULLY OPTIMISED
0.789 sec
0.157 sec
0.410 sec
0.563 sec
(+32%)
(+41%)

65. 65 @peakaceag pa.ag
TL;DR
Implement proper tracking, measure “First Meaningful Paint” (Hero Element delivery).
Audit, clean, and (afterwards) split CSS into two parts: “initial view” and “below the fold”.
Use “critical” to generate and inline your critical path CSS.
Use rel=“preload“ and “loadCSS” to async load below the fold / site-wide CSS.
Off-load all overhead (JS, etc.) to stay within 14kB for faster, initial paint.

66. … and feel free to disagree, but please think about it for a minute.
#7 Let’s talk AMP

67. AMP certainly helps to push people to take the need
for fast loading sites more seriously.
Drives discussion/innovation

68. Suddenly, different teams/stakeholders (have to) care
about performance and it becomes an “agenda topic”.
Enables collaboration

69. Converting existing sites to AMP almost never works, you need to rebuild
the entire HTML & CSS from scratch (which takes time & resources).
Creates additional effort

70. Extending CMS capabilities to manage AMP content is expensive,
additional maintenance (IT, editorial, etc.) increases costs further.
Maintenance & costs

71. 71 @peakaceag pa.ag
The average user doesn’t understand what is happening
Everything they search for will be served to them on Google’s “portal”.
Navigation behaviour changes as well; swiping is THE way to navigate on Google!
#1 #2 #3 #4

72. Seriously, just putting it on GitHub doesn’t make it less controlled!
Not really open source

73. They “use” you to make it easy for them (same structure) and it’s even
hosted on Google. Also, consider changed crawl behaviour (another URL).
Can impact crawling

74. … because we are talking web performance!
Maybe all this shouldn’t matter…

75. Actually, AMP is not really *that* fast…
Google is cheating with speed

76. 76 @peakaceag pa.ag
Publisher Type
Start Render
(in s)
Load Time
(in s)
First Interactive
(in s)
SpeedIndex
The Guardian AMP 1.466 2.664 4.600 1,989
The Guardian Responsive 0.567 5.871 7.167 1,226
The Telegraph AMP 1.300 1.494 8.785 1,520
The Telegraph Responsive 1.700 10.188 15.692 5,724
Daily Mail AMP 1.200 2.153 1.246 1,636
Daily Mail Responsive 1.933 9.746 4.340 5,810
CNN AMP 0.900 8.577 14.605 1,876
CNN Responsive 1.543 15.543 17.458 8,567
AMP vs. regular website: major UK newspapers
The Guardian mostly outperforms AMP with its regular sites (well done!)
(Settings for WPT: London, Chrome, Cable)
Source: Peak Ace AG research (May 2018)

77. 77 @peakaceag pa.ag
AMP vs. regular website: major German newspapers
German newspapers offering faster websites (compared to UK, except for Guardian),
thus the gap/difference to their AMP offering is even smaller!
Source: Peak Ace AG research (March 2018)
Publisher Type
Start Render
(in s)
Load Time
(in s)
First Interactive
(in s)
SpeedIndex
ZEIT Online AMP 1.000 1.168 2.272 1,151
ZEIT Online Responsive 0.400 1.985 2.177 1,024
stern AMP 0.900 0.907 3.363 1,058
stern m-Subdomain 0.300 2.243 2.087 909
Süddeutsche AMP 1.100 1.654 2.804 1,817
Süddeutsche Responsive 2.200 4.935 4.988 2,768
Spiegel Online AMP 1.100 1.138 2.089 1,112
Spiegel Online m-Subdomain 1.500 3.921 5.101 2,519

78. 78 @peakaceag pa.ag
AMP magic: pre-fetching, pre-rendering (and caching)
There is ~1 second avg. difference from the pre-
rendering vs. direct load of any AMP. That’s speed
you can’t make up and the perceived loading time
for a user is even greater.

79. 79 @peakaceag pa.ag
We are taking what we learned from
AMP, and are working on web
standards that will allow instant
loading for non-AMP web content.
Pre-fetching & pre-rendering outside of AMP?
If you‘ve been following the news, this shouldn‘t have come as a surprise:
More: http://pa.ag/2FyeT6h

80. Only if you go full PWAMP (Progressive Web App + AMP)
secondary – and following – clicks/interactions will be fast as well.
Only the 1st request is fast

81. So, what should you do?

82. 82 @peakaceag pa.ag
Please take care of your website first:
(Whether you like AMP or not)
Using AMP must NOT be an excuse for having a
slow-loading website. Invest in your property to
become best-in-class first, before even considering
using AMP, if at all.”

83. 83 @peakaceag pa.ag
If you still feel like implementing AMP, here you go:
Aleyda has this fantastic deck with loads of tips for free on her SlideShare!
Get the slides: https://pa.ag/2FQjBMa

84. Anyone?
#8 One last thing… guess.js?

85. 85 @peakaceag pa.ag
Rather join the cool kids: predictive #webperf with guess.js
guess.js’ goal is to make the web faster and smarter by replacing the manual decision
making with an automated data-driven approach:
More: https://pa.ag/2kEJfLy & https://github.com/guess-js/guess
Calculating the likely-
hood to visit a link
within the viewport:
combining guess.js &
Gatsby to pre-render

86. 86 @peakaceag pa.ag
http://pa.ag/leeds18perf
ALWAYS LOOKING FOR TALENT! CHECK OUT JOBS.PA.AG
Bastian Grimm
bg@pa.ag
twitter.com/peakaceag
facebook.com/peakaceag
www.pa.ag
Liked the deck? Here you go:
WINNER