Edge Computing with Next.js: Where It Helps vs. Hurts

Edge computing is one of those technologies that sounds revolutionary in blog posts and conference talks but gets complicated quickly in production. After running Next.js applications on the edge across several products, I've a practical perspective on where it genuinely helps, where it does not, and what tradeoffs you should expect.

The short version: edge computing is excellent for specific use cases and actively counterproductive for others. Knowing the difference saves you from rewriting code that was perfectly fine running in a single region.

What Edge Computing Means in Practice

In the Next.js ecosystem, "edge computing" means running server-side code on Vercel's Edge Network, a global network of servers close to users rather than a single-region Node.js server. When a user in Tokyo requests a page, the edge function runs in Tokyo, not in Virginia.

The primary benefit's latency. A function running 50ms away from the user instead of 200ms away means faster page loads, faster API responses, and a snappier user experience.

The primary constraint is the runtime environment. Edge functions run on a lightweight JavaScript runtime (similar to Web Workers), not full Node.js. This means no access to Node.js-specific APIs, limited package compatibility, and tighter memory and execution time limits.

Where I Actually Use Edge

Middleware

This is the killer use case for edge computing in Next.js. Middleware runs on every request before it reaches your route handlers, and running it at the edge means it executes close to the user with minimal latency overhead.

I use edge middleware across my products for:

Geolocation-based routing. Several of my products serve users in multiple countries. Edge middleware reads the user's location from request headers and routes them to the appropriate localized experience. This happens in under 5ms at the edge versus 50-100ms if I had to round-trip to a central server.

Authentication checks. Verifying a JWT token and redirecting unauthenticated users doesn't require a database lookup. Edge middleware can verify token signatures, check expiration, and redirect, all without leaving the edge node.

Bot detection and rate limiting. Basic request filtering (blocking known bad user agents, enforcing rate limits on API endpoints) is perfectly suited for edge execution. The faster you can reject bad traffic, the less load on your origin servers.

Static Page Personalization

Some of my product pages are mostly static but need minor personalization: different pricing based on region, different CTAs based on whether the user is signed in, different content based on language preference.

Edge functions can inject this personalization at the edge without sacrificing the performance benefits of static generation. The page is cached at the edge, and the function adds the personalized elements on top.

API Response Caching

For API routes that return data that changes infrequently, edge caching is powerful. The first request hits the origin, but subsequent requests from the same region are served from the edge cache with near-zero latency.

I use this pattern for reference data APIs in my aviation products. Airport data, aircraft specifications, aviation regulatory information: this data changes rarely but is requested frequently. Serving it from edge cache cuts response times by 80-90%.

Where I Do Not Use Edge (and Why)

Database-Heavy Operations

Most of my route handlers query MongoDB. MongoDB connections don't work well from edge functions for two reasons:

First, the edge runtime doesn't support the full MongoDB driver, so you need HTTP-based database access like MongoDB Atlas Data API or a REST wrapper. These work but are slower than a direct connection from a co-located server.

Second, the latency advantage of edge disappears when the function has to round-trip to a database in a single region anyway. If my database is in us-east-1, an edge function in Tokyo still has to reach us-east-1 for the data. The user sees edge-level latency for the request, but the total response time is dominated by the database round-trip.

For database-heavy routes, I use standard serverless functions co-located with my database. The function-to-database latency is 1-2ms, which more than compensates for the slightly higher user-to-function latency.

AI API Calls

My AI-powered products like ClickAi make calls to the Claude API. These calls are latency-dominated by the model inference time (seconds, not milliseconds), so running the route handler at the edge versus in a single region makes no perceptible difference to the user experience.

The Claude API also streams responses, and stream handling at the edge introduces complexity without benefit. I keep all AI route handlers on standard serverless functions.

Complex Business Logic

Edge functions have tighter memory and execution time limits than standard serverless functions. Complex operations (document generation, data transformation, batch processing) can bump against these limits.

I learned this the hard way when a document generation route in one of my products started timing out at the edge. Moving it to a standard function with higher limits solved the problem immediately.

The Decision Framework

After running edge functions in production for over a year, here is my decision framework:

Use edge when:

• The operation is fast (under 50ms of compute)
• It doesn't require a database connection or the data can be cached
• Latency directly impacts user experience (middleware, page personalization)
• The code runs on the edge runtime without modification

Use standard serverless when:

• The operation queries a database
• The operation calls external AI APIs
• The operation requires significant compute or memory
• The code uses Node.js-specific APIs or packages

Use static generation when:

• The content is the same for all users (or varies only by a few dimensions)
• The data changes infrequently

Most of my routes, probably 70%, run on standard serverless functions. About 20% are statically generated. Only about 10% actually benefit from edge execution. That ratio surprises people who assume edge should be the default, but it reflects the reality that most web application work involves database queries and complex logic that edge isn't designed for.

Practical Tips

Test at the edge early. If you think a route might benefit from edge execution, try it early. Discovering that a dependency doesn't work on the edge runtime after you have built the entire feature is painful.

Measure actual latency. Do not assume edge is faster. Measure response times for real users with and without edge execution. If the route hits a database in us-east-1, the edge version might actually be slower for users in us-east-1 due to the overhead of the edge runtime.

Use the runtime export. Next.js makes it easy to specify the runtime per route. Use export const runtime = 'edge' only where it makes sense, and leave everything else on the default Node.js runtime.

Cache aggressively at the edge. The biggest wins from edge computing often come from caching rather than edge execution itself. A cached response served from the edge at 5ms beats any function execution.

Edge computing is a powerful tool in the Next.js toolkit. But like any tool, it's most effective when used for the problems it was designed to solve, not applied indiscriminately to everything.