1. Bastian Grimm
Peak Ace AG
@basgr
THE NEED FOR SPEED:
#WEBPERF 2018 EDITION

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. pa.ag@peakaceag6
USA Today created a super fast GDPR-compliant domain
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. pa.ag@peakaceag8
My favourite statistic regarding web performance
Source: Ericsson ConsumerLab, Neurons Inc. 2015
Solving a maths 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
mobile delays is
comparable to watching
a horror movie!

8. pa.ag@peakaceag10
Revisited: page speed (load time) is a ranking factor
Source: http://pa.ag/2iAmA4Y | http://pa.ag/2ERTPYY

9. pa.ag@peakaceag12
Now, please don’t forget your desktop; both are relevant!
Especially for responsive sites, this can be a massive challenge!
With the mobile-first index, will desktop rankings use
mobile page speed instead of desktop page speed?
No […] as mentioned […], while our index will be built from
mobile documents, we’re going to continue to build a great
search experience for all users, whether they come from
mobile or desktop devices.”
Source: Google spokesperson (https://pa.ag/2FGGKAi)

10. However, details really depend on each individual setup
#1 Get the basics absolutely right

11. pa.ag@peakaceag14
Client-side/front-end optimisation tasks
Use my checklist on SlideShare to double check:
All slides on SlideShare: http://pa.ag/iss18speed
▪ 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.

12. pa.ag@peakaceag15
Server-side/back-end optimisation tasks
Use my checklist on SlideShare to double check:
All slides on SlideShare: http://pa.ag/iss18speed
▪ 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 optimisation (e.g. mem-caching).
▪ General code & runtime optimisation (e.g. CPU utilisation).

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

14. pa.ag@peakaceag17
60% of all web traffic is made up of images...
The average website transfers between 800 and 900kB of images per URL!
Source: https://pa.ag/2xwHOFN

15. pa.ag@peakaceag18
Basic optimisation for all images: put ‘em on a diet!
tinyPNG & tinyJPG for smart (lossy) compression & removal of metadata et al.
API access, various plug-ins (WP, etc.) as well as direct integration into Photoshop.
Source: http://tinypng.com | http://tinyjpg.com

16. pa.ag@peakaceag19
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

17. pa.ag@peakaceag20
You can use WebP with an on-the-fly replacement
Swap PNG and JPEG images per re-write (i.e. using nginx / Apache configuration).
Alternatively: the <picture> element allows you to specify multiple file types manually.
VS.

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

19. pa.ag@peakaceag22
SEODAY could save 3.3 MB in images!
Better compression combined with modern image formats (i.e. WebP & JPEG-XR).

20. pa.ag@peakaceag23
We did this for one of our clients:
Overall image transfer traffic decreased from 550GB to 140GB (a 75% reduction)!
(To be fair: only half of their JPGs were properly optimised beforehand.)

21. Because latency does matter, especially for international sites!
Let’s talk (image) CDNs for a minute

22. pa.ag25
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 predominantly serving:
Give it a try: https://www.cdnperf.com/

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

24. Pretty, varied, colourful, and often very slow!
#3 Custom web fonts

25. pa.ag@peakaceag28
>70% of all websites use at least one non-standard font!
Result: 97kB of additional data and on average 3-4 additional HTTP requests.
Source: https://pa.ag/2I7vAHC

26. pa.ag@peakaceag29
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 finished!

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

28. pa.ag@peakaceag31
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

29. pa.ag@peakaceag32
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’ enables text to be displayed while the font itself is still loading!

30. pa.ag@peakaceag33
Don‘t miss Monica Dinculescu‘s incredible talk:
”Fontastic Web Performance“
Watch the full talk: https://pa.ag/2qf6hvK

31. pa.ag@peakaceag34
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!

32. Because the PageSpeed Insights score is not enough!
#4 Better measurement

33. pa.ag@peakaceag36
Translating experiences into 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?
▪ Is it usable?
› Can users interact with the page or
is it still busy loading?
▪ Is it smooth/pleasing?
› 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)

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

35. pa.ag@peakaceag38
Optimising for and measuring paint timings
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.
First Paint (FP) First Contentful
Paint (FCP)
#1 #2 #3 #4

36. pa.ag@peakaceag39
Optimising for and measuring paint 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!

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

38. pa.ag@peakaceag41
Chrome Dev Tools > Performance > Profiling (Frames)

39. pa.ag@peakaceag42
Track paint times 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)

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

