The Vercel Cost Equation
A mental model for understanding exactly where your money goes - and where it doesn't.
The One-Sentence Version
You pay for people (seats), thinking (CPU), shipping (bandwidth), and extras (images, analytics). The billing model rewards you for doing less work per request—so cache aggressively, query smarter, and ship smaller payloads.
The 2024 Billing Revolution
Vercel flipped the script on how they charge for compute. Understanding this change is worth thousands of dollars.
The old way: You paid for wall-clock time. If your function sat idle for 2 seconds waiting for Postgres to respond, you paid for those 2 seconds of nothing.
The new way: You only pay for active CPU cycles. Waiting for I/O? Free. Only the moments where JavaScript is actually crunching numbers hit your bill.
Think about a typical API route. It parses the request (5ms of work), fires a database query (waits 200ms), processes results (15ms of work), and sends a response (5ms of work).
Under the old model, you paid for 225ms.
Under active CPU billing, you pay for 25ms.
That's not a small optimization. That's an 89% discount baked into the platform.
The catch: If your code is genuinely CPU-heavy—image processing, complex calculations, lots of loops—you won't see the same savings. The discount only applies to I/O wait time.
Here's a real breakdown for a database-backed API route:
| What's Happening | Time | Old Bill | New Bill |
|---|---|---|---|
| Parse incoming JSON | 5ms | Billed | Billed |
| Waiting for DB response | 200ms | Billed | Free |
| Transform the data | 15ms | Billed | Billed |
| Serialize response | 5ms | Billed | Billed |
| Total charged | — | 225ms | 25ms |
Same exact code. Same exact functionality. 89% cheaper.
Now multiply that across every API call your app makes.
What $20/Month Actually Buys You
The Pro plan gives you a budget before overages kick in. Here's what you're working with:
| Resource | Your Allowance | What Burns Through It |
|---|---|---|
| Active CPU | 40 hours | SSR renders, API routes, Server Actions, middleware |
| Bandwidth | 1 TB | Every byte sent to browsers—HTML, JS, CSS, images, JSON |
| Edge Requests | 10 million | Middleware executions, edge function calls |
| Monthly Credit | $20 | Applies toward any overages |
The Team Seat Trap
Vercel bills per dashboard user. Every person with access = $20/month. That "quick access" you gave to a stakeholder six months ago? Still charging. Run a quarterly audit—it takes 2 minutes and saves real money.
Image Optimization
Images use a separate billing model: roughly $0.05 per 1,000 unique transformations. A "transformation" is any unique combination of dimensions and format. We'll cover optimization strategies in the bandwidth section.
The Three Dials You Can Turn
Every cost optimization boils down to one of three moves:
Dial 1: Don't Run The Code At All
The cheapest function call is the one that never happens.
Tactics:
- Convert dynamic pages to static (SSR → SSG)
- Cache responses at the edge
- Debounce client requests
- Kill polling—use webhooks or longer intervals
Ceiling: 100% savings on that code path. Literally free if it never executes.
Dial 2: Make The Code Faster
When you must run code, finish faster.
Tactics:
- Fire I/O operations in parallel (
Promise.all) - Move aggregation to the database
- Use connection pooling
- Drop memory allocation to match actual usage
Ceiling: 50-80% reduction, typically. Diminishing returns after the obvious fixes.
Dial 3: Send Less Stuff
Bandwidth costs scale with payload size. Smaller responses = smaller bills.
Tactics:
- Enable compression (usually automatic, but verify)
- Paginate everything
- Return only the fields the client needs
- Optimize images before they hit Vercel
Ceiling: 40-70% bandwidth reduction depending on how bloated your responses are.
The Billing Cheat Sheet
What actually costs money vs. what's free:
| 💸 Costs Money | ✅ Essentially Free |
|---|---|
| Server-rendering a page | Serving a static page from CDN |
| Running an API route | Client-side JavaScript execution |
| Executing a Server Action | Serving a cached ISR page |
| Transforming an image | Serving an already-transformed image |
| Running middleware | Reading from environment variables |
| Preview deployments (compute) | Serving HTML from edge cache |
The ISR Cheat Code
Incremental Static Regeneration is the sweet spot for most pages. You pay once for the render, then serve from cache until it's time to refresh. All the freshness of SSR at 1/100th the cost for high-traffic pages.
Match Your App Type To Your Strategy
Different apps have different cost shapes. Find yours:
Where your money goes:
- 60-75% → Compute (API routes, real-time features, Server Actions)
- 15-25% → Bandwidth (JSON payloads, app bundles)
- 10-15% → Everything else
Your highest-ROI moves:
- Cache API responses (even 60 seconds helps enormously)
- Batch database queries—kill N+1 patterns
- Push polling intervals from seconds to minutes
- Paginate list endpoints aggressively
Where your money goes:
- 50-70% → Bandwidth (images, video, downloadable assets)
- 15-30% → Compute (if you have SSR—many content sites don't)
- 10-20% → Image transformations
Your highest-ROI moves:
- Serve media from a dedicated CDN (Cloudflare R2, Bunny, etc.)
- Go fully static where possible—SSG everything
- Standardize image dimensions to reduce unique transformations
- Lazy-load everything below the fold
Where your money goes:
- 30-40% → Compute
- 30-40% → Bandwidth
- 20-30% → Images + builds (lots of product photos)
Your highest-ROI moves:
- ISR for product pages (revalidate on inventory changes)
- Paginate search results—nobody scrolls past page 3
- Lazy-load product images in grids
- Cache cart/pricing APIs at the edge
The Hidden Cost: Preview Deployments
Every pull request spins up a full deployment. For active teams, this adds up:
| Team Size | Weekly PRs | Monthly Preview Builds |
|---|---|---|
| 3 engineers | ~15 | 60+ |
| 10 engineers | ~50 | 200+ |
| 25 engineers | ~150 | 600+ |
Each preview consumes build minutes. If someone visits it, that's compute and bandwidth. And they persist indefinitely unless you clean them up.
Quick win: Add this to vercel.json to auto-cancel superseded builds:
{
"github": {
"autoJobCancellation": true
}
}That alone can cut preview costs by 30-50% for active repos.
Reading Your Invoice Without Crying
When the bill arrives, you'll see line items like:
- Pro Plan Subscription — Seat count × $20
- Additional Function Duration — Hours over 40 × rate
- Additional Bandwidth — GB over 1TB × $0.15
- Image Optimizations — Transformations × rate
The diagnostic question: Is any single line item more than 40% of your total? That's your optimization target. Don't spread effort thin—go deep on the biggest number first.
The Actionable Summary
Active CPU billing is your friend
I/O wait is free. Database queries, API calls to external services, file reads—none of that execution time counts. Focus optimizations on actual JavaScript work, not total response time.
Three dials: Invocations → Duration → Payload
In that order. Eliminating a function call beats making it faster. Making it faster beats shrinking the response. But all three compound.
ISR is usually the answer
For any page that can tolerate 60-second staleness, ISR gives you SSR freshness at static-page prices. It's the default choice until you have a reason to do something else.
Audit seats and previews quarterly
The boring stuff. Zombie team members and lingering preview deployments are steady drains that nobody notices until the bill arrives.
Next up: Find Your Cost Hotspots — a 30-minute process to identify exactly which routes are burning money.