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.

AMP - SMX München 2018

5,800 views

Published on

My slides from SMX Munich 2018 covering Accelerated Mobile Pages (AMP) and some thoughts around it.

Published in: Technology

AMP - SMX München 2018

  1. 1. Bastian Grimm, Peak Ace AG | @basgr Why web performance optimisation should be more than AMP! AMP ≠ Silver Bullet
  2. 2. … and feel free to disagree, but please think about it for a minute. First things first…
  3. 3. AMP certainly helps to push people to take the need for fast loading sites more seriously. #1 Drives discussion/innovation
  4. 4. Suddenly, different teams/stakeholders (have to) care about performance and it becomes an “agenda topic”. #2 Enables collaboration
  5. 5. Converting existing sites to AMP almost never works, you need to rebuild the entire HTML & CSS from scratch (which takes time & resources). #3 Additional effort
  6. 6. Extending CMS capabilities to manage AMP content is expensive, additional maintenance (IT, editorial, etc.) increases costs further. #4 Maintenance & costs
  7. 7. Currently, the lack of proper branding possibilities is killing brand recognition as well as decreasing customer loyalty. #5 Lack of branding
  8. 8. 8 @peakaceag pa.ag Can you guess which newspaper is which? AMP versions of four major German newspapers, without their logo they essentially all look pretty much the same:
  9. 9. 9 @peakaceag pa.ag Can you guess which newspaper is which? Due to massive limitations, their “look and feel” is totally different from regular branding; Complex monetisation & marketing automation is hampered due to JS restrictions.
  10. 10. 10 @peakaceag pa.ag Also, the average user doesn’t understand what happens 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
  11. 11. Seriously, just putting it on GitHub doesn’t make it less controlled! #6 Not really open source
  12. 12. They “use” you to make it easy for them (same structure) and even hosted on Google. Also, consider changed crawl behaviour (another URL). #7 Crawling
  13. 13. … because we are talking web performance! Maybe all this shouldn’t matter…
  14. 14. Actually, AMP is not really *that* fast… #8 Google is cheating with speed
  15. 15. 15 @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 load time for a user is even greater.
  16. 16. 16 @peakaceag pa.ag AMP vs. regular website: major German newspapers ZEIT Online as well as stern mostly outperform AMP with their regular sites (well done!) Source: Peak Ace AG research (March 2018) / @patrickstox found the same: http://pa.ag/2Iz6em7 Publisher Type Start Render (in s) Load Time (in s) First Interactive (in s) SpeedIndex ZEIT Online AMP 1.000 1.168 2.272 1151 ZEIT Online Responsive 0.400 1.985 2.177 1024 stern AMP 0.900 0.907 3.363 1058 stern m-Subdomain 0.300 2.243 2.087 909 Süddeutsche AMP 1.100 1.654 2.804 1817 Süddeutsche Responsive 2.200 4.935 4.988 2768 Spiegel Online AMP 1.100 1.138 2.089 1112 Spiegel Online m-Subdomain 1.500 3.921 5.101 2519
  17. 17. 17 @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
  18. 18. Only if you go full PWAMP (Progressive Web App + AMP) secondary - and following – clicks/interactions will be fast as well. #9 Only the 1st request is fast
  19. 19. 19 @peakaceag pa.ag Go full AMP? Sure, what could possibly go wrong!? Just visit bmw.com - they are full AMP but ignored important basics! ▪ Update your custom fonts (to WOFF2) (e.g. for “BMWTypeWebBoldAll” from 101 KB down to 72 KB) Proper compression (e.g. logo.png: 8.0 KB instead of 23.0 KB, ditto your favicon.ico) Better caching strategies (e.g. the logo or favicon.ico surely won’t change daily) Page load is not fast enough for 3G (First Interactive >10 seconds!)
  20. 20. So, what should you do?
  21. 21. 21 @peakaceag pa.ag Please take care of your website first: (no matter if 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.”
  22. 22. Because the PageSpeed Insights score is not enough! #1 Better measurement
  23. 23. 23 @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)
  24. 24. 24 @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.
  25. 25. 25 @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.
  26. 26. 26 @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!
  27. 27. 27 @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)
  28. 28. 28 @peakaceag pa.ag The cool kids’ way of doing this (using GTM) #1 #3 #2 #4
  29. 29. 29 @peakaceag pa.ag This is how it looks like in Google Analytics/Data Studio GA: Behaviour > events > pages: performance metrics [first-contentful-paint] Source: Google Analytics
  30. 30. The code and resources required to render the initial view of a web page #2 Critical rendering path
  31. 31. 31 @peakaceag pa.ag Critical rendering path optimisation Initial view (critical) Below the fold (not critical)
  32. 32. Some (technical) background:
  33. 33. 33 @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;
  34. 34. 34 @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
  35. 35. 35 @peakaceag pa.ag Google doesn’t make a single GET request for its CSS! Because requesting external CSS is more expensive than in-lining everything.
  36. 36. 36 @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!
  37. 37. 37 @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
  38. 38. Highest quality, (more) efficient data compression & smaller files. #3 New image formats
  39. 39. 39 @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
  40. 40. 40 @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
  41. 41. 41 @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) Check out cloudinary image optimisation: http://pa.ag/2IDOkP9 VS.
  42. 42. 42 @peakaceag pa.ag There is more: FLIF, BPG, JPEG-XR, etc. If you’re “image-heavy”, go play with it! Further reading: http://pa.ag/1S5OQmX
  43. 43. Pretty, varied, colourful, and slow! #3 Custom web fonts
  44. 44. 44 @peakaceag pa.ag >70% of all websites use at least one non-standard font! Result: 114 kB additional data and on average 2.9 HTTP requests. Source: http://pa.ag/1BRUnbe Font transfer size & font requests Sites with custom fonts Font transfer size (kB) Font requests
  45. 45. 45 @peakaceag pa.ag Classic scenario: using external CSS Easy to use with one big disadvantage: CSS is render-blocking!
  46. 46. 46 @peakaceag pa.ag Asynchronous? Also not very successful and problematic FOUT (flash of unstyled text) = super annoying flickering Fighting the FOUT: http://pa.ag/1BRWMmu
  47. 47. 47 @peakaceag pa.ag How I usually tackle this Credits: http://pa.ag/1GakitY & http://pa.ag/1NDXCVi
  48. 48. 48 @peakaceag pa.ag New stuff to play around with: “font-display” strategies More: http://pa.ag/2eUwVob
  49. 49. … more?
  50. 50. 50 pa.ag@peakaceag #1 Client-side/front-end optimisation tasks ▪ 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. All slides on SlideShare: http://pa.ag/iss17speed Use my checklist on SlideShare to double check:
  51. 51. 51 pa.ag@peakaceag #2 Server-side/back-end optimisation tasks ▪ 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) All slides on SlideShare: http://pa.ag/iss17speed Use my checklist on SlideShare to double check:
  52. 52. 52 pa.ag@peakaceag We’re hiring! 25+ Performance Marketing jobs in Berlin! Come and say “hello” or apply via jobs.pa.ag. Looking forward to speaking to you! Always looking for talent! Check out jobs.pa.ag
  53. 53. 53 @peakaceag pa.ag http://pa.ag/smx18amp 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:

×