41. pa.ag@peakaceag44
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.

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

43. pa.ag@peakaceag46
New: Google just introduced “First Input Delay” (FID)
Measure 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, a button, or use a custom,
JavaScript-powered control) to the time when
the browser is actually able to respond to
that interaction.

44. pa.ag@peakaceag47
Wait… what?!
Put simply, this is what FID is supposed to reflect:
For example, on a blog, it’s most likely to be
reflected by the time taken between someone
clicking a link and the browser responding to
that interaction (i.e. requesting the next page to
load). The reason there might be a delay is if the
browser’s main thread is busy doing something
else (usually executing JavaScript code).

45. pa.ag@peakaceag48
Time to Interactive (TTI) vs. First Input Delay (FID)
TTI measures how long it takes a site to load and be able to respond to interaction. 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 is loaded and
browser can paint content
Browser is loaded and
browser can paint content
FID
TTI
FCP
Network
requests
Main
thread

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

47. pa.ag@peakaceag50
Diagnosing a higher-than-expected FID
Create a performance trace of your site as it’s loading (CPU & network throttling enabled)
and look for individual tasks on the main thread that take a long time to execute:
More: https://pa.ag/2MMEEmd

48. pa.ag@peakaceag51
Coming soon: image (hero element) visibility tracking
Current state: intent to implement (in Chrome) via Element Timing API
Source: https://pa.ag/2xwF6jB
The Element Timing API will allow developers
to know when certain important image elements
are first displayed on the screen. It will also enable
them to measure the display time of images that
take up a large fraction of the viewport when they
first show up. This will let them understand, measure,
and improve user discomfort when waiting for
important elements to be displayed.

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

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

51. A brief, technical overview:

52. pa.ag@peakaceag55
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:18px;
h1
font-size:22px;
a
font-size:12px;
div
font-size:16px;
p
font-size:12px;
p
font-size:16px;

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

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

55. pa.ag@peakaceag58
How to know which CSS is critically required
“Critical” renders in multiple resolutions and 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!

56. pa.ag@peakaceag59
<!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 are necessary for “Start Render” into the first 14kB 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

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

58. pa.ag@peakaceag61
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.

59. pa.ag@peakaceag62
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).

60. pa.ag@peakaceag63
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 inline.

61. pa.ag@peakaceag64
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%)

62. pa.ag@peakaceag65
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 above the fold 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.

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

64. AMP certainly encourages people to take the need
for fast loading sites more seriously.
Drives discussion/innovation

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

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

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

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

69. Seriously, just putting it on GitHub doesn’t make it less regulated!
Not really open-source

70. AMP makes it easier for them (same structure) and it’s even
hosted on Google. Also, consider changing crawl behaviour (another URL).
Can impact crawling

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

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

73. pa.ag@peakaceag76
Publisher Type
Start Render
(in sec)
Load Time
(in sec)
First Interactive
(in sec)
Speed Index
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)

74. pa.ag@peakaceag77
AMP vs. regular website: major German newspapers
German newspapers have faster websites (compared to UK, except for The Guardian),
thus the gap/difference with regards to their AMP domains is even smaller!
Source: Peak Ace AG research (March 2018)
Publisher Type
Start Render
(in sec)
Load Time
(in sec)
First Interactive
(in sec)
Speed Index
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

75. pa.ag@peakaceag78
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.

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

77. So, what should you do?

78. pa.ag@peakaceag81
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. First, invest
in your property to become best-in-class,
before considering using AMP, if at all.”

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

80. Still in alpha - but really, really cool…
#8 Bonus: predictive pre-*

81. pa.ag@peakaceag84
Interesting concept: predictive #webperf with guess.js
guess.js’ goal is to make the web faster and smarter by replacing manual decision
making with an automated data-driven approach:
More: https://pa.ag/2kEJfLy & https://pa.ag/2NGgwH5
Calculating the likelihood
of visiting a link within the
viewport, using guess.js
to pre-fetch/render.

82. pa.ag@peakaceag85
gatsby.js + guess.js = insanely fast!
Manage in WP, combine with APIs, export into a static PWA (backed by React)
Source: https://www.gatsbyjs.org/

83. pa.ag@peakaceag86
We’re hiring! 30+ performance marketing jobs in Berlin!
Come and say “hello” or apply via jobs.pa.ag. We look forward to talking to you!
Always looking for talent!
Check out jobs.pa.ag

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