Incognito-per-render forfeits Chrome's V8 code cache (~9% CPU measured); parked on isolation at concurrency

[harper-joseph]

What is true today

Every render gets a fresh incognito BrowserContext (settings.incognitoPages, default true; ManagedBrowser.getPage). An off-the-record context's HTTP cache is in-memory and dies with the context, and Chrome's V8 code cache lives in the disk-cache backend — so no compiled script ever survives a render. Two consequences:

• --disk-cache-size=1073741824 in DEFAULT_CHROME_ARGS has never applied to a single render.
• A sub-resource replayed from our own ResourceCache via Fetch.fulfillRequest never enters Chrome's HTTP cache either, so it can never get a code-cache entry. Our cache saves the fetch and forfeits the compile.

Every script on every page is therefore parsed and compiled from scratch, every render.

What it is worth

Measured on a live commerce product page, 6 renders per arm, interleaved, medians excluding the cold first render:

arm	wall	CPU	ScriptDuration
incognito context per render (today)	4,197ms	4,900ms	808ms
default context + persistent userDataDir	3,845 (−8%)	4,440 (−9%)	629 (−22%)
persistent profile + per-render wipe	3,749 (−11%)	4,450 (−9%)	581 (−28%)

Content identical in every arm (review nodes 1,430; zero un-hydrated framework islands; HTTP 200).

A synthetic fixture cannot size this — it reports ScriptDuration of ~40ms in a 7,500ms render, and V8CompileDuration is useless as an instrument because V8 compiles lazily on background threads. The win scales with a real page's script cost (measured 800–2,465ms on real pages), so only a real-page measurement decides it.

Why this is parked rather than shipped

The arm that was measured cannot ship. It ran at maxActivePages: 1 — strictly sequential — with incognitoPages: false, meaning every render shared the default context's single cookie jar. At production concurrency that breaks in two ways:

1. Identity bleed across unrelated URLs. Concurrent renders of different pages interleave session, visitor and bot-mitigation cookies. This repo already measured the sibling case: an unwiped shared context handed a second device variant 125 cookies instead of the 6 pinned ones, putting both devices on one session id, one visitor id and one bot-mitigation token (see the v1.28.0 context-sharing work and variantContext.ts). That is why context sharing only ever shipped scoped to one job, with a mandatory wipe and a fail-closed fallback.
2. The wipe is globally destructive. deleteCookie + Storage.clearDataForOrigin act on the whole context, so firing it between renders would delete the cookies of renders still in flight. Structural, not a tunable race.

The shape that could ship

One browser per slot, each with its own --user-data-dir — not a shared context. Each slot then has its own cookie jar (isolation exactly as today), its own disk cache (so the code cache warms), and renders within a slot are sequential by construction, which is the condition resetForNextVariant was designed for. It is the existing per-job argument, one level up.

Already settled, so nobody re-derives it

• The wipe is not a cost. Measured on live pages with all cookies deleted each time: 2–5ms against a ~4,000ms render (~0.1%), on a jar holding 48–77 cookies. The jar does not accumulate, because the wipe runs every render. (Puppeteer issues one Network.deleteCookies per cookie and 75 of them still lands in single-digit ms.)
• Memory is not the constraint. Production pods have ample memory and disk. RSS is ~265MB per concurrent slot and linear, and extra browser processes cost 7–14% more RSS — worth reporting, not disqualifying.
• Storage.clearDataForOrigin does not clear the HTTP disk cache, which is why the wiped arm kept the whole win. Isolation and the code cache are not in tension.

What has to be measured before picking this up

1. Does browser aging justify retiring at 200 pages? (settings.browserExpirationThreshold) Retirement every ~13 minutes is exactly what would discard the warm profile. The reason on record is a general "prevent memory leaks" recommendation plus an operator observation that aged browsers seemed slower; it has never been measured. Wanted: an aging curve over 200–300 sequential renders (per-render wall, CPU, ScriptDuration, RSS, process count) reported as a series, with today's fresh-incognito shape as the control, and attribution if drift appears — is it RSS-correlated, renderer-process-age-correlated, or reset by disposing a context while keeping the browser? Only one of those is a thing retirement actually fixes.
2. Cookie semantics across job boundaries. Inside a slot, consecutive renders are different URLs, so the wipe must delete all cookies including the pinned ones — pins are job-scoped by design. That is a different wipe than the one that exists.
3. Per-slot RSS and process count at realistic concurrency, for sizing rather than as a blocker.

