Edge computing is a distributed computing paradigm that moves data processing, application logic, and storage capabilities away from centralised data centres and toward the edges of the network, locations physically close to the users and devices that generate and consume the data being processed. Rather than sending every computation to a distant central server edge computing performs processing at the nearest available node, reducing the distance data must travel and therefore reducing latency, bandwidth consumption, and dependence on central infrastructure.

The edge in edge computing refers to the periphery of the network, the boundary where users’ devices connect to the internet infrastructure. A traditional web application centralises all computation in a data centre that may be thousands of miles from many of its users, every request travels from the user’s device to the data centre and back. Edge computing distributes computation to nodes positioned at or near points of network access, internet exchange points, mobile network towers, CDN points of presence, so that processing happens close to where requests originate.

Edge computing represents a fundamental architectural shift in how web applications are built and deployed, not merely an optimisation of existing centralised approaches but a rethinking of where computation should occur. For static content delivery CDNs have provided edge distribution for decades. Edge computing extends this distribution to application logic, enabling code to execute at edge locations rather than only serving pre-computed cached content from them.

For redirect management edge computing is transformative, executing redirect rules at edge nodes near users produces redirect responses in tens of milliseconds rather than the hundreds of milliseconds required when requests must travel to centralised origins. Modern redirect management platforms built on edge computing infrastructure provide globally consistent, low-latency redirect responses regardless of where users are located.

The evolution from CDN to edge computing

Understanding how edge computing evolved from earlier CDN technology clarifies what edge computing adds beyond content distribution.

First generation CDNs, static content caching: early CDNs like Akamai, founded in 1998, distributed static content across geographically dispersed servers. HTML pages, images, CSS, and JavaScript files were cached at edge servers near users, reducing latency for content delivery. The edge served only pre-computed content, dynamic requests requiring computation still went to the origin server.

This first-generation edge model improved content delivery performance significantly but left dynamic content generation at the origin. For requests requiring computation, user authentication, personalisation, database queries, redirect rule evaluation, the request still needed to reach the origin with its associated latency.

Second generation, edge logic: as CDN infrastructure became more sophisticated operators added programmable capabilities at the edge. Akamai EdgeSuite, Fastly VCL, Varnish Configuration Language, and similar technologies allowed limited request manipulation at the edge, header modification, simple routing decisions, URL rewriting. These capabilities were more powerful than pure content caching but still limited compared to full application programming.

Modern edge computing, serverless at the edge: Cloudflare Workers, Fastly Compute@Edge, AWS Lambda@Edge, Deno Deploy, and similar platforms represent the current generation, full-featured serverless execution at edge nodes. Developers write application code in JavaScript, TypeScript, Rust, or other languages and deploy it to edge infrastructure. The code executes at edge nodes near users with the same capabilities as origin server code, making HTTP requests, reading and writing data stores, implementing complex business logic.

This programmable edge enables complete application architectures where the origin server is optional, edge functions can serve all requests, accessing edge-colocated data stores without any origin involvement for many request types.

How edge computing works

Edge computing infrastructure consists of distributed compute nodes, data stores, and networking capabilities positioned at locations near users.

Edge nodes: the physical or virtual machines at edge locations where edge functions execute. An edge node at a major internet exchange point, Frankfurt, London, Singapore, New York, handles requests from users in that region. Edge nodes run the runtime environments for edge functions, V8 isolates for Cloudflare Workers, WebAssembly runtimes for Fastly Compute@Edge, alongside caching infrastructure and networking components.

Edge nodes must handle massive request volumes with minimal latency, the infrastructure is optimised for fast request handling at extreme scale. A single Cloudflare edge server handles millions of requests per day from many different customer applications executing simultaneously in isolated sandboxes.

