demo · v149

Cold vs Warm

Load the same same-origin probe page repeatedly. Its inline script is cache-eligible: stable source text, same network isolation key, no dynamic code generation. The table compares the first hash sighting with later loads, then shows how one byte of source change creates a new cold key.

The browser does not expose a direct "bytecode cache hit" bit. This demo keeps the network isolation key stable by loading a real same-origin URL, avoids eval() in the cacheable probe, and reports PerformanceObserver mark/measure entries emitted by the inline script. Timing still varies by machine, but the cache key and eligibility model are now real.
probe URLnot run yet
last hashnone
script size0 B
known hashes0
run variant route hash iframe elapsed script measure marks verdict

PerformanceObserver marks from last run

waiting-Run a probe to collect script-* marks.

what's being measured

The iframe is loaded from /v149/inline-script-cache/cold-vs-warm/probe, not a blob: URL. The stable variant serves the exact same inline script source on every run. The mutated variant changes one literal from A to B, changing the SHA-256 cache key. The eval-disqualified variant is intentionally not cacheable and is labelled separately.

edge cases

one byte changed

The mutated run changes one literal and produces a new SHA-256 hash, so it is recorded as a cold miss until repeated.

same-origin route

Every cacheable run uses the same origin and route shape. A query parameter changes per run, but the network isolation key remains stable.

dynamic code disqualified

The eval-disqualified probe uses a separate script body and is never labelled as a warm cache hit, even if its hash repeats.

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