Do You Need Edge Functions? A CDN Is Enough for Most Sites

Legacies is an independent digital product brand based in Bucharest, Romania, founded by Horia Stan and Alexandru Tălnaci, and "do we need edge?" is one of the questions clients ask us most when they compare hosting plans. The word is on every pricing page, so it is fair to wonder.

Our answer, for most small business sites, is no. A static or mostly static site served through a CDN already delivers pages from servers close to your visitors. Edge functions only pay off when you run logic on almost every request for users spread across the world, and even then, where your data lives matters more than where your code runs.

Quick answer

• Landing pages and business sites: a static build behind a CDN is fast, cheap and simple. You do not need edge functions.
• Apps with logins, forms and a database: run the server in one region close to your database and your main users.
• Edge functions: use them for small, data-light tasks like redirects, geolocation or A/B routing, and only after you measure a real latency problem.
• 2026 update: Next.js deprecated its route-level edge runtime in version 16.3, and Vercel now recommends Node.js over edge for most functions.

What "edge" actually means

There are three different things hiding behind the word, and pricing pages tend to blur them.

A CDN copies files to data centers around the world. When someone in London opens your site, they get the page from a nearby location rather than from a server in another country. For content that does not change on every request, this already solves most of the latency problem.

Edge functions go one step further. They run your code in those same locations. That sounds strictly better, but it comes with constraints.

When edge functions actually help

For applications with global users and logic on every request, edge execution can make a real difference. Typical cases:

• Redirecting visitors by country or language before the page loads.
• Checking a session cookie and sending logged-out users to a login page.
• Splitting traffic for an A/B test without a client-side flicker.
• Serving personalized responses from data that is itself replicated globally.

The common thread: the work is small and does not need a round trip to one central database. When those conditions hold, running close to the user cuts real milliseconds.

Why edge is often an unnecessary complication

Your database is not at the edge

This is the part most marketing skips. If an edge function in Sydney has to query a database in Frankfurt, every query crosses the planet. Do that three or four times per page and the "fast" edge version is slower than a plain server sitting next to the database. Vercel's own edge runtime docs suggest setting a preferred region close to your data source for exactly this reason.

The runtime is limited

Edge runtimes are not full Node.js. According to the Next.js edge runtime reference, you cannot read or write the filesystem, calling require is not allowed, dynamic code evaluation is blocked, and packages that rely on native Node.js APIs will not work. ISR is not supported either. Many database drivers, PDF tools and image libraries fall into that gap.

Debugging gets harder

Logs scatter across regions, behavior differs slightly from local development, and size limits apply. On Vercel, an edge function is capped at 1 MB after compression on the Hobby plan and 2 MB on Pro. When something breaks at 11 p.m., you want fewer moving parts, not more.

What changed in 2026: the frameworks moved back to Node.js

If you build with Next.js, the question has partly answered itself.

• Next.js 16 replaced middleware.ts with proxy.ts, which runs on the Node.js runtime. The old middleware file is deprecated.
• In Next.js 16.3, export const runtime = 'edge' on pages and routes is deprecated. Node.js is the default, and the fix is to delete the line.
• Vercel's docs now say plainly that they recommend migrating from edge to Node.js for better performance and reliability. Both runtimes run on Vercel's Fluid compute, which reduces cold starts with bytecode caching and pre-warming.
• Even on Cloudflare, the OpenNext adapter runs Next.js apps on Workers using the Node.js runtime rather than the edge runtime.

So the industry direction is clear. Use full Node.js by default, put static content on a CDN, and keep edge logic for the few places it truly helps. We explain why we stay on Next.js through these changes in why we choose the Next.js App Router.

What it costs at the time of writing

Edge is not automatically expensive. For small projects it can be free. These figures come from the official pricing pages as of October 2026:

The bigger cost is rarely the invoice. It is the engineering time spent working around runtime limits, debugging region-specific issues, and keeping two execution models in your head. For a small business, that time is better spent on content and conversion.

What we actually do

The rule we always apply: do not add infrastructure for a problem you have not measured.

• Landing pages and presentation sites: static build, served through a CDN. Simple, fast, cheap.
• Applications with server logic like dashboards and forms with server-side validation: a Node.js server in one region close to the main user base and the database. Our own site runs as a Node.js server in Docker behind a reverse proxy, which is the setup the Next.js self-hosting guide recommends.
• Edge functions: only where we measure an actual latency problem, not preemptively.

How to measure before you decide

1. Check real user dataLook at Core Web Vitals in Google Search Console or PageSpeed Insights. If Largest Contentful Paint is already green for your main markets, edge will not move the needle.
2. Look at Time to First Byte by countryIf TTFB is high only for far-away visitors, and your pages are dynamic, you may have a distance problem. If it is high everywhere, the problem is your server or your code.
3. Find the slow partIs it the database query, a third-party API, large images or too much JavaScript? Most slow small sites we see have one of those, not a geography problem.
4. Fix the cheap things firstCaching, image optimization and removing heavy scripts are cheaper than a new architecture. Then measure again.

If you would rather not do this yourself, our Web Optimization service starts at 699 lei (about 130 EUR) and covers speed, technical SEO and accessibility, with a report of everything we fixed. You can start with our free website audit or see all options on our services page.

A useful website should feel fast because its architecture matches the job, not because it carries an expensive label. That is also why we keep infrastructure out of the conversation when someone asks how much a business website costs. Most of the time, the boring setup wins.

When to handle it yourself vs bring someone in

Handle it yourself if your site is mostly static, your hosting already includes a CDN, and your Core Web Vitals are green. In that case, there is nothing to do except keep things updated.

Bring someone in if your app is slow for real users and you cannot tell why, you are planning to serve customers on several continents, or a hosting provider is pushing you toward edge features you do not understand. A few hours of measurement usually costs less than a month of the wrong architecture. And whatever you run, keep it patched. We cover that in our post on Next.js security patches.

Frequently Asked Questions

Do I need edge computing for my small business website?

Probably not. If your site is mostly static, a CDN already serves it from locations near your visitors, which handles most of the speed benefit. Edge functions make sense when you run logic on nearly every request for users spread across many countries, and only after you have measured a real latency problem.

What is the difference between a CDN and edge functions?

A CDN caches and serves files like HTML, images and scripts from data centers around the world. Edge functions run small pieces of your own code in those same locations. A CDN speeds up content delivery, while edge functions move logic closer to users, with limits on what that code can do.

Is the Next.js edge runtime deprecated?

Yes. As of Next.js 16.3, setting runtime to edge on pages and route handlers is deprecated, and Node.js is the default. Next.js 16 also replaced middleware with proxy, which runs on Node.js. Vercel now recommends migrating functions from edge to Node.js.

Are edge functions faster than serverless functions?

Only for some workloads. Edge functions start quickly and run close to the user, so small tasks like redirects can be faster. But if the function needs a database in one region, every query travels that distance, and a regional serverless function next to the database is often faster overall.

How much do edge functions cost?

At the time of writing, Cloudflare Workers has a free tier with 100,000 requests per day, and the paid plan starts at 5 USD per month with 10 million requests included. Vercel's free Hobby plan is for non-commercial use, and Pro starts at 20 USD per month. For small sites, engineering time usually costs more than the hosting bill.

What should I fix first if my website feels slow?

Start with measurement. Check Core Web Vitals and Time to First Byte, then look at the usual suspects: large images, heavy JavaScript, slow database queries and third-party scripts. Fixing those is cheaper than changing your infrastructure, and it usually solves the problem.