v158 · resource timing · baseline
Body size basics
Same-origin first: for your own resources the three byte counts are always exposed, in every browser, under every gating regime. This page fetches this site's real assets, receives the PerformanceResourceTiming entry through a live PerformanceObserver, and derives the numbers developers actually use the fields for — compression ratio, cache hits, and header overhead.
What Chrome 158 changes (runtime feature ResourceTimingUseCORSForBodySizes) is only the cross-origin gate — see the gate matrix. Everything on this page is same-origin and therefore identical before and after; it is the baseline the gates subtract from.
Fetch a real asset, read its entry
decodedBodySize—bytes after decompression — what the parser sees
encodedBodySize—body bytes as transferred (e.g. gzip/br output)
transferSize—encoded body + ~header estimate; 0 on cache hits
encoded as a share of decoded (compression at a glance):
No fetch yet.
how the entry arrives
const seen = new Map();
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) seen.set(entry.name, entry);
}).observe({ type: "resource", buffered: true });
const res = await fetch("/public/styles.css", { cache: "reload" });
await res.blob(); // the entry completes with the body
const entry = seen.get(res.url); // delivered by the observer
entry.decodedBodySize; // e.g. 48 112
entry.encodedBodySize; // e.g. 9 347 after gzip
entry.transferSize; // encodedBodySize + ~300, or 0 from cache