Bandwidth is the maximum rate at which data can be transferred across a network connection, measured in bits per second and expressed in units of kilobits per second, Kbps, megabits per second, Mbps, or gigabits per second, Gbps. A network connection with 100 Mbps bandwidth can transfer a maximum of 100 megabits of data every second, enabling a 100 megabyte file to be transferred in approximately 8 seconds under ideal conditions.

The word bandwidth is borrowed from signal processing, where it describes the range of frequencies a signal can carry. In networking the analogy is apt, a higher-bandwidth connection carries more data simultaneously, just as a wider-frequency signal carries more information. A narrow pipe constrains how much water flows through it regardless of the pressure, a low-bandwidth connection constrains data transfer regardless of how fast the servers at each end can process it.

Bandwidth is one of two fundamental performance dimensions of network connections, the other being latency. Where latency measures the delay before data transfer begins, how long until the first bit arrives, bandwidth measures the rate of data transfer once it has begun, how quickly subsequent bits arrive. Both dimensions independently affect user experience and both must be considered when designing and evaluating web infrastructure.

For redirect management bandwidth is relevant because redirects reduce the bandwidth demands on origin infrastructure, redirect responses are tiny, a few hundred bytes, compared to full page responses. A redirect management platform that handles redirect responses at the edge consumes minimal bandwidth at the origin, the small redirect responses are served entirely from edge infrastructure. Understanding bandwidth helps explain the scalability economics of redirect infrastructure and why high-volume redirect traffic is inexpensive to serve compared to full page content.

Bandwidth vs latency

The distinction between bandwidth and latency is fundamental, confusing them leads to misdiagnosis of performance problems and inappropriate optimisation choices.

Different bottlenecks: bandwidth and latency create different types of performance problems. High latency makes connections feel sluggish for interactive use, every request waits a long time before any response arrives. Low bandwidth makes large file transfers slow, data arrives eventually but at a trickle. A connection can have high bandwidth and high latency, a satellite link that transfers data quickly once started but has a 600ms round-trip time, or low bandwidth and low latency, a slow but responsive local network connection.

Interactive vs bulk transfer: the relative importance of bandwidth and latency depends on the use case. Interactive web browsing is more sensitive to latency, each user action triggers a request-response cycle and the delay before the response begins is what users notice. Large file downloads are more sensitive to bandwidth, once the download starts users care about how fast data arrives not about the initial delay.

Web page loading: web page loading is affected by both. Latency affects the time before content begins to arrive, the time to first byte. Bandwidth affects how quickly the content transfers once it begins arriving, particularly for pages with many large resources, high-resolution images, large JavaScript bundles, video content. Modern web performance optimisation addresses both, edge networks reduce latency, compression and efficient formats reduce bandwidth requirements.

The bandwidth-delay product: a derived metric that captures the interaction between bandwidth and latency. The bandwidth-delay product, measured in bits, represents the amount of data that can be in transit simultaneously on a connection. A 100 Mbps connection with 100ms RTT has a bandwidth-delay product of 10 megabits, 10 megabits of data can be in flight simultaneously. Large bandwidth-delay products require large TCP receive windows, a TCP protocol parameter, to achieve full utilisation of the available bandwidth. Connections with high bandwidth and high latency, satellite links, require careful TCP tuning to achieve good throughput.

Types of bandwidth in web infrastructure

Bandwidth appears at several layers of web infrastructure, each with different implications for performance and cost.

Network link bandwidth: the raw data carrying capacity of a physical network link. A data centre server connected to a 10 Gbps network switch can transfer up to 10 gigabits per second to and from the data centre network. Servers connected to 1 Gbps links are limited to 1 gigabit per second of total throughput, the sum of all incoming and outgoing traffic combined cannot exceed this limit.

Most web server workloads do not saturate network link bandwidth, a typical web server handling thousands of requests per minute with average response sizes of 50 kilobytes transfers only a few megabits per second, well within the capacity of a 1 Gbps link. High-traffic media serving, video streaming, large file downloads, can approach or saturate network link bandwidth for busy servers.

CDN bandwidth: CDN providers measure bandwidth usage across their edge networks, the total data transfer rate across all edge nodes serving a customer’s traffic. CDN bandwidth pricing is typically measured in gigabytes of data transferred per month, or as a peak bandwidth measurement in Gbps. CDN bandwidth costs vary by provider and by region, bandwidth in North America and Europe is typically less expensive than bandwidth in Asia-Pacific or Latin America.

Cloudflare’s business model, charging flat fees rather than per-bandwidth fees, differs from most CDN providers who charge per gigabyte transferred. This pricing model makes Cloudflare particularly attractive for high-bandwidth applications, video, software downloads, where bandwidth costs can otherwise be substantial.

Origin server bandwidth: the bandwidth consumed by traffic that reaches the origin server rather than being served from CDN cache or edge functions. Minimising origin bandwidth is a cost and performance objective, traffic served from CDN cache or edge functions does not consume origin bandwidth. High CDN cache hit rates reduce origin bandwidth proportionally, a 95% cache hit rate means only 5% of total traffic consumes origin bandwidth.

Redirect management platforms built on edge infrastructure, where redirect responses are served entirely from edge nodes, consume essentially zero origin bandwidth for redirect traffic. The tiny redirect responses, a few hundred bytes each, are generated at edge nodes from redirect rule data without any origin server involvement.

Egress bandwidth: data transferred from servers to clients, the outbound direction. Egress bandwidth is the primary bandwidth cost in cloud infrastructure, most cloud providers charge significant fees for data transferred out of their networks. AWS, Google Cloud, and Azure all charge per-gigabyte for egress bandwidth, making high-volume data serving from cloud origins expensive.

