Vercel SKUs
Billing on any platform is easier to reason about when you can trace a real request from start to finish. In this video, we follow a single reader visiting a breaking news article on a high-traffic blog and see exactly which Vercel resources are consumed along the way.
Edge Requests
Every incoming request to Vercel's CDN counts as an Edge Request, whether the response is served from cache or generated dynamically. This is the starting point for every interaction with your app.
Routing Middleware
Before the cache is checked, routing middleware can run logic like inspecting an authentication cookie to decide whether a user sees the full article or a preview. Middleware uses the Fluid Compute billing model: you pay for active CPU time plus a small invocation fee per request.
Fluid Compute
When a page renders on demand with a Vercel function, Fluid Compute kicks in. Unlike traditional serverless billing that charges for the entire function runtime, Fluid Compute only bills for the milliseconds your code is actively processing. If your function is waiting on an API response, that idle time is free.
Fast Origin Transfer and Fast Data Transfer
Once your function generates a response, it travels to Vercel's Edge Cache. This internal transfer is Fast Origin Transfer (FOT), measured by bandwidth from compute to the edge.
From there, the response is delivered to the user's browser. That's Fast Data Transfer (FDT), measured by the payload size sent to end users. A 1 MB hero image means 1 MB of FDT.
Runtime Cache
To avoid hitting your CMS and re-rendering on every request, you can cache responses from inside your functions. Writing to the cache consumes Write Units. Subsequent requests pull from cache using Read Units, which are faster and cheaper than an origin fetch.
On-Demand Revalidation
When content changes and you can't wait for a cache timer to expire, On-Demand Revalidation lets you mark specific cache entries as stale. A CMS webhook calls your revalidation endpoint, the tagged entries refresh on the next request, and the updated content is written back to cache.
Recap
- Edge Requests count every request to the CDN
- Routing Middleware runs before cache, billed on active CPU time
- Fluid Compute bills only for active processing, not idle waiting
- FOT is bandwidth from your function to the edge; FDT is bandwidth to the user
- Runtime Cache saves cost with Read/Write Units instead of repeated origin fetches
- On-Demand Revalidation keeps content fresh without waiting for timers
Follow up docs
Was this helpful?