Vercel vs Netlify vs Cloudflare Pages: Which Meter Will Your Frontend Hosting Bill Actually Grow On?

The headline plan price rarely decides your frontend hosting bill. Three meters do: outbound bandwidth, server-side compute (functions, SSR, image optimization), and per-seat charges. Cloudflare Pages is the safest choice when bandwidth is the risk, Vercel is the smoothest when you run Next.js with SSR and a team, and Netlify sits in between with a model that has changed enough that you should re-read it before committing.

All plan details below are as of November 2026. These vendors revise pricing often, so use this post for the structure of the decision and confirm current numbers on each pricing page.

What is a frontend hosting bill actually made of?

Almost every overage I have seen traces back to one of four line items:

1. Bandwidth (egress): bytes served from the CDN to browsers. Big images, video, and source maps nobody needed to ship all land here.
2. Compute: serverless function invocations and duration, SSR rendering, middleware/edge execution, and image optimization requests.
3. Build minutes and concurrency: how long CI-style builds take and how many can run at once.
4. Seats: some plans charge per team member who can deploy, even if they only deploy once a month.

A static marketing site is dominated by item 1. A Next.js app with server components and personalised pages is dominated by item 2. A five-person agency with forty small sites is dominated by item 4. Pick the host that is cheapest on your dominant meter, not the one with the nicest free tier.

Takeaway: identify your dominant meter first; comparing plan sticker prices before that is comparing the wrong number.

How do the three differ on each meter?

The pattern is that Cloudflare monetises compute and add-on products rather than static egress, while Vercel and Netlify meter the delivery itself. That is why a viral image-heavy page can be a non-event on one and a surprise invoice on another.

Takeaway: if your site is mostly static assets and traffic is unpredictable, an unmetered-egress host removes the worst tail risk.

When does SSR or image optimization become the real cost?

This is where I have seen Next.js projects get caught. Rendering a page on every request means every visitor consumes compute, and image optimization means each unique width/format combination can be a billable transformation on hosts that meter it.

Before you migrate or upgrade, find out which routes are actually dynamic. In a Next.js project, the build output lists them:

# After `next build`, the route table marks each route.
# ○ = static, ● = SSG with data, ƒ = dynamic (server-rendered on demand)
npx next build 2>&1 | grep -E '^\s*(○|●|ƒ)'

Every ƒ route is a compute meter. Often a route is dynamic only because it reads cookies() or headers() somewhere in the tree, or because a fetch is uncached. Converting accidental dynamic routes to static or revalidated ones cuts the compute meter on every host, which is a bigger lever than switching providers.

For images, two honest options exist: keep the host's optimizer and cap the variants (a limited deviceSizes list in next.config.js), or pre-generate sizes at build time and serve them as plain static files. The second removes the meter entirely at the cost of a build step you maintain.

Takeaway: audit which routes are dynamic before blaming the host; accidental SSR is the most common avoidable compute cost.

How do I estimate my bill before I commit?

Do not trust intuition; plug your own numbers into a model with the rates from each pricing page. This small script makes the structure explicit. The rates are placeholders you must fill in yourself, deliberately not real prices.

from dataclasses import dataclass

@dataclass
class Plan:
    name: str
    base_monthly: float        # plan fee
    seats_included: int
    per_extra_seat: float
    gb_included: float
    per_extra_gb: float        # 0 if egress is unmetered
    fn_million_included: float
    per_extra_million_fn: float

def monthly_cost(p: Plan, seats: int, gb_out: float, fn_millions: float) -> float:
    extra_seats = max(0, seats - p.seats_included)
    extra_gb = max(0.0, gb_out - p.gb_included)
    extra_fn = max(0.0, fn_millions - p.fn_million_included)
    return (p.base_monthly
            + extra_seats * p.per_extra_seat
            + extra_gb * p.per_extra_gb
            + extra_fn * p.per_extra_million_fn)

# Fill from each vendor's current pricing page. These zeros are placeholders.
plans = [
    Plan("host_a", 0, 1, 0, 0, 0, 0, 0),
    Plan("host_b", 0, 1, 0, 0, 0, 0, 0),
]

# Run three scenarios: today, 3x traffic, and a viral spike month.
scenarios = {"today": (3, 200, 2), "3x": (3, 600, 6), "spike": (3, 5000, 10)}
for p in plans:
    for label, (seats, gb, fn) in scenarios.items():
        print(p.name, label, round(monthly_cost(p, seats, gb, fn), 2))

The scenario that matters is the spike month, not today. A host with a slightly higher base fee and unmetered egress often wins the spike scenario by a wide margin, while a host with generous bundled compute wins the dynamic-app scenario.

Takeaway: model today, 3x, and a spike month; the host that wins only "today" is the one that surprises you later.

Is it worth paying for the platform that matches my framework?

Sometimes. If you run Next.js with server components, ISR and middleware, the first-party host removes a class of "works locally, behaves differently deployed" problems, and that time has real value. If you ship a static Astro, Vite, or Hugo site, you are paying a premium for features you do not use, and an unmetered-egress host is the rational default.

Each option has a real downside. Vercel's per-seat pricing punishes teams where many people occasionally deploy, and its overages can arrive without a hard stop unless you configure spend controls. Netlify's pricing structure has been revised enough that older blog posts (including comparisons from a couple of years ago) are unreliable. Cloudflare Pages gives you the least friction on cost but, for framework-specific SSR features, you may hit behavioural differences from Node-based hosting because the runtime is not Node by default.

If you want the managed Next.js experience and accept the metering, Vercel is the host that handles SSR, ISR and image optimization without extra adapter work. If your risk is egress on a mostly static site, Cloudflare Pages is the one that does not bill you for serving static assets.

Takeaway: pay for framework fit only if you use the framework features that need it.

FAQ

Is Cloudflare Pages really free for unlimited bandwidth?

Static asset requests on Pages are not metered for bandwidth as of November 2026, but Pages Functions run on Workers and are subject to Workers request and CPU limits and pricing. Check the current limits for your plan.

Why is my Vercel bill higher than the plan price?

Usually usage beyond the included allowances (bandwidth, function duration, image optimization) or additional paid seats. Open the usage dashboard and sort by line item to see which one grew.

Can I move a Next.js app off Vercel to avoid costs?

Yes, but test every dynamic feature (middleware, ISR, image optimization) on the target host first, since adapters and runtimes do not always match Vercel's behaviour exactly.

Bottom line

Static or image-heavy sites with unpredictable traffic fit Cloudflare Pages, because egress is the risk and it is not metered there. Next.js teams that use SSR, ISR and middleware heavily will usually spend less engineering time on Vercel, as long as they set spend limits and count seats honestly. Netlify is worth a fresh look if you value its build and form tooling, but read its current pricing model rather than relying on older comparisons. Whatever you choose, audit your dynamic routes first; that fixes more of the bill than any migration.

Related reading

• Stop Guessing Your Webhook Dedup TTL: Derive It From the Delivery Contract
• Postgres as a Job Queue vs Redis vs SQS: When Does "Just Use Your Database" Stop Working?
• GitHub Push Rejected: "File Exceeds 100 MB" (GH001) — Fix It With filter-repo or LFS