Performance
Origin
Origin is the server that holds the real application and produces the original response. A CDN or proxy in front of it answers when it can and asks the origin when it cannot.
How it is measured
It is observed, not counted. Request a URL with a throwaway query string and note the time to first byte; that is roughly what the origin costs on a cache miss. Response headers such as `cf-cache-status: MISS` or `x-cache: Miss from cloudfront` tell you the edge went back to it.
The origin's own access log shows the traffic that got through. Divide origin requests by total requests and you have the miss rate in plain form. If your host bills per request or per CPU second, that log is also your invoice.
Worked example
A Laravel store on a single 2-vCPU VPS in Frankfurt serves 90,000 requests on Saturday. The CDN answers 81,000 from cache and the origin handles 9,000, peaking at 14 requests per second. Median origin TTFB is 420 ms; an edge hit returns in 35 ms.
On Sunday someone purges the whole cache at 10:00. For eleven minutes the origin sees 60 requests per second, CPU pins at 100%, and TTFB climbs to 3.1 s before the cache refills.
How it differs
The origin is where the response is made. A CDN is a fleet of caches that repeat that response closer to the visitor. The CDN cannot serve what is uncacheable, like a logged-in cart, and the origin cannot be in more than one place at once.
Common errors
Leaving the origin IP reachable so bots and attackers bypass the CDN. Testing speed with a warm cache and concluding the origin is fast. Letting `Set-Cookie` on public pages stop the edge from caching them. Scaling up the server when the real fix is a longer cache lifetime.
In practice
Sort yesterday's origin access log by URL and read the top ten. Those are your caching targets. Then restrict the origin to accept traffic only from your CDN's address ranges, and re-test TTFB with and without a cache-busting query string.