Measure whether the image CDN bill is egress- or invocation-bound #25

Studio now asks the image CDN for the rendition that fits each slot (&size=), instead of taking the large default everywhere. That cuts egress sharply — the catalogue table went from the large rung to compact, roughly 10x fewer bytes per row — but it trades one thing we have not measured.

Status: parked. The bill was read in September 2026 and the whole project runs at ~8 €/month and falling, so neither side of this trade changes any decision today. See the comments. Revisit if the bill starts climbing.

The question

Is the CDN bill dominated by Storage egress, or by /img invocations?

Asking several renditions of the same product multiplies cache keys: a product that used to be one URL can now be requested as small, compact and large — three edge-cache entries and three 302s on first miss instead of one.

• If egress dominates, the change is a clear win and we could go further (a smaller rung for the rack tiles).
• If invocations dominate, we may want fewer distinct rungs — e.g. collapse small/compact into one, so every list shares a single key.

Rough intuition, not yet checked: a 302 is a few hundred cached bytes with no Storage read, so an invocation should be far cheaper than the bytes it saves. But "should be" is not a billing line.

How to answer it

GCP billing, broken down by SKU for this project: Cloud Run invocations + CPU-seconds for the /img service, against Cloud Storage network egress for the filament/* objects. The Reports page has to be opened by hand — it would not finish loading through browser automation.

What is already known, measured in the running app

The catalogue IS cached — by Chromium, not by us. Measured over a cold reload: 25 catalogue images, 25 served from the HTTP disk cache, 0 from the network, 0 bytes, and the 302 was not replayed either. The images carry cache-control: immutable, max-age=1y, so once fetched they do not come back. An earlier version of this issue said the catalogue was "pure network on every visit" — that was wrong.

What is true is narrower: the catalogue is not in the app's OWN disk cache (preCacheImages only warms the inventory). The difference that matters is that ours is permanent and version-keyed, while Chromium's is bounded and evicts — across 13 408 products x several renditions it will evict, and then re-fetch. Not "never cached", but "cached until the browser needs the room".

Everything is served as AVIF. The proxy negotiates on Chromium's Accept header and returns filament/<rung>/<id>.avif — 25 of 25 in the same measurement. Every byte figure quoted for the rungs (33 kB for large, 3.4 kB for compact, …) was measured with curl WITHOUT that header, so they are JPEG sizes: the ratios between rungs hold, the absolute numbers are pessimistic.

Settled, do not re-litigate

&stream=1 (serve the bytes instead of the 302) was considered and rejected on cost. The endpoint supports it and it removes a round-trip and a second origin — but it moves the image egress off Storage and onto the function, and bills CPU in proportion to the bytes served. The redirect is the cheap shape by design: a tiny cached response, with the payload coming straight from Storage. Recorded in cdnImg() in renderer/inventory.js so it is not re-discovered as a good idea.

Pre-caching a smaller rendition was also rejected. The local disk cache holds ONE rendition per product and the detail panel reads it too, so warming medium would save 23 kB once and then cost a full-size fetch on every panel open. Fetched once and free forever afterwards is the lowest TOTAL egress. Recorded in preCacheImages().

Neither rejection depended on the egress/invocation split — both were rejected on shape, not on scale.

Reference

The rendition ladder, the 302 behaviour and the HTTP/2 note are documented in CLAUDE.md -> API base -> Product images. Source of truth for the sizes is the SIZES map in the backend repo's functions/index.js.