Performance for the long haul
summary
JavaScript dominates real-world slowdowns: pause-and-compile plus runtime cost means a 2.36 MB gzipped bundle can expand to ~11.5 MB uncompressed, multiplying parse time 3–5x. Use Chrome DevTools Performance traces, Webpack Bundle Analyzer or source-map-explorer, and BundlePhobia to find fat deps; blocking doubleclick in DevTools and using local overrides proves changes before deploy. Preloading fonts saves ~3s FCP in one experiment, and service worker caches bytecode removes repeated pause/compile; track time to interactive and total blocking time and enforce budgets.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:05Performance as an additional step
- 1:53Understanding performance issues
- 2:41JavaScript
- 7:02Runtime
- 8:08Time to Interactive
- 10:38Reducing JavaScript
- 12:59Tree Shaking
- 14:41Size Requests
- 16:28Performance Budgets
- 17:18Set budgets based on context
- 18:43Implement a performance system
- 18:57Performance metrics
- 21:34Mobile performance
- 24:33Chrome User Experience Report
- 26:20Test within the spectrum
- 28:15Theory and testing
- 32:40Performance on mobile
- 33:56Conclusion
related talks
26mWeb Performance in modern JavaScript world
51mWhen JavaScript Bytes
31mThe Future of Front-End Performance
21mMonsters of Web Performance
28mDecoding JavaScript: Loading Performance —
52m10KB or Bust: The Delicate Power of Webpack and Babel
37mSecret Shortcuts of Loading Web Performance
23mDecoding Javascript: Loading Performance