How we make Web Apps lightning fast at Microsoft
summary
Performance audit shows heavy JavaScript as the dominant cost: use Chrome/Edge coverage to measure unused code, apply webpack dynamic imports to split locale and rarely used modules, and leverage service workers with Workbox or OfflinePlugin to prefetch. A config.office.com case study removed 16 MB from the initial bundle and makes the page 4× faster to interactive (2× on slow networks). Microsoft sets concrete targets like 200 KB initial JS and CI checks to enforce them.
AI-written summary · about
chapters (9)
- 0:00Start
- 9:19CODE SPLITTING PROCESS OF SPLITTING PIECES OF YOUR CODE INTO ASYNC CHUNKS
- 9:42HOW DOES IT WORK?
- 10:07ANYTHING TEMPORAL
- 19:42ROOT CAUSE: WEBPACK!
- 20:28ROOT CAUSE: ENGINEERS?
- 22:00NEGATING NETWORK COST
- 23:04WHY SHOULD I CARE?
- 23:33PREVENT CROSS-TOOL PITFALLS
related talks
41mHow we make Web Apps lightning fast at Microsoft!
26mWeb Performance in modern JavaScript world
37mSecret Shortcuts of Loading Web Performance
24mSuperpowers of browser's Web API
46mWeb Performance in 2018
21mWhy are web applications slow, and what to do about it
01h 03mSpeed up your Web Application
21mEvolution of Web Performance