Edge function deployment: when a developer deploys an edge function the code is distributed to all edge nodes globally, or a configured subset. Deployment propagation is fast, seconds to minutes for complete global distribution. A function deployed from a developer’s laptop is executing at edge nodes on six continents within minutes. This instant global deployment is one of edge computing’s most operationally valuable characteristics, updates to redirect rules, security configurations, and application logic propagate worldwide immediately.

Edge data stores: compute without data access is limited. Edge computing platforms provide data storage accessible from edge functions with low latency. Cloudflare KV: eventually consistent key-value storage, replicates data to all edge locations. Cloudflare Durable Objects, strongly consistent stateful objects. Fastly Edge Dictionaries, configuration data at the edge. These edge-colocated data stores enable edge functions to access application data without origin round trips.

Networking at the edge: edge nodes connect to each other and to origin servers through optimised backbone networks. Cloudflare’s Argo Smart Routing uses real-time network measurements to route requests between edge nodes and origins through the fastest available network paths, reducing origin round-trip times for requests that must reach the origin.

Edge computing use cases

Edge computing enables a wide range of use cases, each exploiting the latency advantages of processing near users.

Redirect management: the most directly relevant use case for this glossary. Redirect rules executed at edge nodes return redirect responses from the nearest edge location, tens of milliseconds from any user globally. A redirect from old-domain.com/page to new-domain.com/page processed at a Cloudflare edge node in Singapore responds to a Singapore-based user in 15-25ms. The same redirect processed at a US-based origin server responds in 250-350ms. Edge redirect execution eliminates the latency of cross-ocean or cross-continent origin round trips.

Personalisation at the edge: serving personalised content variations at the edge without origin involvement. An edge function reads a user identifier from a cookie, looks up the user’s preferences in edge KV storage, and selects the appropriate content variant, returning the personalised response without the latency of an origin database query. Edge personalisation reduces time to first byte for personalised content from hundreds of milliseconds to tens of milliseconds.

Authentication and access control: verifying authentication tokens at the edge before forwarding requests to the origin. An edge function validates a JWT, JSON Web Token, checks the token’s signature and claims, and either forwards the authenticated request or returns a 401 Unauthorized response. Authentication at the edge reduces origin load, unauthenticated requests are rejected before reaching the origin, and improves response time for authentication failures, edge rejection is faster than origin rejection.

A/B testing and feature flags: splitting traffic between content variants at the edge. An edge function randomly assigns users to test groups, storing the assignment in a cookie, and routes requests to different origin backends or modifies responses to reflect different feature states. Edge A/B testing eliminates the flicker, brief flash of one variant before switching to another, that occurs when A/B logic runs client-side in JavaScript after the page loads.

Bot detection and management: identifying and managing automated traffic at the edge before it reaches the origin. Edge functions analyse request characteristics, User-Agent headers, request patterns, IP reputation, and challenge or block suspicious traffic. Bot management at the edge protects origin servers from bot-generated load.

Geo-based routing: routing users to region-specific content based on their geographic location as determined by their IP address. Edge functions have access to geographic data, country, region, city, for each connecting user. Routing to localised content, complying with data residency requirements, or serving region-appropriate content all happen at the edge without origin involvement.

Image optimisation: transforming images at the edge, resizing, reformatting, compressing, to serve appropriately sized images to each device. An edge function reads the requesting device’s capabilities from request headers, Accept header indicating WebP support, viewport size from client hints, and returns an optimised version of the requested image from edge storage.

Edge computing and web performance

Edge computing’s performance benefits extend beyond simple latency reduction, it affects multiple dimensions of web performance.

Time to first byte reduction: the most direct performance benefit. Time to first byte, TTFB, measures the time from a browser sending a request to receiving the first byte of the response. Processing requests at edge nodes near users dramatically reduces TTFB, the geographic component of TTFB shrinks from hundreds of milliseconds to tens of milliseconds. Lower TTFB improves Google’s Largest Contentful Paint, a direct Core Web Vitals ranking signal.

