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.

10 Web Performance Lessons For the 21st Century

346 views

Published on

When Web Performance Optimization was emerging as a new field of engineering we had a handful of rules to follow. Gzip here, minify there, do some caching. This was 15 years ago.

This year’s Smashing Magazine performance checklist has 62 items with hundreds of links for further research.

Have we learned so much or has the Web become so complicated?

In this talk I will try to make sense of today’s most pressing Web Performance issues with easily digestible lessons about metrics, budgets, JavaScript frameworks, functional programming, browsers and plain old HTML.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

10 Web Performance Lessons For the 21st Century

  1. 1. 10 Web Performance Lessons For the 21st Century* *Title loosely inspired by this bookkwasniew.com
  2. 2. Using the Web in 2008 •Go to website •Do things (post a comment, read news etc.)
  3. 3. Using the Web nowadays •Go to website •Do things (post a message, read news etc.)
  4. 4. Using the Web nowadays •Go to website •Not what I intended to do •… •Not what I intended to do •Do things (post a message, read news etc.)
  5. 5. http://requestmap.webperf.tools/
  6. 6. http://www.geek.com/games/the-average-web-page-is-now-larger-than-the-original-doom-1653097/ 2.3MB *Floppy disk, not a save icon
  7. 7. missed opportunity
  8. 8. 10 lessons
  9. 9. Mateusz Kwaśniewski (kwasniew.com) 2007 2019
  10. 10. 2013 2019 Mateusz Kwaśniewski (kwasniew.com)
  11. 11. 2013 20192004 Mateusz Kwaśniewski (kwasniew.com)
  12. 12. Lesson I
  13. 13. “Programmers at work maintaining a legacy web application"
  14. 14. My first big mistake • Applying random optimisation without identifying a bottleneck • There’s opportunity cost of doing useless optimisations
  15. 15. Theory of Constraints
  16. 16. Lesson 1: Measure first, optimise bottleneck second Practical Performance: https://www.youtube.com/watch?v=6m_E-mC0y3Y
  17. 17. One Metric That Matters?
  18. 18. 1st generation
  19. 19. 1st generation
  20. 20. 1st generation Lab/Synthetic Real User Monitoring (RUM)
  21. 21. Raiders of the fast start: https://www.youtube.com/watch?v=qts9gPYoANU
  22. 22. Just after DOMContentLoaded
  23. 23. 7 seconds before Load
  24. 24. 2nd generation Speed Index Custom Metrics
  25. 25. https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
  26. 26. https://blog.twitter.com/engineering/en_us/a/2012/improving-performance-on-twittercom.html
  27. 27. Custom Metric: Hero Image https://speedcurve.com/blog/user-timing-and-custom-metrics/
  28. 28. Custom Metric: Hero Image Image loaded early but render was blocked by the script
  29. 29. 3rd generation First Contentful Paint Time to Interactive First Meaningful Paint First CPU Idle
  30. 30. 3rd generation First Contentful Paint Time to Interactive First Meaningful Paint First CPU Idle
  31. 31. 3rd generation First Contentful Paint Time to Interactive First Meaningful Paint First CPU Idle
  32. 32. speed index
  33. 33. speed index
  34. 34. Show it to your CEO
  35. 35. Interactivity metric in RUM?
  36. 36. Web Performance: Leveraging the Metrics that Most Affect User Experience: https://www.youtube.com/watch?v=6Ljq-Jn-EgU&t=898s First (Contentful) Paint Custom Metric Lighthouse metrics This process we follow, this cycle we ride
  37. 37. The search is not over Last Painted Hero = max(largest heading, largest image)
  38. 38. Lesson 2: Measure what matters How I learned to stop worrying and love UX metrics: https://www.youtube.com/watch?v=lLR_nGA5t5g WEB PERFORMANCE METRICS
  39. 39. What does good look like?
  40. 40. 20% faster
  41. 41. https://treo.sh/demo/1?interval=1month
  42. 42. Performance Budget Be specific https://timkadlec.com/remembers/2019-03-07-performance-budgets-that-stick/
  43. 43. Continuous Web Performance Testing
  44. 44. Performance bankruptcy https://product.voxmedia.com/2015/5/6/8561867/declaring-performance-bankruptcy
  45. 45. https://blog.radware.com/applicationdelivery/applicationaccelerationoptimization/2013/06/web-performance-poverty-line/
  46. 46. https://www.youtube.com/watch?v=Lx1cYJAVnzA Time to Interactive < 5s for the first load
  47. 47. https://addyosmani.com/blog/performance-budgets/
  48. 48. 100ms 1000ms
  49. 49. Magic numbers https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Perceived_Performance 100ms 1000ms https://calendar.perfplanet.com/2018/magic-numbers/
  50. 50. Lesson 3: Get yourself performance budget
  51. 51. Web Performance Advocates and JS Frameworkers debating on Twitter
  52. 52. Web Performance Advocates and JS Frameworkers debating on Twitter Platform! React!
  53. 53. Web Performance Advocates and JS Frameworkers debating on Twitter #perfmatters #DX matters
  54. 54. Lesson 4
  55. 55. Disclaimer: JS startup time may not be an issue for your type of app
  56. 56. Make JavaScript Faster: https://www.youtube.com/watch?v=RwSlubTBnew
  57. 57. https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
  58. 58. Optimization: use lighter framework
  59. 59. Optimization: use lighter framework this looks small
  60. 60. Hyperapp •Standalone React+Redux •400 lines of code I can reason about •Elm architecture, very few concepts to learn - fits in my head •Matches my JS preferences - no this/new/classes •Loads fast by default
  61. 61. Hyperapp •Standalone React+Redux •400 lines of code I can reason about •Elm architecture, very few concepts to learn - fits in my head •Matches my JS preferences - no this/new/classes •Loads fast by default
  62. 62. Hyperapp •Standalone React+Redux •400 lines of code I can reason about •Elm architecture, very few concepts to learn - fits in my head •Matches my JS preferences - no this/new/classes •Loads fast by default
  63. 63. Hyperapp •Standalone React+Redux •400 lines of code I can reason about •Inspired by Elm architecture, very few concepts to learn - fits in my head •Matches my JS preferences - no this/new/classes •Loads fast by default
  64. 64. Hyperapp •Standalone React+Redux •400 lines of code I can reason about •Inspired by Elm architecture, very few concepts to learn - fits in my head •Matches my JS preferences - no this/new/classes •Loads fast by default ____ extends Component @Component
  65. 65. Hyperapp •Standalone React+Redux •400 lines of code I can reason about •Inspired by Elm architecture, very few concepts to learn - fits in my head •Matches my JS preferences - no this/new/classes •Loads fast by default
  66. 66. Hyperapp •Standalone React+Redux •400 lines of code I can reason about •Inspired by Elm architecture, very few concepts to learn - fits in my head •Matches my JS preferences - no this/new/classes •Loads fast by default
  67. 67. https://github.com/kwasniew/hyperapp-realworld-example-app
  68. 68. 27kb
  69. 69. 14kb
  70. 70. 13kb
  71. 71. 1kB
  72. 72. https://github.com/krausest/js-framework-benchmark
  73. 73. Lesson 4: Write JS. Not too much. Mostly _____.
  74. 74. Lesson 4: Write JS. Not too much. Mostly functions.
  75. 75. https://medium.com/dev-channel/a-netflix-web-performance-case-study-c0bcde26a9d9
  76. 76. I don’t know
  77. 77. I guess it was popular
  78. 78. Availability heuristic
  79. 79. Boring solution to my boring problem Oh Shiny Shiny
  80. 80. Choose boring technology?
  81. 81. Choose boring technology. https://mcfunley.com/choose-boring-technology
  82. 82. https://superuser.com/questions/927585/on-some-websites-why-doesnt-ctrl-click-work-but-right-click-open-in-new-t
  83. 83. Back button amnesia
  84. 84. Browsers help you with HTML optimisations for free
  85. 85. Progressive rendering out of the box
  86. 86. {"username": "@username_9","score": 499,"text": “Blah 123"} {"username": "@username_83","score": 498,"text": “Blah 345"}
  87. 87. https://github.com/jakearchibald/streaming-html/blob/master/xhr-ndjson.js
  88. 88. But HTML is bigger than JSON
  89. 89. nope. http://codeartisan.blogspot.com/2012/07/using-html-as-media-type-for-your-api.html
  90. 90. But my framework can do SSR
  91. 91. CSR (Client Side Render) First Paint - 1.7s Interactive - 2.7s
  92. 92. Server-Side Render (SSR) + CSR
  93. 93. Server-Side Render (SSR) + CSR First Paint - 1.5s Interactive - 4.0s First Paint - 1.7s Interactive - 2.7s
  94. 94. well-executed SPA
  95. 95. Lesson 5: Write code. Not too much. Mostly HTMLstream based partial async hydration How to Survive the Single Page App-ocalypse: https://www.youtube.com/watch?v=1SRO-1HBE6E
  96. 96. Lesson 6
  97. 97. CSS
  98. 98. JS
  99. 99. Compiled to JS languages
  100. 100. Statically typed FP langs
  101. 101. Elm
  102. 102. Elm = Types + Ramda + Immutable.js + React + Redux + …
  103. 103. https://elm-lang.org/blog/small-assets-without-the-headache
  104. 104. Hyperapp 28kb
  105. 105. Hyperapp 28kb32kb
  106. 106. 🌳
  107. 107. Why can’t we have it in JS and its supersets?
  108. 108. Array.prototype.smoosh = …
  109. 109. Optimisations taxonomy • load time • runtime
  110. 110. Ease and safety of optimisation https://elm-lang.org/blog/blazing-fast-html-round-two https://elm-lang.org/blog/blazing-fast-html
  111. 111. Pure functions + Immutable data structures
  112. 112. String -> Html
  113. 113. lazy String -> Html
  114. 114. Making stupid things impossible
  115. 115. lazy [Item] -> Html
  116. 116. What capabilities are enabled by my language constraints?
  117. 117. Lesson 6: You may need more than JS
  118. 118. The more you SPA the more you need to understand the browser https://developers.google.com/web/updates/2018/09/inside-browser-part1
  119. 119. Technique: Pushing random optimisation commit with your fingers crossed
  120. 120. Flame Chart
  121. 121. render
  122. 122. Comments Comment
  123. 123. Hypothesis
  124. 124. View optimisation strategies
  125. 125. Windowing/ Virtualized long list
  126. 126. Align work (keyed lists)
  127. 127. <ul> <li key="0">Red</li> <li key="1">Green</li> </ul> <ul> <li key="2">Refactor</li> <li key="0">Red</li> <li key="1">Green</li> </ul>
  128. 128. Skip work (avoid reconciliation) lazy shouldComponentUpdate/PureComponent memoize
  129. 129. Lesson 7: Observe the not so secret life of your browser Browser Rendering Optimization: https://eu.udacity.com/course/browser-rendering-optimization--ud860 BROWSER
  130. 130. What I need my website to do? 1. Download and render most important elements of the page
  131. 131. What I need my website to do? 1. Download and render most important elements of the page “You don't need all that other crap. Have courage in your minimalism.” http://idlewords.com/talks/website_obesity.htm
  132. 132. What I need my presentation to do? 1. Cover the most important elements of the talk
  133. 133. GitHub uses no web fonts
  134. 134. Parallax lag
  135. 135. Lesson 8: Have courage in your minimalism
  136. 136. Go make the Web faster
  137. 137. DEV OPS
  138. 138. DEV OPSDesign Marketing
  139. 139. https://kwasniew.com/training/people-and-interactions/
  140. 140. What should we teach children today to prepare them for the world of tomorrow?
  141. 141. 1. Measure first, optimise bottleneck second 2. Measure what matters 3. Get yourself performance budget 4. Write JS. Not too much. 5. Write code. Not too much. Mostly HTML. 6. Embrace static FP. You may need more than JS. 7. Observe not so secret live of your browser 8. Bad system will beat good people every single time 9. Have courage in your minimalism 10.Sometimes 9 is enough
  142. 142. 1. Measure first, optimise bottleneck second 2. Measure what matters 3. Get yourself performance budget 4. Write JS. Not too much. Mostly functions. 5. Write code. Not too much. Mostly HTML. 6. Embrace static FP. You may need more than JS. 7. Observe not so secret live of your browser 8. Bad system will beat good people every single time 9. Have courage in your minimalism 10.Sometimes 9 is enough
  143. 143. 1. Measure first, optimise bottleneck second 2. Measure what matters 3. Get yourself performance budget 4. Write JS. Not too much. Mostly functions. 5. Write code. Not too much. Mostly HTML. 6. Embrace static FP. You may need more than JS. 7. Observe not so secret life of your browser 8. Bad system will beat good people every single time 9. Have courage in your minimalism 10.Sometimes 9 is enough
  144. 144. 1. Measure first, optimise bottleneck second 2. Measure what matters 3. Get yourself performance budget 4. Write JS. Not too much. Mostly functions. 5. Write code. Not too much. Mostly HTML. 6. Embrace static FP. You may need more than JS. 7. Observe not so secret life of your browser 8. Make or join faster organisation 9. Have courage in your minimalism 10.Sometimes 9 is enough
  145. 145. 1. Measure first, optimise bottleneck second 2. Measure what matters 3. Get yourself performance budget 4. Write JS. Not too much. Mostly functions. 5. Write code. Not too much. Mostly HTML. 6. Embrace static FP. You may need more than JS. 7. Observe not so secret life of your browser 8. Make or join faster organisation 9. Have courage in your minimalism 10.Sometimes 9 is enough
  146. 146. 1. Measure first, optimise bottleneck second 2. Measure what matters 3. Get yourself performance budget 4. Write JS. Not too much. Mostly functions. 5. Write code. Not too much. Mostly HTML. 6. Embrace static FP. You may need more than JS. 7. Observe not so secret life of your browser 8. Make or join faster organisation 9. Have courage in your minimalism 10. Sometimes 9 is enough
  147. 147. Delivered with ❤ by @kwasniew Thank you

×