Reducing Latency with Netlify Edge Functions: When to Move Logic to the Edge

The Latency Gap in Traditional Serverless

When you use a standard serverless function (like those based on AWS Lambda), the request travels from the user to a specific data center region, executes, and returns. If your user is in Tokyo but your function is hosted in us-east-1, you introduce significant network latency before a single line of code even runs. This is particularly problematic for tasks that must happen before the page renders, such as authentication checks or A/B test bucket assignments.

The solution is to move that logic to the network edge. Netlify Edge Functions use the Deno runtime to execute code at the point of presence (PoP) closest to the user, intercepting the request before it ever hits the origin server or the CDN cache.

Interception vs. Execution

It is important to distinguish between a standard Netlify Function and an Edge Function. A standard function is a destination; a user requests /api/get-data, and the function responds. An Edge Function is an interceptor. It sits in the request pipeline, allowing you to inspect the request, modify it, or return a response immediately without the request ever reaching the main site assets.

Common Use Cases for Edge Logic

• Geolocation Redirects: Sending users to a country-specific version of a site based on their IP address.
• A/B Testing: Assigning a cookie to a user and serving a different HTML version without a client-side flicker.
• Security Headers: Injecting custom security headers into every response globally.
• Authentication Guards: Checking for a valid JWT in a cookie before allowing access to a protected route.

Implementation: Geolocation-Based Content

To implement an Edge Function, you must place your logic in the netlify/edge-functions directory. Because these functions run on Deno, you use standard Web APIs (Request, Response) rather than Node.js-specific modules.

The following example demonstrates how to intercept a request and redirect a user based on their geographic location. This code should be placed in netlify/edge-functions/geo-redirect.ts.

import { Context } from "@netlify/edge-functions";

export default async (request: Request, context: Context) => {
  // Access the geo data provided by Netlify's edge network
  const country = context.geo().country;

  // Redirect UK users to a specific landing page
  if (country === "GB") {
    return Response.redirect("https://uk.example.com", 302);
  }

  // Otherwise, let the request proceed to the origin site
  return context.next();
};

Deployment and Verification:
1. Deploy the code via your Git provider to Netlify.
2. Configure the function to run on specific paths in your netlify.toml file (e.g., edge_functions = [ { \"path = \"/*\", \"function = \"geo-redirect\" } ]).
3. Use a VPN or a tool like curl with a spoofed location to verify the redirect.
4. Check the Location header in the browser's Network tab to ensure the 302 redirect is triggering correctly.

Trade-offs and Runtime Constraints

Edge Functions are not a wholesale replacement for standard serverless functions. They operate under a more restrictive environment to maintain the speed that makes them useful.

The primary limitation is the memory and execution time. If your logic requires heavy computation, large libraries, or long-running database queries, an Edge Function will likely time out or exceed memory limits. These are designed for request manipulation, not heavy processing.

Checking for Success

To verify your Edge Function is working as intended without relying solely on visual cues, use the curl command to inspect headers. If you are injecting a custom header via an Edge Function, run:

curl -I https://your-site.netlify.app

Look for your specific custom header in the output. If the header is missing, check the Netlify deploy logs to ensure the function didn't crash during the Deno compilation phase. If the function is active but not triggering, verify that your netlify.toml path patterns correctly match the incoming request URL.