Bandwidth, requests and edge functions: what you actually pay for
Modern hosting bills by what the site consumes, not by the server. The four units on the bill, what drives each, and how a small site keeps them all near zero.
The short answer
Traditional hosting charged for a server whether or not anyone visited. Modern platforms charge for what the site actually consumes, in four units: bandwidth, meaning bytes served to visitors; requests, meaning files asked for; function invocations and their compute time, for anything dynamic; and build minutes, for turning the code into the site. A well-built static site keeps all four small, because files are cached at the edge and nothing runs per visit. When a bill surprises, it is nearly always one oversized asset or one script calling a function on every page.
The four units
| Unit | What it counts | What drives it up | What keeps it down |
|---|---|---|---|
| Bandwidth | Bytes sent to visitors | Large images, video, uncompressed files, many visits | Sized and compressed images, modern formats, video on a dedicated service, edge caching |
| Requests | Files asked for | Pages made of many small files, no caching, bot traffic | Bundling, long cache lifetimes, a filtering layer in front |
| Functions | Number of calls and compute time per call | Dynamic features on every page, slow functions, bots hitting endpoints | Static wherever possible, functions only for real dynamic work, rate limits |
| Build minutes | Time to build the site per deploy | Large sites rebuilt fully on every change, slow image processing | Incremental builds, cached image processing, sensible deploy frequency |
Reading the dashboard
- Bandwidth by asset. The top few files usually explain most of it. An unoptimised hero image or a video file served directly is the usual finding.
- Requests by path. A path with far more requests than page views is being polled by a script or a bot.
- Functions by name and duration. One function with most of the calls, or one with unusually long duration, is the cost.
- Builds by trigger. Dozens of builds a day from content previews or automated commits add up on large sites.
What a small business site should expect
A static site with well-handled images, a contact form on a function, and a filtering layer in front consumes little in all four units. Bandwidth is dominated by images and stays modest when they are sized properly. Requests are cached at the edge. Functions run only on form submissions. Builds happen when content changes. Many such sites sit within the entry tier of modern platforms for years, and when they grow, the cost grows gently and visibly.
What this means for you
Usage-based hosting is fair and predictable once you know the four units and what drives each. Keep images sized, cache at the edge, run functions only for real dynamic work, and put a filtering layer in front so bots do not run up the meter. Then look at the dashboard once a quarter. The site that is cheap to host is the same site that is fast to load, which is not a coincidence.
Frequently asked questions
What counts as a request?
Every file a browser asks for: the page, each stylesheet, each script, each image, each font. A page that loads sixty files makes sixty requests. Bundling assets, caching at the edge and serving fewer, better-sized images all reduce the count. Bot traffic adds requests too, which is one reason a filtering layer in front saves money.
Why did our function costs jump?
Usually one of three things: a script calling a function on every page view instead of only when needed, a bot hammering a form endpoint, or a function that became slow and now uses more compute time per call. The dashboard shows which function and how often; the fix follows from that.
Do we pay for traffic from bots and scrapers?
On the common platforms, yes: bandwidth and requests are counted whoever asks. A network layer in front that drops known bad traffic before it reaches the platform keeps those numbers down, and caching means even legitimate crawler traffic is cheap.
Sources
- Vercel documentation: Pricing (accessed 2026-09-11)