Origin load reduction: edge computing processes requests that would otherwise reach the origin, redirect responses, authentication checks, cached content. Origin load reduction has cascading benefits, origins handle fewer requests, individual requests receive more processing capacity, and origins can be sized for actual dynamic content generation rather than total request volume. Reduced origin load improves origin response times for requests that do reach the origin.

Bandwidth reduction: edge processing eliminates bandwidth consumption for requests handled entirely at the edge. A redirect response returned from an edge node does not consume bandwidth on the network segment between the edge and the origin. For high-volume redirect traffic, a brand protection domain redirecting thousands of visits per day, edge execution eliminates all origin-bound bandwidth for those requests.

Global performance consistency: without edge computing performance varies dramatically by user location, users near the origin have fast experiences while distant users have slow experiences. Edge computing provides consistent performance globally, every user benefits from nearby edge processing regardless of where the origin is located. Consistent global performance is measurable in SEO rankings, search engines assess performance from multiple geographic locations and reward consistent global performance.

Edge computing platforms

Several platforms provide edge computing infrastructure, each with different language support, capabilities, pricing, and appropriate use cases.

Cloudflare Workers: the most widely adopted edge computing platform. JavaScript and TypeScript with WebAssembly support. V8 isolate execution with sub-millisecond cold starts. Global deployment to 200+ edge locations. Integrated with Cloudflare KV, Durable Objects, R2 storage, and Cloudflare’s CDN and security infrastructure. Workers power many redirect management platforms, providing the edge execution infrastructure on which redirect rule processing runs.

Fastly Compute@Edge: Fastly’s edge computing platform supporting Rust, JavaScript, and AssemblyScript compiled to WebAssembly. WebAssembly execution provides strong performance and language flexibility. Fastly’s network is particularly strong for media delivery and real-time applications requiring low latency.

AWS Lambda@Edge: Amazon’s edge computing capability integrated with CloudFront CDN. Supports Node.js and Python. Executes at CloudFront edge locations, fewer locations than Cloudflare or Fastly. Higher cold start times than Worker-based platforms, container-based execution rather than isolates. Well-suited for organisations already using AWS infrastructure.

Vercel Edge Functions: edge computing integrated with Vercel’s deployment platform. JavaScript and TypeScript using the Web APIs standard. Optimised for Next.js applications. Vercel’s edge functions power middleware, request interception for authentication, redirects, and personalisation, in Next.js applications.

Deno Deploy: Deno’s edge computing platform. TypeScript-first with Deno’s security model. Executes at edge locations globally. Smaller network footprint than Cloudflare but growing. Native TypeScript support without compilation step.

Netlify Edge Functions: Netlify’s edge computing capability. Deno-based execution at edge locations. Integrated with Netlify’s static site and JAMstack deployment platform. Appropriate for Netlify-hosted sites requiring edge logic.

Edge computing and SEO

Edge computing affects SEO through performance improvements and through the specific ways edge-executed redirect responses interact with search engine processing.

Core Web Vitals at the edge: Google’s Core Web Vitals ranking signals, particularly Largest Contentful Paint, are directly affected by server response time. Edge computing reduces server response time by processing requests near users rather than at distant origins. Improved TTFB from edge processing translates to improved LCP scores, a direct ranking benefit for sites using edge computing.

Crawl budget optimisation: Googlebot crawls from Google’s infrastructure, primarily US-based. Edge computing does not directly reduce Googlebot’s crawl latency unless Google crawls from geographically distributed infrastructure. However edge-executed redirect responses are SEO-equivalent to origin-executed redirects, the HTTP response is identical from Google’s perspective regardless of where it was generated.

Redirect signal consistency: edge-executed 301 permanent redirects carry the same link juice transfer and index update signals as origin-executed 301s. Search engines evaluate the HTTP response, status code and Location header, not the infrastructure that generated it. Edge redirect execution provides performance benefits without affecting the SEO properties of redirect responses.