Introduction
When you deploy on Vercel, there are two separate bandwidth metrics you need to understand — and most developers only notice one of them. Last post I covered Fast Origin Transfer, which is the internal data moving between Vercel's CDN and your compute functions. Today we're looking at the other one: Fast Data Transfer.
My dashboard showed 553.49 MB used out of a 100 GB monthly limit. Here's what that number actually means, what's driving it, and how to reduce it if you need to.
What is Fast Data Transfer?
Fast Data Transfer is the bandwidth consumed when Vercel's CDN delivers content to your site's end users. Every time a visitor loads your site — a page, an image, a font, a JSON response — that data travels from Vercel's nearest edge node to the user's browser. That's Fast Data Transfer.
This is the metric most developers think of when they hear "bandwidth". It's the last mile: Vercel → User.
How is it different from Fast Origin Transfer?
It's easy to confuse the two, so here's the clearest way to think about it:
- Fast Origin Transfer — data between Vercel's CDN edge and your Vercel Compute (server functions). Internal network. 10 GB free limit.
- Fast Data Transfer — data between Vercel's CDN edge and your end users' browsers. Public internet. 100 GB free limit.
A single user page load triggers both: the edge might fetch from compute (Origin Transfer), then deliver the result to the user (Data Transfer). But static assets served directly from the CDN cache only generate Data Transfer — no Origin Transfer at all.
Incoming vs Outgoing — what do they mean here?
My dashboard showed:
- Incoming: 180.8 MB (32.7%) — data sent from users to Vercel's CDN. This is HTTP request payloads — form submissions, file uploads, POST request bodies coming from users' browsers.
- Outgoing: 372.69 MB (67.3%) — data sent from Vercel's CDN to users. This is everything your site delivers: HTML pages, JavaScript bundles, CSS, images, fonts, JSON API responses.
The 67.3% outgoing vs 32.7% incoming split is expected for most web apps. Your site sends far more data than it receives — pages, assets, and API responses are almost always larger than the requests that triggered them.
What's interesting here is that my incoming ratio (32.7%) is relatively high. This tells me users are sending meaningful data to my site — probably form submissions or API calls with POST bodies — not just browsing static pages.
Reading the chart
The usage chart runs from mid-April to May 14, and the pattern tells a clear story:
- Zero traffic April 16–May 1 — the site had barely any visitors during this period. No data transfer means no users.
- First activity around May 2 — a small spike of about 19 MB, mostly outgoing. Someone found the site.
- Large spike May 4 — the biggest blue (incoming) bar of the entire chart, at roughly 58 MB, with outgoing going to about 77 MB total. This was the day the site got shared or promoted somewhere — a surge of visitors each loading pages and likely submitting forms.
- Peak on May 10