Measured in your browserWe advise on speed. We practice it.Loaded just now · real numbers from this visit, not a lab score.
Page loaded
First byte
DOM ready
First paint
Largest paint
DNS lookup
TLS handshake
Transferred
Saved by compression
Requests

A CDN invoice with no allocation is a number nobody owns: product teams ship heavier pages, launch chattier features and store bigger videos while the delivery line grows in someone else’s budget. Allocation fixes the incentive by fixing the visibility — every product sees its own delivery cost move when its own decisions move it. The pipeline is four parts: a map, a meter, rules for the remainder, and a monthly report someone actually reads.

Why allocation changes behaviour

The point is not accounting neatness; it is that delivery cost is a consequence of product decisions, and consequences unpriced are consequences repeated. When the video team sees its own petabytes and the API team its own request millions, three things happen: cost work like the ten levers acquires owners per lever (the image diet belongs to whoever owns the image bytes); forecasting improves, because driver-based models calibrate per product instead of blended; and the annual budget conversation stops being delivery-team-defends-a-blob and becomes products-own-their-lines. Aim the design at decision-usefulness, not audit-grade precision — a consistent 95%-right allocation published monthly beats a perfect one published never.

The map: hostnames, paths, owners

Allocation quality is decided by how traffic identifies its owner, and the hierarchy of reliability is: hostname first — where products already live on their own hostnames, allocation is nearly free; path prefix second — one shared hostname with disciplined prefixes (/api/, /video/, /assets/checkout/) allocates cleanly if the prefix map is maintained; tagging metadata last — some platforms let configs carry labels, useful where structure fails. The map itself — hostname/prefix → product → owning team — lives in version control next to the delivery config, reviewed when either changes, because a stale map silently misassigns every downstream number; it is the same estate inventory the one-pager maintains, wearing its finance hat. And feed the map forward: new products get a hostname-or-prefix decision at design time, which costs nothing then and everything to retrofit.

The meter: usage from logs, rated into money

Measure usage from edge logs — delivered bytes and request counts summed per map entry per month, with region where your bill is region-priced; the fields are the standard set from the log-line guide, and sampled logs are fine (scale the sample, note the error, move on). Then rate usage into money one of two ways. Effective-rate: divide each invoice family’s total by its total usage and apply the blended rate to each product’s usage — simple, always sums exactly to the invoice, slightly unfair to products whose traffic is cheap-region-heavy. Rate-card: price each product’s regional usage at contract rates and scale the result so the total matches the invoice — fairer, more moving parts. Start with effective-rate; graduate only if a product credibly objects with regional numbers. Meter feature lines separately where they meter cleanly (image transforms, edge invocations map to their driving product via the same paths); the goal each month is that the product columns sum to the invoice, to the dollar, with the residue handled next.

The awkward remainder: shared and unattributable

Some spend resists mapping: shared assets (the design system every page loads), platform overheads (log delivery, support percentages, security features protecting everything), and the genuinely unattributable residue (unmapped paths, bot noise). Resist both bad endpoints — ignoring it (products under-see their true cost) and burying it in the biggest product (which then rightly distrusts the whole report). Instead: keep the shared bucket explicit and visible, split it by a stated rule — proportional to attributed usage is the defensible default; per-head or per-product flat splits where usage-proportional is clearly wrong — and write the rule down where the report links to it, because allocation disputes are always rule disputes, and a written rule converts them from monthly arguments into annual reviews. Watch the unmapped residue as a health metric: rising unmapped percentage means the map is rotting, and the fix is the map, not the rule.

Showback, chargeback and keeping it honest

Start with showback — the monthly report per product (usage, money, trend, share of shared bucket) published where teams already look — and let it run for quarters before considering chargeback (actually moving budgets), because showback captures most of the behavioural value at a fraction of the political cost, and chargeback amplifies every mapping error into a finance dispute; graduate only if showback demonstrably fails to move decisions. Keep it honest with three habits: reconcile to the invoice monthly (the columns must sum — the same discipline as the invoice review, one level down); annotate step-changes with their cause (launch, config change, price change) so the report accumulates institutional memory; and review map + rules once a year in the annual review, where the allocation table is the exhibit that turns “delivery costs too much” into “these two products grew and here is why” — which is the conversation the whole pipeline exists to enable.

Get the free assessmentMore analysis