Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The need for Speed: Advanced #webperf - SEOday 2018

1,046 views

Published on

My deck on #webperf from SEOday 2018 in Cologne. Especially in a mobile-first world, fast loading websites are of outmost importance. Also, Google has been very vocal about anything web performance in the last 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 seconds maximum to deliver, so make it count. In this deck I will be walking you 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.

Published in: Technology

The need for Speed: Advanced #webperf - SEOday 2018

  1. 1. Bastian Grimm Peak Ace AG @basgr THE NEED FOR SPEED: #WEBPERF 2018 EDITION
  2. 2. I’ve got some serious issues…
  3. 3. For me, there is nothing worse than having to wait for anything to load! I’m not a very patient guy…
  4. 4. GDPR is actually pretty cool!
  5. 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. 6. Fast loading time plays an important role in overall user experience! Performance = user experience!
  7. 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. 8. pa.ag@peakaceag10 Revisited: page speed (load time) is a ranking factor Source: http://pa.ag/2iAmA4Y | http://pa.ag/2ERTPYY
  9. 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. 10. However, details really depend on each individual setup #1 Get the basics absolutely right
  11. 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. 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. 13. Highest quality, (more) efficient data compression & smaller files #2 Image optimisation
  14. 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. 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. 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. 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. 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. 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. 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. 21. Because latency does matter, especially for international sites! Let’s talk (image) CDNs for a minute
  22. 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. 23. pa.ag26 Test your (CDN) latency from all over the world: Try it out: https://pa.ag/2HX6aje
  24. 24. Pretty, varied, colourful, and often very slow! #3 Custom web fonts
  25. 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. 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. 27. FOIT (flash of invisible text) or FOUT (flash of unstyled text) can cause irritating flickering Asynchronous?
  28. 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. 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. 30. pa.ag@peakaceag33 Don‘t miss Monica Dinculescu‘s incredible talk: ”Fontastic Web Performance“ Watch the full talk: https://pa.ag/2qf6hvK
  31. 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. 32. Because the PageSpeed Insights score is not enough! #4 Better measurement
  33. 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. 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. 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. 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. 37. pa.ag@peakaceag40 Watching a video on YouTube? This is your hero element:
  38. 38. pa.ag@peakaceag41 Chrome Dev Tools > Performance > Profiling (Frames)
  39. 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. 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. 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. 42. pa.ag@peakaceag45 Combine it with Google Data Studio Test it: http://pa.ag/2Ee550q
  43. 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. 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. 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. 46. pa.ag@peakaceag49 Tracking FID in JavaScript using Google Analytics More: https://pa.ag/2IlRV7O
  47. 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. 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. 49. The code and resources required to render the initial view of a web page #5 Critical rendering path
  50. 50. pa.ag@peakaceag53 Critical rendering path optimisation Initial view (critical) Below the fold (not critical)
  51. 51. A brief, technical overview:
  52. 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. 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. 54. pa.ag@peakaceag57 Google doesn’t make a single CSS GET request! Because requesting external CSS is more expensive than inlining everything.
  55. 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. 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. 57. Let’s look at an implementation example… Is it worth all the effort?
  58. 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. 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. 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. 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. 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. 63. … and feel free to disagree, but please think about it for a minute. #6 Let’s talk AMP
  64. 64. AMP certainly encourages people to take the need for fast loading sites more seriously. Drives discussion/innovation
  65. 65. Suddenly, different teams/stakeholders (have to) care about performance and it becomes an “agenda topic”. Enables collaboration
  66. 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. 67. Extending CMS capabilities to manage AMP content is expensive, additional maintenance (IT, editorial, etc.) further increases costs. Maintenance & costs
  68. 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. 69. Seriously, just putting it on GitHub doesn’t make it less regulated! Not really open-source
  70. 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. 71. … because we are talking web performance! Maybe all this shouldn’t matter…
  72. 72. Actually, AMP is not really *that* fast… Google is cheating with speed
  73. 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. 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. 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. 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. 77. So, what should you do?
  78. 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. 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. 80. Still in alpha - but really, really cool… #8 Bonus: predictive pre-*
  81. 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. 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. 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. 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

×