Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

NYC WebPerf Meetup Feb 2020 - Measuring the Adoption of Web Performance Techniques

943 Aufrufe

Veröffentlicht am

Performance optimization is a cyclical process. We are constantly learning new ways to optimize, while simultaneously adopting new technologies and techniques that negatively impact performance. The HTTP Archive provides a great historical record of the technical side of the web, with almost 10 years of history and an ever growing dataset of sites.

During this session Paul will provide a brief overview of the HTTP Archive and then dive into some insights into the adoption of common web performance techniques and some of their measurable impacts.

Veröffentlicht in: Internet
  • Als Erste(r) kommentieren

NYC WebPerf Meetup Feb 2020 - Measuring the Adoption of Web Performance Techniques

  1. 1. ©2019 AKAMAI Measuring the Adoption of Web Performance Techniques NYC WebPerf Meetup 12 Feb 2020 Paul Calvano Principal Web Performance Architect @paulcalvano
  2. 2. 2
  3. 3. 3
  4. 4. 4 ● Make Fewer HTTP Requests ● Use a Content Delivery Network ● Add an Expires Header ● Gzip Components ● Put Stylesheets at the Top ● Put Scripts at the Bottom ● Avoid CSS Expressions ● Make JavaScript and CSS External ● Reduce DNS Lookups ● Minify JavaScript ● Avoid Redirects ● Remove Duplicates Scripts ● Configure ETags ● Make Ajax Cacheable Release Date: December 2008
  5. 5. 5 ● Do Less ● Do it Faster ● Change the Order Optimizing for performance: https://twitter.com/TimVereecke
  6. 6. 6
  7. 7. 7 https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/#monthly-200901-202001
  8. 8. 8 https://developers.google.com/speed/pagespeed/insights/
  9. 9. 9
  10. 10. 10 https://discuss.httparchive.org/t/analyzing-lighthouse-scores-across-the-web/1600
  11. 11. 11
  12. 12. 12
  13. 13. 13 Google BigQuery 5.3 Million Websites!
  14. 14. 14
  15. 15. 15
  16. 16. 16
  17. 17. 17 > 150 Offscreen Images!
  18. 18. 18 Off Screen Images https://discuss.httparchive.org/t/chrome-image-lazy-loading-sites-already-using-it-on-week-1/1707
  19. 19. 19 Off Screen Images https://discuss.httparchive.org/t/chrome-image-lazy-loading-sites-already-using-it-on-week-1/1707
  20. 20. 20 https://web.dev/native-lazy-loading
  21. 21. 21 https://discuss.httparchive.org/t/chrome-image-lazy-loading-sites-already-using-it-on-week-1/1707 January 2020: <img loading=lazy> 18,070 sites! <img loading=eager> 320 sites <img loading=auto> 443 sites <iframe loading=lazy> 3,151 sites
  22. 22. 22 https://twitter.com/TimVereecke/status/1169880348651446272
  23. 23. 23 MORE THAN 80% OF SITES CAN BENEFIT FROM IMAGE OPTIMIZATION ! > 1MB Potential Savings: 949K websites! https://developers.google.com/web/tools/lighthouse/audits/optimize-images
  24. 24. 24 ©2018 AKAMAI Choosing the Right Image Format https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/image-optimization Use browser specific formats: webp, jpeg-xr, jpeg2000
  25. 25. 25 V65+ Edge v18+ 0.9% of Chrome Image Requests 45.3% of Chrome Image Requests
  26. 26. 26 Responsive Images served by 65% of sites. https://developers.google.com/web/tools/lighthouse/audits/oversized-images Image Source: https://en.wikaipedia.org/wiki/File:Responsive_design_-_Commons_Android_app.jpg
  27. 27. 27 ©2018 AKAMAI
  28. 28. 28 ©2018 AKAMAI Original: 954 Bytes Gzip: 372 bytes Savings: 61%
  29. 29. 29
  30. 30. 30 Higher Compression levels Are Expensive … But Have the Highest Compression Ratios
  31. 31. 31https://paulcalvano.com/index.php/2018/07/25/brotli-compression-how-much-will-it-reduce-your-content/
  32. 32. How well are we compressing text assets? Only 45% of HTML responses were compressed !!!
  33. 33. 33 Bundle all your assets! Don’t bundle Serve only what’s needed! Image Source: https://pixabay.com/photos/puppy-tug-o-war-lab-1647692/
  34. 34. 34 Critical CSS Start Render
  35. 35. 35
  36. 36. 36 41% of sites have more than 100KB Unused CSS Unused CSS and JavaScript incurs a processing cost
  37. 37. 37 https://httparchive.org/reports/state-of-javascript#bytesJs
  38. 38. 38 https://v8.dev/blog/cost-of-javascript-2019
  39. 39. 39 4 Critical Domains 3 Possible Single Points of Failure
  40. 40. 40
  41. 41. 41 https://speakerdeck.com/csswizardry/more-than-you-ever-wanted-to-know-about-resource-hints <link rel="dns-prefetch" href="..." /> <link rel="preconnect" href="..." /> <link rel="prefetch" href="..." /> <link rel="prerender" href="..." /> <link rel="preload" href="..." />
  42. 42. 42 3rd Party Protocol Overhead <link rel="dns-prefetch" href="..." /> <link rel="preconnect" href="..." />
  43. 43. 43 ● Performs DNS Lookup in advance of an HTTP request ● Implemented in HTTP Response Header: 522 websites ● Implemented in HTML Body: 1,605,919 websites <link rel="dns-prefetch" href="..." /> ● DNS + TCP + TLS in advance of an HTTP request ● Implemented in HTTP Response Header: 2,895,113 websites ● Implemented in HTML Body: 275,938 websites <link rel="preconnect" href="..." /> Recommended
  44. 44. ©2015 AKAMAI | FASTER FORWARDTM The fastest request is the one you don’t have to make.
  45. 45. 45 Where Does Resource Caching Happen? CACHE PARENT CACHE CHILD ORIGIN CDN BROWSER GATEWAY HTTP headers for browser cache ServiceWorker HTTP headers HTTP headers CDN Config [ UI / API ] HTTP headers Reverse Proxy Config [ UI / API ]
  46. 46. 46 https://hpbn.co/primer-on-latency-and-bandwidth/
  47. 47. 47 No CDN? Where is the Content Served From? 48% of requests were served without a content delivery network.
  48. 48. 48 https://developers.google.com/web/tools/lighthouse/audits/cache-policy
  49. 49. 49 Cacheabilty based on Cache-Control Header - HTTP Archive, Mobile, August 2019 https://discuss.httparchive.org/t/what-percentage-of-third-party-content-is-cacheable/1614 How Cacheable is Web Content?
  50. 50. 50 https://discuss.httparchive.org/t/analyzing-resource-age-by-content-type/1659
  51. 51. 51 https://almanac.httparchive.org/
  52. 52. 52 https://almanac.httparchive.org/
  53. 53. 53 https://almanac.httparchive.org/
  54. 54. 54 https://almanac.httparchive.org/
  55. 55. 55 https://almanac.httparchive.org/
  56. 56. 56 https://almanac.httparchive.org/
  57. 57. 57 https://forms.gle/Qyf3q5pKgdH1cBhq5 https://almanac.httparchive.org/
  58. 58. ©2018 AKAMAIbit.ly/ha-slack Chat github.com/HTTPArchive Contribute discuss.httparchive.org Collaborate HTTP Archive Guided Tour https://bit.ly/2JmDnSH
  59. 59. 59 Q&A @paulcalvano

×