Summary

  • Fastly records an edge miss and a shield hit separately even when that delivery makes no origin request. Headline cache-hit ratio is not a direct measure of origin requests avoided.
  • Traffic between Fastly POPs counts towards requests and billable bandwidth. The documentation describes possible overall savings, not a guarantee that shielding lowers every customer’s bill.
  • Headers and raw metrics have their own reporting boundaries: an edge-hit response can carry an earlier shield event, and cacheable-fetch counters do not count every kind of request.

One delivery produces more than one cache result

Fastly’s shielding concepts guide describes an intermediate POP that can satisfy a request after the receiving edge has missed. If that shield has the object, the user receives content from within Fastly’s network without a request to the origin.

The same guide says both the edge miss and the shield hit enter the cache-hit calculation. A request that reaches the origin contributes two misses, one at each layer. A delivery and a recorded cache event are therefore not the same unit. The headline ratio may look lower than a buyer expects even when the shield has done useful origin-avoidance work.

That observation is narrower than saying every lower ratio is good. A service could have genuine cache-key, freshness or traffic problems. It is also narrower than saying every origin reduction proves economic improvement: fewer successful user requests could reduce demand too. No customer traffic was examined here. The useful point is that the published counting mechanism prevents one ratio from proving the whole result.

Avoided origin work is not absent CDN work

The configuration guide says inbound shield traffic is billed as regular traffic, including traffic that populates other POPs. The concepts guide explicitly includes inter-POP traffic in request count and billable bandwidth.

An edge miss followed by a shield hit can thus avoid the origin while still consuming an internal CDN leg. Those descriptions are compatible. The shield is doing the work that otherwise might have reached a different part of the system; useful work need not be free work.

Fastly says additional bandwidth charges are likely to be offset by origin bandwidth and server-load savings, and that shielding often reduces overall costs in realistic scenarios. That is an important potential benefit, not an independently observed customer result. An actual comparison needs the traffic mix and the commercial terms on both sides of the origin/CDN boundary.

The guide’s extreme case is a service configured to PASS every request. It says requests and delivery bandwidth almost double because most requests are presented to two POPs. This is not a universal promise of a doubled monetary bill, nor a claim that the same billable activity has been erroneously charged twice. Discounts, commitments, traffic composition and origin prices were not inspected in this research.

The buyer needs a baseline with the same units

A procurement scorecard that rewards only a higher cache-hit ratio could reject useful shielding because it counts two cache decisions where the buyer expected one. Another scorecard that rewards only fewer origin calls could omit the added CDN leg. Both can be accurately reading a number and inaccurately describing the purchase.

A more useful acceptance comparison keeps the audience demand and time window explicit, separates origin and shield activity, and names the bytes included in each measure. A body-byte field is not a header-plus-body total simply because both sound like bandwidth. A request count is not a unique-user count. There is no numerical customer saving to report here; these are the conditions needed before one could be claimed.

The buyer need not demand that shielding reduce every possible counter. The point of an intermediate cache is to change where work happens. What matters is whether the changed work serves the intended delivery and commercial objective, and whether both teams can explain it without using a favourable metric as a substitute for the missing one.

Two server names need not mean two current visits

Fastly’s concepts guide adds a subtle reporting limit. Shielded responses can contain entries for several POPs in X-Served-By, X-Cache-Hits and X-Cache. But on an edge hit, the entry representing the shield can come from the earlier event when that object was cached. It need not show a shield visit made by the current request.

Counting every two-entry response as a fresh paid traversal would therefore turn historical response information into an invented current event. The headers are useful evidence only when their meaning is preserved. The X-Served-By reference also warns that cache identities can be reused as nodes enter and leave service; an identity captured at one time should not become a permanent asset label across time.

No live customer header was collected or customer CDN probed for this article. The distinction comes from the public specification, not a reconstructed customer route or an invoice inferred from a screenshot.

HIT and MISS are simplified reports

The X-Cache reference cautions against another shortcut. PASS is reported as MISS, edge-generated synthetic content as HIT, and stale or background-revalidation hits also as HIT. Multiple entries can arise through shielding, Next-gen WAF at Edge or restart logic.

That makes HIT an unsuitable universal synonym for “this current request retrieved a stored object exactly as imagined”. The reference’s explanation of non-MISS entries as cache satisfaction rather than forwarding also has a restart qualification. The buyer should not strip those qualifications away to obtain a simpler billing or origin-access conclusion.

There is no need to turn this into a programming tutorial. The commercial implication is that a header’s presentation is not the contract’s charging unit. Operators can use it to understand a response, but finance cannot simply sum its entries as independently proven invoice lines.

Raw statistics still have boundaries

Fastly’s real-time analytics reference and Historical Stats reference provide separate shield and origin measures. Shield fetches describe inter-POP requests as part of shielding; the cache-fetch measures specifically concern completed requests returning cacheable content. That qualification matters when comparing them with broader request counts.

The references also distinguish shield hits and misses and several request and response byte fields. They allow a buyer to ask where delivery work occurred, without making every field interchangeable or turning raw observations into a net-cost finding. A service-specific account would need matching measurement windows, definitions and applicable commercial terms.

The result is not an argument against shielding. It is an argument for buying its actual effect: successful delivery with a changed distribution of work. An edge miss and a shield hit can describe an origin spared, a ratio carrying an extra miss, and a paid CDN leg at the same time. A sound acceptance report can keep all three truths in view.

Sources