We are all good with browsers made by others
summary
Explains how modern browsers use a multi‑process architecture (browser, render, network, GPU) and why rendering a single frame must fit a 10 millisecond budget to reach 60fps, or users see jank; shows the compositor thread handling scrolling and producing compositor frames via IPC to the GPU; demonstrates that using transform and opacity can skip layout/paint by moving work to the GPU, and recommends web workers and requestAnimationFrame to move work off the main thread.
AI-written summary · about
chapters (31)
- 0:00intro
- 0:22preamble
- 0:47how many of us have never said a $%^&*?
- 1:31what is a browser
- 3:29why should i care?
- 4:20how is it made
- 4:32architecture
- 5:16processes & threads
- 6:42browser processes
- 9:46multi-process architectures: pros & cons
- 11:38how does it work
- 13:05rendering
- 13:47scared, huh?
- 14:01render a page
- 14:28parsing
- 16:50style calculation
- 18:09layuot
- 20:34paint
- 21:35compositing
- 23:39compositing - events
- 25:43critical rendering path (crp)
- 26:38jank - your worst enemy
- 27:02critical rendering path (crp)
- 27:49main thread
- 28:05a quick distinction
- 29:17recap
- 29:47i motori
- 30:06maybe it's not what we thought
- 30:20any ideas?
- 32:04links
- 32:30thank you!
related talks
44mWe Are All Good with Browsers Made by Others
44mUnder the Browser Hood: How the Event Loop and Compositing Work
28mHow to Achieve Performing Rendering in the Browser
31mThe parallel future of the browser (Closing Keynote)
30mLet the main thread breathe!
58mUntangling Browser Threads
38mThe future of the browser
19mLet the Main Thread Breathe!