Performance
Origin shield
Origin shield is one designated cache layer between a CDN's edge locations and your origin. Misses from many edges collapse into a single request to the origin.
How it is measured
Measure origin requests per unique object. Without a shield, a new file asked for by 30 edge locations can hit the origin 30 times. With one, it should hit once. Your CDN dashboard usually reports shield hit ratio separately from edge hit ratio.
Confirm it from headers or logs. Cloudflare Tiered Cache, CloudFront Origin Shield, and Fastly shielding each expose the shield location in a header or log field. Pick the region nearest your origin, then watch origin requests and miss-path TTFB.
Worked example
A news site publishes a 2.4 MB poster image at 09:00 and links it from a push notification. Within a minute, 41 edge locations ask for it. With no shield, the origin (an S3 bucket plus a small Node app) takes 41 fetches and the Node box spikes to 85% CPU.
With a shield in us-east-1 next to the origin, the origin sees 1 fetch and the other 40 edges fill from the shield. Origin egress for that launch drops from about 98 MB to 2.4 MB.
How it differs
An origin shield is a cache; the origin is the source of truth. The shield remembers copies and absorbs duplicate misses, but it cannot create a page it has never seen. It also adds a hop, so a miss that must reach the origin gets slightly slower, not faster.
Common errors
Enabling it in a region far from the origin. Expecting it to help uncacheable dynamic pages. Counting shield hits as edge hits and overstating the cache ratio. Turning it on for a tiny site with traffic from one country. Forgetting that a purge has to clear the shield layer too.
In practice
Turn it on when origin load spikes after publishes or purges and your audience spans many regions. Choose the shield location closest to the origin. Compare origin requests per day for a week before and after; if the count does not fall by half, switch it off and stop paying for it.