Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Super speed around the globe - SearchLeeds 2018

3 322 vues

Publié le

My talk covering some of the very latest in web performance optimisation (paint timings, critical rendering path, custom web fonts, etc.) for technical marketers & SEOs from SearchLeeds 2018.

Publié dans : Technologie
  • How to Manifest Anything You Want in 24 hours ▲▲▲ https://tinyurl.com/y6pnne55
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Secrets To Making Up, These secrets will help you get back together with your ex.  http://goo.gl/FXTq7P
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • ➤➤ How Long Does She Want You to Last? Here's the link to the FREE report ■■■ http://ishbv.com/rockhardx/pdf
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Anychance you can change this so it can be downloaded? Was at searchleeds, excellent talk
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

Super speed around the globe - SearchLeeds 2018

  1. 1. Bastian Grimm, Peak Ace AG | @basgr The latest in #webperf 2018: better metrics, images, custom fonts & CRP Super speed around the globe
  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. 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. 6. Fast loading time plays an important role in overall user experience! Performance = user experience!
  7. 7. 7 @peakaceag pa.ag Google loves site speed and keeps pushing for faster sites
  8. 8. 8 @peakaceag pa.ag Revisited: PageSpeed (load time) is a ranking factor Source: http://pa.ag/2iAmA4Y & http://pa.ag/2ERTPYY
  9. 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. 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. 11. However, details really depend on the individual setup #1 Absolutely get the basics right
  12. 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. 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. 14. By now everyone should be on HTTPS, right? #2 HTTP/2
  15. 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. 16. Because the server does all the work! Your devs don‘t need to do much
  17. 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. 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. 19. Highest quality, (more) efficient data compression & smaller files #3 Image optimisation
  20. 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. 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. 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. 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. 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. 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. 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. 27. Because latency does matter, especially for international sites! Let’s talk CDNs for a minute
  28. 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. 29 @peakaceag pa.ag Test your (CDN) latency from all over the world: Try it out: https://pa.ag/2HX6aje
  30. 30. Pretty, varied, colourful, and often very slow! #4 Custom web fonts
  31. 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. 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. 33. FOIT (flash of invisible text) or FOUT (flash of unstyled text) can cause annoying flickering Asynchronous?
  34. 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. 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. 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. 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. 38. Because the PageSpeed Insights score is not enough! #5 Better measurement
  39. 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. 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. 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. 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. 43 @peakaceag pa.ag Watching a video on YouTube? This is your hero element:
  44. 44. 44 @peakaceag pa.ag Chrome Dev Tools > Performance > Profiling (Frames)
  45. 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. 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. 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. 48 @peakaceag pa.ag Combine it with Google Data Studio Test it: http://pa.ag/2Ee550q
  49. 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. 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. 51 @peakaceag pa.ag Tracking FID in JavaScript using Google Analytics More: https://pa.ag/2IlRV7O
  52. 52. The code and resources required to render the initial view of a web page #6 Critical rendering path
  53. 53. 53 @peakaceag pa.ag Critical rendering path optimisation Initial view (critical) Below the fold (not critical)
  54. 54. Some brief, technical background:
  55. 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. 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. 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. 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. 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. 60. Let’s look at an implementation… Is it worth all the effort?
  61. 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. 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. 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. 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. 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. 66. … and feel free to disagree, but please think about it for a minute. #7 Let’s talk AMP
  67. 67. AMP certainly helps to push people to take the need for fast loading sites more seriously. Drives discussion/innovation
  68. 68. Suddenly, different teams/stakeholders (have to) care about performance and it becomes an “agenda topic”. Enables collaboration
  69. 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. 70. Extending CMS capabilities to manage AMP content is expensive, additional maintenance (IT, editorial, etc.) increases costs further. Maintenance & costs
  71. 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. 72. Seriously, just putting it on GitHub doesn’t make it less controlled! Not really open source
  73. 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. 74. … because we are talking web performance! Maybe all this shouldn’t matter…
  75. 75. Actually, AMP is not really *that* fast… Google is cheating with speed
  76. 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. 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. 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. 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. 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. 81. So, what should you do?
  82. 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. 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. 84. Anyone? #8 One last thing… guess.js?
  85. 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. 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

×