CDN deployment reduces egress bandwidth costs, data served from CDN edge caches is charged at CDN rates, typically lower than cloud origin egress rates, and frequently-accessed content is served from cache without any origin egress. Cloudflare R2 storage eliminates egress fees entirely for data served through Cloudflare’s network, a significant cost advantage for high-bandwidth content.

Bandwidth and redirect management

Redirect management has a distinctive bandwidth profile, redirect responses are extremely small compared to full page responses, making bandwidth a non-issue for redirect serving at essentially any scale.

Redirect response size: an HTTP redirect response consists of a status line, a small number of response headers, and an empty body. A typical 301 permanent redirect response:

HTTP/2 301
Location: https://new-destination.com/path
Cache-Control: max-age=86400
Content-Length: 0

HTTP/2 301
Location: https://new-destination.com/path
Cache-Control: max-age=86400
Content-Length: 0

HTTP/2 301
Location: https://new-destination.com/path
Cache-Control: max-age=86400
Content-Length: 0

The total size of this redirect response, including HTTP/2 framing overhead, is approximately 150-300 bytes. Compare this to a typical HTML page response, 50-200 kilobytes, or an image, 100 kilobytes to several megabytes. A redirect response is 200 to 10,000 times smaller than the content it redirects to.

Bandwidth cost calculation: 1 million redirect responses at 300 bytes each consume 300 megabytes of bandwidth, approximately 0.3 gigabytes. At typical CDN bandwidth rates of $0.01-0.08 per gigabyte this is a bandwidth cost of $0.003-0.024, effectively negligible. Even 1 billion redirect responses per month consume only 300 gigabytes, a few dollars at CDN rates.

This tiny bandwidth footprint means bandwidth is never a scaling constraint for redirect management, the relevant scaling dimensions are request processing rate, how many requests per second the redirect infrastructure can handle, and rule lookup latency, how quickly redirect rules can be evaluated. Both are addressed by edge computing architecture rather than bandwidth provisioning.

Reducing origin bandwidth through edge redirects: for sites with significant redirect traffic, domain migration redirects receiving thousands or millions of redirects daily, serving redirects at the edge eliminates the origin bandwidth that would otherwise be consumed forwarding these requests to the origin and receiving origin responses. The bandwidth saving is modest, redirect responses are small, but the reduction in origin request processing load is substantial.

Bandwidth for redirect rule synchronisation: redirect management platforms that store rules in globally distributed edge data stores, Cloudflare KV, Fastly Edge Dictionaries, consume bandwidth synchronising rule updates across edge locations. Adding or modifying a redirect rule propagates the change to all edge locations, each receiving the updated rule data. For typical redirect rule sizes, a few hundred bytes per rule, synchronisation bandwidth is negligible even for large redirect portfolios with thousands of rules.

Bandwidth measurement and monitoring

Understanding actual bandwidth usage requires measurement tools and monitoring infrastructure, different from latency measurement which focuses on response times.

Server-side bandwidth monitoring: web servers and load balancers record bytes transferred for each request, the sum across all requests gives total bandwidth consumption. Nginx logs include the bytes sent field, the size of each response body. Apache logs include similar data. Aggregating these logs provides daily and monthly bandwidth totals.

Cloud providers and hosting platforms expose bandwidth metrics through monitoring dashboards, AWS CloudWatch bandwidth metrics, Cloudflare Analytics bandwidth reports. These platform-level metrics provide aggregate bandwidth data without requiring log analysis.

CDN analytics: CDN platforms provide bandwidth analytics showing total data transfer, cache hit rates, the proportion of traffic served from cache, and origin bandwidth. Cache hit rate is the key bandwidth efficiency metric, higher hit rates mean more traffic served from CDN cache and less origin bandwidth consumption. Most CDN analytics dashboards show bandwidth trends over time, daily, weekly, monthly, enabling capacity planning and cost forecasting.

Network-level bandwidth testing: tools like iperf measure raw network link bandwidth, useful for verifying that servers are not constrained by network connectivity. Speedtest measures bandwidth between a test client and test servers at various locations, providing a consumer perspective on network performance. These tools measure available bandwidth rather than actual utilisation.

Bandwidth optimisation techniques

Reducing bandwidth consumption improves performance, particularly for users on low-bandwidth connections, and reduces infrastructure costs.

Compression: the most universally applicable bandwidth optimisation. HTTP compression, gzip or Brotli, compresses response bodies before transmission. Text content, HTML, CSS, JavaScript, JSON, typically compresses to 20-30% of its original size, reducing bandwidth consumption by 70-80%. Web servers and CDNs compress responses automatically when clients indicate compression support through the Accept-Encoding request header. Brotli compression achieves better compression ratios than gzip, particularly for text content, at the cost of higher CPU usage for compression.

Image optimisation: images typically constitute the largest portion of page bandwidth for content-heavy pages. Serving appropriately sized images, not larger than what the display requires, reduces bandwidth proportionally. Modern image formats, WebP, AVIF, achieve significantly better compression than JPEG and PNG, reducing image bandwidth by 25-50%. Lazy loading, deferring offscreen images until they are needed, reduces initial page bandwidth by loading only visible images immediately.

HTTP/2 and HTTP/3 header compression: HTTP/2’s HPACK header compression and HTTP/3’s QPACK compression reduce the bandwidth consumed by HTTP headers. Repeated headers, User-Agent, Accept, Cookie, across multiple requests to the same server are compressed using a shared dynamic table, sending only the difference from previously transmitted headers rather than the full header values.

Cache-Control and browser caching: resources cached in browser storage are served without any network transfer, zero bandwidth consumption for cached assets. Aggressive caching of static assets, versioned CSS, JavaScript, fonts, images, eliminates repeat bandwidth costs for returning visitors. Properly configured cache headers reduce total bandwidth consumption over time as users build local caches of site assets.