O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Raiders of the Fast Start: Frontend Performance Archaeology PerfmattersConf 2018

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 107 Anúncio

Raiders of the Fast Start: Frontend Performance Archaeology PerfmattersConf 2018

Baixar para ler offline

There are a lot of books, articles, and online tutorials out there with fantastic advice on how to make your websites performant. It all seems easy in theory, but applying best practices to real-world code is anything but straightforward. Diagnosing and fixing frontend performance issues on a large legacy codebase is like being an archaeologist excavating the remains of a lost civilization. You don’t know what you will find until you start digging!

Pick up your trowels and come along with Etsy’s Frontend Systems team as we become archaeologists digging into frontend performance on our large, legacy mobile codebase. I’ll share real-life lessons you can use to guide your own excavations into legacy code:

What tools and metrics we used to diagnose issues and track progress.
How we went beyond server-driven best practices to focus on the client.
Which fixes successfully increased conversion, and which didn’t.
Our work, like all good archaeology, went beyond artifacts and unearthed new insights into our culture. We at Etsy pride ourselves on our culture of performance, but, like all cultures, it needs to adapt and reinvent itself to account for changes to the landscape. Based on what we’ve learned, we are making the case for a new, organization-wide, frontend-focused performance culture that will solve the problems we face today.
Presentation from https://perfmattersconf.com/

There are a lot of books, articles, and online tutorials out there with fantastic advice on how to make your websites performant. It all seems easy in theory, but applying best practices to real-world code is anything but straightforward. Diagnosing and fixing frontend performance issues on a large legacy codebase is like being an archaeologist excavating the remains of a lost civilization. You don’t know what you will find until you start digging!

Pick up your trowels and come along with Etsy’s Frontend Systems team as we become archaeologists digging into frontend performance on our large, legacy mobile codebase. I’ll share real-life lessons you can use to guide your own excavations into legacy code:

What tools and metrics we used to diagnose issues and track progress.
How we went beyond server-driven best practices to focus on the client.
Which fixes successfully increased conversion, and which didn’t.
Our work, like all good archaeology, went beyond artifacts and unearthed new insights into our culture. We at Etsy pride ourselves on our culture of performance, but, like all cultures, it needs to adapt and reinvent itself to account for changes to the landscape. Based on what we’ve learned, we are making the case for a new, organization-wide, frontend-focused performance culture that will solve the problems we face today.
Presentation from https://perfmattersconf.com/

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Semelhante a Raiders of the Fast Start: Frontend Performance Archaeology PerfmattersConf 2018 (20)

Anúncio

Mais recentes (20)

