Where a request enters the Edge Network

When a user hits your application, the first stop is the nearest Vercel Point of Presence (PoP). The Edge Network uses Anycast routing and continuously monitors endpoint health, speed, and user proximity to select the best PoP for each connection. After the Vercel Firewall performs initial evaluation and security checks, the request is linked to one of 18 globally distributed Edge Regions. Throughout the request lifecycle, the network dynamically reroutes traffic to redundant or failover systems as needed to maintain service.

Vercel's Edge Network routes requests from the nearest PoP to the closest compute-capable Edge Region, and when necessary to a developer-designated region closer to your backend.

Requests are enriched with contextual data—geolocation, secure environment variables, deployment and branch details—without adding latency. This information flows into Edge Middleware and Vercel Functions, enabling real-time decisions based on request and application awareness.

When a request becomes an Edge Request

Before a request counts as an Edge Request, it passes through platform defenses and any already-active Web Application Firewall (WAF) persistent actions. Only after clearing those filters does the request move into the WAF for full evaluation.

A request that passes system firewall rules and existing Web Application Firewall (WAF) persistent actions becomes an Edge Request and proceeds to the WAF for evaluation.

Every Edge Request serves one of two purposes: fetching data or triggering an event. Its characteristics depend on the payload, route, application, deployment, and client details such as cookies, user agents, and TLS fingerprints. These attributes determine bandwidth usage and what happens after the response is delivered.

Usage and optimization

  • Each Edge Request is processed in real time—covering static assets, dynamic API routes, and serverless functions.
  • Requests blocked by Vercel Firewall or WAF persistent actions do not count toward Edge Request totals.
  • Tracking Edge Requests reveals application demand and behavior patterns; each request consumes network resources, so optimizing frequency and type reduces costs.
  • The project's usage tab provides one-to-one tracking of each Edge Request.
  • Reducing unnecessary calls—via lazy loading, adjusting polling frequency, and batching related API requests—lowers request volume and overhead.
  • Monitor patterns using Vercel's analytics and developer tools to identify further optimization opportunities.

Fast Data Transfer: moving data at speed

Fast Data Transfer (FDT) describes the low-latency movement of data between the visitor's browser and the Edge Network. Supported by a broad network of PoPs and private fiber connections, FDT bypasses typical public internet bottlenecks to reduce Time to First Byte (TTFB) and Largest Contentful Paint (LCP).

Fast Data Transfer consists of two parts: incoming requests and outgoing responses, first recognized at the same point as Edge Requests.

FDT is measured by the volume of data transferred during a request, covering both inbound (user to Vercel) and outbound (Vercel to user) traffic. Higher data volumes affect both performance and usage costs.

Reducing payload size

  • Request and response headers in browser devtools show FDT activity and data transfer details.
  • Framework-level optimizations such as code-splitting, lazy loading, and tree-shaking help reduce payload sizes.
  • Vercel Image Optimization can significantly reduce the size of served images.
  • Vercel automatically compresses assets like images, JavaScript, and CSS, decreasing overall data size and improving page load times.

Inspecting requests with x-vercel-id

To trace how a request flows through the Edge Network, check the x-vercel-id header in HTTP responses. This header shows the Edge Region that handled the request and the region where functions (Edge or serverless) executed.

For example, a request from New York City might route to the nearest Edge Region iad1 (Washington, DC), while the function runs in sfo1 (San Francisco, CA) because it is closer to your backend origin. The x-vercel-id header would reflect both regions.

Every Vercel request has a unique ID that shows which Edge Regions processed it.

Points of Presence are not included in the x-vercel-id header.

Managing resource consumption

Every step of a request—routing, rendering, caching—reflects decisions shaped by user parameters and application logic. Tracking Edge Requests and Fast Data Transfer gives visibility into how resources are allocated based on your framework, allowing you to keep the application efficient and cost-effective while maintaining performance.