The Map

A browser is a program that takes untrusted text from strangers, turns it into pixels and behaviour on your machine, and does so without letting the stranger touch anything else. Every design decision in it follows from those three clauses.

a browser is not one program. in chrome today it is:

  1 browser process     (UI, navigation, privilege)
  N renderer processes  (one per site, sandboxed)
  1 GPU process
  1 network process
  K utility processes   (audio, storage, printing, ...)

the thing you call "the browser" is the coordinator. the thing that runs your page is one of the N.

Early browsers were one process. One bad page took the whole window with it, and one compromised page could read every other page's memory. Chrome shipped in 2008 with a process per tab, and every major browser has converged on a version of the same split since.

Not quite, and the difference matters for security. The unit of isolation is the site, which is the registrable domain plus scheme: https://bank.example. Two tabs on the same site may share a renderer. One tab containing an iframe from a different site puts that iframe in a different renderer from the page around it.

a tab on bank.example with an embedded ads.example iframe:

  renderer A  runs bank.example's document
  renderer B  runs ads.example's iframe
  the browser process stitches them into one tab

the ad's JavaScript is in a different address space from your balance.
it cannot read bank.example's memory even with a renderer exploit.

A renderer process is where the course spends most of its time, so it is worth knowing its threads by name before anything else.

Here is the whole thing once, fast, so the rest of the course has a map to pin to. Each stage below is a part of its own.

Because the stylesheet is on the critical rendering path and the image is not. The path is the minimum set of work between the first byte and the first pixel, and it is defined by what blocks what.

the blocking rules, which are the whole story:

  HTML parsing     blocks on  a synchronous <script> (it might document.write)
  script execution  blocks on  all CSS above it (it might read a computed style)
  first render     blocks on  all CSS in <head> (unstyled flash is worse than waiting)
  nothing          blocks on  images, async scripts, fonts (mostly)

so: CSS blocks render, sync JS blocks parsing, and JS waits for CSS.
a sync script after a stylesheet pays for both.

There are two clocks in a browser, and conflating them causes most bad performance advice.

a realistic load budget on a mid-range Android over 4G:

  DNS + TCP + TLS       ~300 ms
  TTFB                   ~400 ms
  HTML + critical CSS   ~200 ms
  parse + style + layout ~150 ms
  JS parse + execute    ~900 ms  ← the usual villain
  images for LCP        ~500 ms

a frame budget, where it all has to fit:

  input handling    ~1 ms
  JS                ≤ 8 ms
  style + layout    ~3 ms
  paint + composite ~3 ms
  slack             ~1 ms

a 50 ms click handler is three dropped frames. the user calls that lag.

Three rendering engines matter: Blink (Chrome, Edge, Opera, Brave, Samsung Internet, every Android WebView), WebKit (Safari, and every browser on iOS until recently), and Gecko (Firefox). They implement the same specifications and the same pipeline shape, with real differences underneath.

This course is paired with the DevTools course and its companion app. The app is a small React application where every route triggers one specific pathology: a layout thrash, a long task, a render-blocking stylesheet, a memory leak, a hydration mismatch, a blocked request. The DevTools course walks each panel; this course points at the app whenever a mechanism is easier to see than to read.