Related

Our ResourceCache deserves a look in the same pass: measured at production resource counts it does not remove CPU, it moves ~50ms onto the single Node thread to save ~70ms of Chrome CPU, and Chrome's own cache achieves the same origin offload at zero Node cost — though only within one browser's lifetime, whereas the disk cache is shared across slots and restarts. That trade is only justified by real origin RTT, which a localhost fixture cannot price.

Bench harness and full numbers: bench/render-cpu/ (README has the method, the instruments, and the dead-end table).

[harper-joseph]

Partial data from a browser-aging run that was stopped at 25% (60 of 240 renders per arm), plus one finding that stands on its own. Harness is on the bench branch as bench/render-cpu/aging.js; a full run is ~32 minutes.

The wipe is 10–20× more expensive on a persistent profile

Measured with an empty cookie jar, so the cookie half is a no-op and this is Storage.clearDataForOrigin alone paying for a disk-backed profile rather than an in-memory one:

context	wipe p50	max	as % of render
pooled incognito (in-memory)	1ms	1ms	0.01%
pooled incognito, recycling	2ms	2ms	0.03%
default context, persistent profile	20ms	21ms	0.27%

This is a cost that belongs specifically to the persistent-profile candidate and it is the floor: puppeteer issues one Network.deleteCookies per cookie, and a real storefront jar was measured at 48–77 cookies steady-state (125 when unwiped). Separate live-page measurement put the whole wipe at 2–5ms on an incognito context with ~75 cookies, so the two numbers together suggest the profile-backed storage clear dominates, not the cookie deletion. At 20ms against a ~4,000ms render it decides nothing by itself — it just needs to be in the ledger, and it was not in the −11%/−9% comparison.

Aging: indeterminate, do not read as a negative

Three sample points per arm is not a curve. Recording it so the next attempt starts here rather than from zero:

arm	page 20	page 40	page 60
fresh incognito per render (today)	7,460ms / 2,187ms CPU / 1,430MB	7,456 / 2,160 / 1,434	7,450 / 2,383 / 1,447
pooled incognito	7,467 / 2,260 / 1,430	7,451 / 2,173 / 1,436	7,462 / 2,270 / 1,439
pooled, due to recycle at page 120	7,463 / 2,202 / 1,426	7,461 / 2,220 / 1,434	7,462 / 2,495 / 1,436
persistent profile	7,478 / 2,262 / 1,418	7,472 / 2,395 / 1,425	7,466 / 2,327 / 1,426

• Wall is flat to 0.2% in every arm over the first 60 pages, including the two that accumulate state.
• CPU is non-monotonic in three of four arms and every value sits inside the ~±5% batch spread. The largest single jump is in an arm that had not yet done anything different from its neighbour — a useful illustration of the noise floor.
• RSS drifts ~1% per 40 pages in all four arms, including the control that destroys a browser context on every render. A drift the control shares is not context accumulation. This is the one number worth re-measuring properly.
• Fidelity held (461 review nodes) in every arm.

The recycle arm never reached its recycle point, so the question that most needs answering — is the thing that ages the context or the browser? — has no data at all.

Two things already built for the follow-up

• A ?cookies=N fixture knob and wipe-0 / wipe-25 / wipe-125 arms to price how the wipe scales with jar size. Run those at concurrency 1 — on a shared default context, concurrent wipes delete each other's cookies and the timing stops meaning one wipe's cost.
• The pooled-recycle arm, which is the only way to separate "retire the context" from "retire the browser". Note it must be a pooled-incognito arm: a browser will not let you dispose its default context, so that experiment cannot be run on the persistent-profile shape at all.

Also worth noting: retirement counts pages opened, not renders (browser.totalOpenedPages > BROWSER_MAX_TOTAL_PAGES in Worker.ts).