Browser Engines & PWAs — Service Workers, Rendering & Process Model
Interview map of browser architecture and the PWA platform: process model, rendering, Service Workers, and when a PWA beats a native shell.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
Question ladder
L1
What makes a site installable?
Answer
HTTPS, a manifest with name, icons, start_url, and display, plus a controlling Service Worker. Chromium also applies an engagement heuristic.
L2
What is the order of Service Worker install, activate, and claim?
Answer
Install precaches. If an old worker still controls clients, the new one waits. Activate deletes old caches. clients.claim takes open pages without waiting for a navigation.
L3
Cache-first or network-first for HTML versus hashed assets?
Answer
Hashed JS and CSS are cache-first. HTML navigations are network-first, with the cache as the offline fallback. An old index.html can pin a deleted asset forever.
L4
What is layout thrashing, and how does the compositor help?
Answer
Interleaving geometry reads and style writes forces layout on every iteration. Transform and opacity often stay on the compositor and skip layout and paint.
L5
Why site isolation, and which process owns cookies versus the DOM?
Answer
Site isolation puts cross-site documents in different renderer processes so a compromised renderer cannot read another site's memory. The network service coordinates cookies. The renderer owns the DOM.
L6
Ignition versus TurboFan, at systems level?
Answer
Ignition interprets bytecode so cold code starts quickly. TurboFan compiles hot functions with speculative type feedback and deoptimizes back to Ignition when an assumption fails.
L7
Design offline-first UX and a safe update for a dashboard PWA.
Answer
Cache-first app shell, network-first or stale-while-revalidate for lists, versioned caches, an update toast on activate, background sync for drafts, and push for alerts. Never cache Authorization. Degrade on iOS.
Failure modes
Stale worker forever
The new sw.js byte change never wins because the old worker still controls open clients and nothing calls skipWaiting or prompts a reload.
skipWaiting without UX
The new worker activates under old page JS, so fetch rules and the running bundle disagree.
Caching POST or auth responses
A shared cache returns one user's personalized JSON or a non-idempotent response to someone else.
Forced synchronous layout
A loop reads offsetHeight and writes style, so layout runs once per element.
Service Worker treated as a second page thread
The worker has its own lifetime. It can be killed while idle and does not share the page's DOM.
Ignoring iOS limits
Install, push, and background sync are not the same product on every browser. Say you would check the current Safari notes.
Misconceptions
A PWA is offline forever.
You design freshness. Cache-first on unversioned HTML is a bug, not a feature.
The Service Worker runs on the page.
It is a separate worker with its own event loop and lifetime.
Blink is Chromium.
Blink is the rendering engine inside Chromium. Chrome adds branding and services.
V8 is the browser.
V8 is the JS engine. The browser process, renderer, GPU, and network service are the rest of the platform.
Interviewer traps
Retelling the JS event loop, closures, or React rendering when the question was the browser platform.
Point at the event-loop lesson for task ordering. Stay on processes, the frame pipeline, and the Service Worker.
Calling every cache cache-first.
Name the resource class. Hashed assets, HTML, and personalized API responses are different strategies.
Design scenario
Same prompt for every reader.
Requirements
App shell is cache-first. List APIs are network-first or stale-while-revalidate. Asset caches are versioned. Activate shows an update toast. Draft forms can background-sync. Incident alerts can push.
Traffic / scale
A few hundred operators, each holding a dashboard tab open across a deploy.
Latency
The shell paints from cache in under a second. List data may be a few seconds stale.
Consistency
Never serve one operator's authenticated JSON to another. HTML must not pin deleted hashed assets.
Availability
The shell and last lists still render when the network drops. Mutations queue until connectivity returns.
Failure assumptions
- An old Service Worker can keep controlling open tabs for days.
- iOS install, push, and background sync may lag Chromium.
- A precache 404 fails the whole install.
Constraints
- HTTPS only.
- Never cache Authorization headers or personalized responses in a shared cache.
- Degrade gracefully where iOS PWA support is partial.
Prompt
Design an installable ops dashboard with an offline app shell, fresh-enough lists, and a safe update.
API
Which requests are network-only, and how does the page learn that a new worker is waiting?
Data
Which cache names exist, and what does activate delete?
Architecture
Where do the browser process, the renderer, and the Service Worker sit for this origin?
The product is already a web app
Prefer
PWA on the browser platform
One origin, one deploy, linkable install. You design offline and updates yourself.
- HTTPS, a manifest, and a Service Worker are the install surface.
- Cache Storage is per resource class, not a slogan.
- The origin sandbox and site isolation stay a feature.
Alternative
A native or desktop shell
Capacitor, Electron, or Swift/Kotlin when the web platform cannot reach the OS.
- Store review and a new binary replace a deploy of the origin.
- Plugins and Node bridges buy APIs and add an attack surface.
- Offline is still your design, plus whatever the OS already gives you.
Read the cluster in this order
Each box is a separate lesson. The phone cards are the same path as the diagram.
- 1
Service Worker lifetime
Register, install, wait, activate, fetch, and clients. - 2
Strategy per resource
Cache-first, network-first, stale-while-revalidate, or network-only. - 3
Install and offline UX
Manifest, app shell, push, and background sync, with iOS called out. - 4
Bytes to pixels
DOM, CSSOM, layout, paint, composite, and the critical rendering path. - 5
Which process
Browser, renderer, GPU, network, site isolation, Blink, and V8 tiers.
Overview
Interviewers use this cluster to see whether you can separate the language from the platform. The event loop says when a script, a promise, and a paint opportunity run. This page says which process owns the DOM, which worker intercepts fetch, and how bytes become pixels.
A Progressive Web App is not a framework. It is a secure origin plus a manifest (install identity) plus a Service Worker (programmable cache and network) plus an update UX you designed on purpose.
Ask this out loud: if users report that the app never updates after deploy, walk the Service Worker lifecycle and Cache Storage versioning end to end. That walk is Service Workers and cache strategies.
When a PWA beats a native shell
| Dimension | PWA (browser platform) | Capacitor / Cordova shell | Electron / Tauri desktop | Native (Swift/Kotlin) |
|---|---|---|---|---|
| Distribution | URL plus optional install or store wrappers | App stores | Desktop installers or stores | App stores |
| Update speed | Deploy the origin, then the worker updates | Store review plus a binary | Ship a new binary or an auto-updater | Store review |
| Offline | Cache Storage and a Service Worker you design | Similar, plus native plugins | Local filesystem or custom | Full OS offline APIs |
| Deep OS APIs | Improving, still incomplete | Plugins bridge gaps | Near-full desktop | Full |
| Security boundary | Origin plus the process model | WebView plus a bridge | Node or system bridge risk | OS sandbox |
| Best when | One web codebase, linkable, fast iteration | Need a store and some native APIs | Desktop filesystem and windowing dominate | Maximum platform fidelity |
Rule of thumb: prefer a PWA when the product is already a web app and install, offline, and push are enough. Choose a native shell when you need privileged APIs, store-first discovery, or background work beyond what Service Workers and iOS allow. Choose Electron when desktop filesystem and windowing dominate, and accept the larger attack surface.
What if you choose the other? Shells buy OS depth and cost binary updates plus bridge bugs. PWAs buy reach and cost careful worker and cache discipline, plus platform gaps, especially on iOS.
Decision map
Flow
- 1
1. Need an installable client
- next2. HTTPS, manifest, and SW
- 2
2. HTTPS, manifest, and SW
- next3. Decide if offline is critical
- 3
3. Decide if offline is critical
- next4. App shell and versioned caches
- 4
4. App shell and versioned caches
- next5. Strategy per resource class
- 5
5. Strategy per resource class
- next6. Design a visible update
- 6
6. Design a visible update
- next7. Use process and rendering to debug
- 7
7. Use process and rendering to debug
Lesson map
Browser Engines & PWAs — Service Workers, Rendering & Process Model
Interview map of browser architecture and the PWA platform: process model, rendering, Service Workers, and when a PWA beats a native shell.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB a["1. Need an installable client"] b["2. HTTPS, manifest, and SW"] c["3. Decide if offline is critical"] d["4. App shell and versioned caches"] a -->|1. Need an installable client| b b -->|2. HTTPS, manifest, and SW| c c -->|3. Decide if offline is critical| d
Read the chain as the default for a product that already lives on the web. A content site that must not install stops at the critical rendering path and never registers a worker. A dashboard that must work on a train takes the app shell and a versioned cache. The per-resource choice is the next lesson, not a single global mode.
What the rest of the cluster adds
- Service Workers — register, scope, install, waiting, activate,
skipWaiting,clients.claim, and fetch. - PWA cache strategies — cache-first, network-first, stale-while-revalidate, network-only, and Workbox versus hand-rolled Cache Storage.
- Manifest and offline UX — installability, the app shell, push, and background sync.
- Rendering pipeline — DOM, CSSOM, layout, paint, composite, and the critical rendering path.
- Process model — site isolation, Blink, the network stack, and the V8 pipeline.
Task ordering on one thread lives in JS event loop, microtasks, and macrotasks. Use that page when the question is "when does this promise run relative to paint." Do not re-teach language proficiency, React, or a sampling profiler here.
Choose the shell in code
The sandbox does not launch a browser. It only names the client shape from the constraints you already have.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Interview Q&A
What is the minimum mental model for a PWA?
Answer
A secure origin, a manifest for identity and install UI, a Service Worker as the programmable cache and network, and a deliberate update UX.
When does a PWA beat Electron?
Answer
When you do not need deep desktop OS integration, you want one deploy for every client, and you accept the browser's security boundaries as a feature.
How does this relate to the JS event loop?
Answer
Loop timing explains when scripts and promises run relative to paint. This cluster explains where they run (process, renderer, Service Worker) and how bytes become pixels and offline UX. The loop lesson is JS event loop, microtasks, and macrotasks.
Why is a hung tab not the whole browser?
Answer
The renderer for that site is its own process. The browser process can discard it and keep the UI. Site isolation is the longer version on the process-model page.
What do you say if the app never updates after deploy?
Answer
Confirm sw.js bytes changed and are not stuck in HTTP cache. See whether the new worker is waiting on open clients. Version the cache name and delete unknown caches on activate. Show an update toast instead of calling skipWaiting with no reload.
Is Blink the same thing as Chromium or V8?
Answer
No. Chromium is the browser project. Blink is its rendering engine. V8 is the JS engine Blink embeds. Chrome is Chromium plus Google services and branding.
Where should personalized API JSON live?
Answer
Network-only, or a cache key that includes the user. A shared Cache Storage entry for an authorized response leaks user A to user B.
What is the one codebase trap?
Answer
A PWA does not remove product work. You still design freshness, install criteria, and the iOS gaps. A shell does not remove that work either. It adds binary updates and a bridge.
Pitfalls
- Treating "PWA" as offline forever, with cache-first HTML.
- Debugging a worker bug as if it shared the page DOM and the page event loop.
- Picking Electron because install sounds hard, then owning a Node bridge you did not need.
- Explaining jank with a CPU profiler lecture when the trace shows layout on the main thread. The frame pipeline page owns that story.
Operators say yesterday's dashboard is still on screen after your production deploy. Sketch register, install, waiting, activate, and the cache names you would delete. Say what the user sees before you call skipWaiting.