Raiders of the Fast Start: Frontend Performance Archaeology PerfmattersConf 2018

  1. 1. STARRING KATIE SYLOR-MILLERAND ETSY FRONTEND SYSTEMS
  2. 2. Katie Sylor-Miller Staff Software Engineer Etsy Frontend Systems @ksylor && @ohshitgit
  3. 3. WE DO NOT FOLLOW MAPS TO BURIED TREASURE, AND “X” NEVER, EVER MARKS THE SPOT
  4. 4. Archaeology is the study of human history and culture through physical remains
  5. 5. Performance archaeology uncovers insights into your development culture
  6. 6. Survey Excavate Hypothesis Interpret Archaeology 101
  7. 7. YOU CALL THIS ARCHAEOLOGY?
  8. 8. Hypothesis Image by HeritageDaily on Wikipedia
  9. 9. The Mobile Listing Page
  10. 10. Mobile Visits 67% 52% Mobile GMS
  11. 11. RUM Dom Content Loaded Times 1000 2000 3000 4000 50000 DOMContentLoaded ms Numberofvisits
  12. 12. Dom Content Loaded Times 15% 37% 24% 13% 6% 1000 2000 3000 4000 50000 DOMContentLoaded ms Numberofvisits
  13. 13. Conversion Vs. Dom Content Loaded 1000 2000 3000 4000 5000 DOMContentLoaded ms Conversionrate
  14. 14. 1000 2000 3000 4000 5000 Conversion Vs. Population 15% 37% 24% 13% 6% DOMContentLoaded ms Conversionrate
  15. 15. Improving the performance of the mobile listing page will increase conversion Hypothesis
  16. 16. FORTUNE AND GLORY, KID
  17. 17. Survey Hypothesis
  18. 18. Performance Best Practices Great server response times Minify and gzip static JS and CSS assets Resize and compress images Responsive images Use proper headers to take advantage of browser caching Use dns-prefetch resource hints Use HTTP/2 when available (not all of our CDNs support) In-house RUM monitoring and alerting 3rd party synthetic monitoring service
  19. 19. NOW WHAT?
  20. 20. Critical Rendering Path How quickly a user: • receives confirmation that the page has started loading? • sees the most important information on the page? • can interact with the page?
  21. 21. NOW WHAT?
  22. 22. Ground Penetrating Radar Image by Tapatio via Wikipedia
  23. 23. WebPageTest.org Ground Penetrating Radar
  24. 24. The Mobile Listing Page
  25. 25. WebPageTest Results (Before) iPhone 6 iOS9 - 3GSlow 
 (this is much worse than our typical user experience) METRIC BEFORE AFTER CHANGE TTFB 1.8s Start Render 8.5s DOM Content Loaded 12.1s Speed Index 13,193 Time to First Interactive >19s CSS size 98KB/0.62MB JS size 386KB/1.46MB Images 37 Cost $$$$-
  26. 26. PRETEND THIS DIDN’T HAPPEN
  27. 27. Waterfall (before)
  28. 28. Waterfall (before) Five CSS files
 Block CSSOM construction
 and Start Render
  29. 29. Waterfall (before) Related listings images
 (below the fold)
  30. 30. Waterfall (before) Two different sizes of shop avatar image
 (1 above, 1 below the fold)
  31. 31. Waterfall (before) Three JS files
 Global base (XL), page-specific (L), category nav(S)
 Block DOM Content Loaded
  32. 32. Waterfall (before) Similar listing images
 (waaaayyyyy below the fold)
  33. 33. Five CSS bg-images
 One icon font
  34. 34. Main listing image is 36th!!!
 Followed by more carousel images
  35. 35. Reviews images (from async content) Logging Logging Logging
  36. 36. $(‘document’).ready()
  37. 37. Areas For Improvement • Lazyload images: 
 Defer loading of “below the fold” images • Reduce CSS File Size: 
 Combine CSS files and remove unused rules • Switch to SVGs: 
 Replace CSS bg-images and icon fonts with SVGs • Reduce JS File Size: 
 Remove unused Javascript
  38. 38. Survey Excavate
  39. 39. Test Pits
  40. 40. Lazyload Images Test Pit #1
  41. 41. 37 Images 814KB
  42. 42. lazy loading synthetic tests DOMContentLoadedms 1750 3500 5250 7000 Network Speed Wifi 4G 3G Before After Lazy Loading
  43. 43. Reduce CSS File Size Test Pit #2
  44. 44. 5 CSS files 98KB/0.62MB
  45. 45. “Load only what you need” - Yoav Weiss, yesterday
  46. 46. EASIER SAID THAN DONE
  47. 47. Automation to the Rescue? • Selenium script opens the page(s) in a browser • Run uncss (https://github.com/uncss/uncss) • Output a new file with only the CSS in use … But, we didn’t capture *all* states and had to keep adding more every time we found a bug.
  48. 48. CSS Reduction Synthetic Tests DOMContentLoaded(ms) 1750 3500 5250 7000 Network Speed Wifi 4G 3G Before After CSS Reduction After Lazy Loading
  49. 49. Lazyloading + CSS Reduction Experiment Results User-facing experiment #1
  50. 50. RUM Results - Lazyloading + CSS Reduction METRIC BEFORE AFTER CHANGE TTFB 1.16s 1.18s 1.2% DOM Content Loaded 3.3s 3.1s 6% ➡ Page Load 6.0s 5.2s 13.2% ➡
  51. 51. RUM Results - Lazyloading + CSS Reduction
  52. 52. Conversion
  53. 53. X MARKS THE SPOT
  54. 54. Switch to SVGs Test Pit #3
  55. 55. 5 bg-images 1 icon font
  56. 56. SVG Switch Synthetic Tests Logged Out DOMContentLoadedms 1500 3000 4500 6000 Wifi 4G 3G Before After SVGs Logged In 1500 3000 4500 6000 Wifi 4G 3G Before After SVGs
  57. 57. SVG Switch Results User-facing Experiment #2
  58. 58. RUM Results - SVG Switch METRIC BEFORE AFTER CHANGE TTFB 1.17 1.17s ⬌ DOM Content Loaded 3.0s 3.0s ⬌ Page Load 5.6s 5.5s 1%➡
  59. 59. RUM Results - SVG Switch
  60. 60. Conversion ⬌
  61. 61. WebPageTest.org again How are we doing?
  62. 62. METRIC BEFORE AFTER CHANGE TTFB 1.8s 2.0s 11% Start Render 8.5s 4.8s 44% ➡ DOM Content Loaded 12.1s 12.6s ?? 4% Speed Index 13,193 13,071 ⬌ Time to First Interactive >19s >17s 10%➡ CSS size 98KB/0.62MB 38KB/0.24MB 60%➡ JS size 386KB/1.46MB 375KB/1.59MB 3% Images 37 25 32%➡ Cost $$$$- $$$-- $➡ WebPageTest Results (After) iPhone 6 iOS9 - 3GSlow
  63. 63. Waterfall - After Down to 2 CSS Files!
  64. 64. Waterfall - After Listing carousel images!
  65. 65. Waterfall - After One shop avatar image!
  66. 66. Waterfall - After Still two large JS files
  67. 67. Waterfall - After CSS Background image
 added back in by experiment
  68. 68. Logging Reviews images (added by new experiment) Async content
  69. 69. Stratigraphy
  70. 70. A Brief History of JS at Etsy 2010 - jQuery w/Homegrown system to concatenate and serve JS files 2011 - Dependencies get inlined using rails-style
 //=require ‘path/to/dependencies’
 window.Etsy.module; 2012 - RequireJS - AMD dependencies
 define([‘path/to/dependencies’],
 function(dep) { }); 2017 - still a mix of everything :(
  71. 71. HA HAAAAAHA
  72. 72. Reduce JS File Size Test Pit #4
  73. 73. “Load only what you need” - Yoav Weiss, yesterday
  74. 74. 56KB/264KB 121 dependencies 142KB/712KB 124 dependencies PAGE-SPECIFIC FILE GLOBAL BASE FILE
  75. 75. NO TYPES!
  76. 76. Manual JS Reduction Test Pit #4a
  77. 77. How to be a Javascript Detective JS dependency $(‘selector’)
 Smarty/Mustache
 templates PHP View PHP Controller Experiment flags
  78. 78. 56KB/264KB 42KB/177KB 25% ➡ 142KB/712KB 94KB/469KB 33% ➡ PAGE-SPECIFIC FILE GLOBAL BASE FILE
  79. 79. WebPageTest Results (After) Manual JS removal METRIC BEFORE AFTER CHANGE TTFB 2.0s 1.9s 5%➡ Start Render 4.8s 4.87s 1% DOM Content Loaded 12.6s 9.8s 22%➡ Speed Index 13,071 10,903 16%➡ Time to First Interactive >17s >15s 12%➡ CSS size 38KB/0.24MB 38KB/0.24MB ⬌ JS size 375KB/1.59MB 299KB/1.15MB 20%➡ Images 25 23 8%➡ Cost $$$-- $$$-- ⬌ iPhone 6 iOS9 - 3GSlow
  80. 80. Manual JS Reduction Results User-facing Experiment #3
  81. 81. RUM Results - Manual JS Reduction METRIC BEFORE AFTER CHANGE TTFB 1.2s 1.2s ⬌ DOM Content Loaded 2.9s 2.8s 2.9%➡ Page Load 5.6s 5.5s 1.6%➡
  82. 82. RUM Results - Manual JS Reduction
  83. 83. Conversion ➡
  84. 84. Javascript Instrumentation Test Pit #4b
  85. 85. Code Coverage?
  86. 86. window.Etsy = 
 window.Etsy || {};
 window.Etsy.Vimes.register
 (“vb383”);
 
 function vb383(id,fn) {
 return function() {
 window.Etsy.Vimes.start('vb383' , id);
 return fn.apply(this, arguments);
 };
 }
 return vb383(1, function(args) { 
 return stuff;
 } Re-write JS to log
 function calls Capture real user
 actions Send logs onLoad
 and onUnLoad Map # of calls back
 to source files Introducing Vimes
  87. 87. PAGE-SPECIFIC FILE 56KB/264KB 40KB/173KB 28% ➡ 142KB/712KB 89KB/448KB 37% ➡ GLOBAL BASE FILE
  88. 88. Instrumented JS Reduction Results Fourth Experiment
  89. 89. RUM Results - Instrumented JS METRIC BEFORE AFTER CHANGE TTFB 1.2s 1.2s ⬌ DOM Content Loaded 3.0s 2.9s 2.7%➡ Page Load 5.2s 5.1s 1.2%➡
  90. 90. RUM Results - Instrumented JS
  91. 91. Conversion
  92. 92. Excavate Interpret
  93. 93. Performance directly affects conversion
  94. 94. Frontend performance is just as important as backend, if not more.
  95. 95. PUT IT IN THE BROWSER AND FORGET IT
  96. 96. Our experiences are not our users experiences (especially on mobile)
  97. 97. Small-scale tweaks don’t always pan out
  98. 98. Your front-end architecture needs to match your development culture
  99. 99. Static top-level CSS or JS dependency managed at the page level Dynamic FE dependency management at the component level WHAT WE HAVE WHAT WE NEED
  100. 100. Architect for deletion
  101. 101. THANK YOU

×