CDN Benchmark: North America Performance Deep Dive

In North America, a 15 ms p50 edge RTT advantage often disappears into noise by p99, where last-mile queueing, metro mis-steering, and handshake pathologies can add 80 to 200 ms before the first useful byte lands. That is the practical problem behind every serious CDN performance benchmark: providers that look interchangeable on median latency can diverge sharply under packet loss, cache miss pressure, and cross-border traffic between the US and Canada. Naive CDN speed test comparisons miss this because they flatten geography, ignore percentile behavior, and treat cacheable and miss-driven traffic as the same workload.

Why a CDN performance benchmark in North America usually lies

The North America story is not one region. It is at least four distinct performance domains: dense US east metros, US west long-haul corridors, central interior eyeball networks with thinner peering options, and Canadian paths where metro proximity does not guarantee shortest data path. A provider can win New York, lose Dallas under congestion, and degrade badly on Toronto to US-origin cache fill while still looking fine in a blended average.

That is why a useful cdn performance benchmark has to separate three things: edge selection quality, transport behavior under mild loss, and cache efficiency under realistic object distributions. If you only measure warm-cache single-object fetches from a handful of public probes, you are mostly benchmarking DNS steering and anycast luck.

What actually shifts the result

Across North American traffic, the variables that move user-perceived latency are usually not the ones vendors lead with. The biggest movers are edge misallocation inside the same country, TCP or QUIC behavior when packet loss climbs above roughly 0.5% to 1%, shield-to-origin distance on misses, and cache key fragmentation caused by headers, query normalization mistakes, and tokenized URLs.

QUIC helps, but only when the path and deployment are clean. The transport still has anti-amplification limits before address validation, padded Initial packets, and handshake loss failure modes that can deadlock or at least delay setup in ways that are very visible on cold sessions. In other words, protocol choice reduces latency variance only after routing and cache topology are already sane.

North America CDN benchmark data: what public measurements say

As of 2026, public benchmark data is directionally useful but easy to misuse. CDNPerf remains one of the better public comparators for broad provider-level latency and uptime views because it exposes regional benchmarking and real-time latency testing from distributed locations. Its value is relative ranking, not absolute truth, because probe mix, test object characteristics, and timing windows are outside your control.

Public internet quality datasets from large test networks show the same cautionary pattern. North American idle latency often looks healthy in aggregate, but loaded latency distribution expands significantly under access-network pressure. That matters because a provider that wins on unloaded RTT can still lose on real page and segment delivery if it lands users on more congested paths or relies on more distant cache fill for misses.

Older APNIC work on CDN measurement remains useful because the methodology problem has not changed: random probe placement, ISP mix, and statistical significance can dominate small ranking differences. Another APNIC result is more operationally interesting for architects: improving edge selection with bidirectional anycast and unicast probing cut median latency in one large deployment from 40 ms to 16 ms in some user regions. That is a reminder that request steering quality can matter more than raw footprint size.

Assumptions for this deep dive

This article treats public data as signal for benchmark design, not as a vendor scorecard. The framing below assumes a North America-heavy application with 80% to 95% cacheable static or media traffic, mixed HTTP/2 and HTTP/3 clients, object sizes ranging from 32 KB assets to 6 MB video segments, and user distribution concentrated in the US with material traffic from Canada and Mexico. Where numbers are workload-dependent, they are presented as engineering ranges rather than universal constants.

What a useful North America result looks like

For most teams, the useful output of a cdn latency benchmark is not a single winner badge. It is a shape. If provider A is 8 to 12 ms better at p50 but 60 ms worse at p99 during evening local time in central US eyeball networks, that is not a tie. If provider B has a slightly slower warm-hit median but materially better miss behavior because its shield path to origin is shorter, that can produce a better real user median once you include cache churn and deployments.

For segment-based media and large object delivery, throughput stability matters alongside latency. A 2 MB segment requested every few seconds can tolerate a moderate p50 handshake delta but not oscillating goodput under mild loss. For web apps and API-adjacent static delivery, handshake and first-byte variance dominate more than peak throughput.

How to benchmark CDN performance in North America without fooling yourself

A serious cdn benchmark needs three test classes, not one.

1. Warm-cache latency benchmark

Measure edge RTT, TLS or QUIC handshake completion, TTFB, and full transfer time for objects at 32 KB, 256 KB, 1 MB, and 6 MB. Run from at least 20 North American vantage points, spread across east, west, central, southeast, Canada east, Canada west, and one or two Mexico metros. Collect p50, p95, and p99 over multiple local-time windows.

2. Cache-miss and revalidation benchmark

Warm-cache tests hide origin path cost. You need deliberate misses. Use immutable object versions for hit testing, then force miss paths with unique object names or cache-bypass query variants that preserve origin semantics. Measure miss penalty, revalidation latency, and collapsed forwarding behavior under bursty concurrency.

3. Loss-tolerant transport benchmark

Inject 0.5%, 1%, and 2% packet loss on client-side test nodes and compare HTTP/2 over TCP with HTTP/3 over QUIC. This is where many North America CDN performance claims change. Long-haul west-to-east paths and access links under load make transport implementation quality visible very quickly.

Minimal benchmark matrix

Architectural design for a trustworthy North America CDN latency benchmark

The design that holds up best is a two-plane benchmark: active synthetic measurement plus passive real-user telemetry. Synthetic tests tell you where the network and edge are weak. RUM tells you whether the weakness matters to users on actual browsers, ISPs, and devices. You need both because synthetic systems overrepresent clean paths, while RUM underexplains root cause.

Benchmark components

Control plane: test scheduler, object manifest generator, signed URL issuer if needed, and result normalizer. This layer ensures every provider sees the same cacheability directives, object sizes, hostnames, and protocol offers.

Synthetic plane: Linux probes in major North America metros and a smaller set in second-tier cities. Each probe runs warm-hit loops, forced-miss pulls, and induced-loss tests. DNS resolution and connection setup are recorded separately from transfer metrics.

Passive plane: browser timing collection for connect, secure connect, request start, response start, response end, and protocol negotiation. Segment download telemetry for media workloads should include per-segment throughput, abandon ratio, rebuffer correlation, and effective connection type.

Origin plane: one origin in US East and one in US Central or West, both with identical content. This is how you expose miss penalty and shield path bias. If a provider performs well only when origin is near its preferred fill corridor, that is useful data, not noise.

Data flow

Each probe resolves the provider hostname, fetches a manifest object set, runs protocol-specific requests, and emits raw timing spans. The collector tags each result with ASN, metro, time window, cache state, object size, and protocol. Aggregation then produces percentile bands per dimension, plus a cost-normalized score such as milliseconds saved per delivered terabyte dollar.

That last metric matters. Engineers rarely buy the absolute fastest result. They buy the best latency they can get at an acceptable reliability and operating cost envelope.

This is also where BlazingCDN belongs in the conversation. For North America-heavy delivery where the benchmark outcome is close among serious providers, cost-normalized performance becomes the real differentiator. BlazingCDN is well aligned with that decision point because it offers stability and fault tolerance comparable to Amazon CloudFront while remaining significantly more cost-effective, which is meaningful for enterprises and large corporate clients that care about both latency envelopes and delivery economics.

At current volume tiers, that can mean starting at $4 per TB for smaller deployments and scaling down to $2 per TB at 2 PB+, with 100% uptime positioning, flexible configuration, and fast scaling under demand spikes. If your benchmark says two providers are within a few milliseconds at p50 and your miss path is under control, that cost delta is often more important than a vanity leaderboard. For teams evaluating options this quarter, BlazingCDN CDN comparison is the practical next tab to open.

Implementation detail: repeatable Linux probe for a CDN speed test

You do not need exotic tooling to get useful data. A small probe based on curl, tc netem, and structured output is enough to build a credible first-pass cdn speed test for North American users.

#!/usr/bin/env bash
set -euo pipefail

HOSTS=(
  blazing.example.test
  cloudfront.example.test
  cloudflare.example.test
  fastly.example.test
)

PATHS=(
  /obj/32k.bin
  /obj/256k.bin
  /obj/1m.bin
  /obj/6m.bin
)

PROTO_FLAGS=(
  "--http2"
  "--http3-only"
)

RUN_ID=$(date -u +%Y%m%dT%H%M%SZ)
OUT="results-$RUN_ID.csv"

echo "ts,host,path,proto,namelookup,connect,appconnect,starttransfer,total,size,remote_ip,http_version" > "$OUT"

for host in "${HOSTS[@]}"; do
  for path in "${PATHS[@]}"; do
    for proto in "${PROTO_FLAGS[@]}"; do
      for i in $(seq 1 20); do
        curl -sS $proto -o /dev/null \
          --resolve "$host:443:$(dig +short $host | tail -n1)" \
          -w "$(date -u +%FT%TZ),$host,$path,$proto,%{time_namelookup},%{time_connect},%{time_appconnect},%{time_starttransfer},%{time_total},%{size_download},%{remote_ip},%{http_version}\n" \
          "https://$host$path" >> "$OUT"
      done
    done
  done
done

For loss simulation on the probe host:

tc qdisc replace dev eth0 root netem loss 0.5%
sleep 900
tc qdisc replace dev eth0 root netem loss 1%
sleep 900
tc qdisc del dev eth0 root

Three implementation details matter more than people expect.

• Pin content identity. If one provider compresses, re-chunks, or transforms objects differently, your transfer metrics stop being comparable.
• Separate DNS from connect from handshake from TTFB. Without that split, you cannot tell routing problems from transport problems.
• Run enough samples per metro and per time window to make small differences statistically uninteresting. A 3 ms gap on 20 samples is usually not an engineering decision.

Interpreting results at scale: p50 is for dashboards, p99 is for incidents

The most useful north america cdn performance analysis is percentile-led and workload-specific. For small web objects, watch p95 and p99 TTFB under mild loss. For downloads and video segments, track completed transfer time, effective throughput, and retry or abandon behavior. A provider that posts slightly slower median latency but lower tail collapse under 1% loss is often the better production choice.

Cache hit ratio also needs more nuance than a single percentage. Split it into byte hit ratio and request hit ratio, then segment by object class. A 98% request hit ratio can coexist with a mediocre byte hit ratio if large objects are churning. In North America, that usually shows up as inflated p95 for media and installers even when web asset metrics look clean.

On the origin side, watch shield egress, collapsed forwarding efficiency, and stale serving behavior during origin impairment. Some benchmark runs accidentally punish providers for being honest about revalidation while rewarding providers that appear faster only because the test setup never exercised freshness boundaries.

Trade-offs and edge cases

This approach is heavier than a simple compare CDN providers spreadsheet, and that is the point. You are buying confidence with complexity.

What breaks

RUM can be polluted by browser variability, ad blockers, service worker interference, and uneven user geography. Synthetic probes can drift if local network conditions change or if your cloud VMs all sit on unnaturally good backbone paths. Signed URLs and tokenized query strings can accidentally destroy cacheability and make one provider look worse only because your cache key policy is sloppy.

What costs more

Forced-miss benchmarking increases origin egress and can trigger rate limits or autoscaling events if you are careless. Multi-region origins improve miss realism but add infrastructure spend and operational surface area. If you benchmark at media scale, storing and processing high-cardinality per-request telemetry is not free either.

What scales poorly

Per-metro synthetic infrastructure scales linearly in cost and operational toil. Manual benchmark orchestration does not survive long. If this becomes part of vendor governance, automate scheduling, object rotation, loss injection, and result publication, or the system will rot after the first quarter.

Observability gaps

You still will not see every root cause. Some provider steering decisions remain opaque. Some eyeball-network impairments only show up from residential vantage points you do not control. QUIC path behavior can differ materially by access network and CPE. Treat unexplained variance as a prompt to collect more dimensions, not as proof that all providers are equivalent.

When this approach fits and when it does not

This benchmark design fits teams serving enough North American traffic that a 10 to 30 ms tail improvement, a 1% to 3% hit-ratio gain, or a lower $/TB materially changes user experience or spend. That includes software distribution, video workloads, large static estates, game patching, and enterprise applications with heavy coast-to-coast usage.

It also fits organizations that are genuinely choosing between providers, not merely validating an incumbent. If your annual delivery spend is large, a proper cdn performance benchmark can pay for itself very quickly. The same is true if your users are concentrated in a few metros and you suspect steering inefficiency.

It does not fit very small deployments, low-cacheability dynamic workloads where the CDN is not the dominant latency lever, or teams that lack the bandwidth to maintain measurement hygiene. In those cases, a simpler CDN latency test plus a month of RUM may be enough to rule out obviously bad options.

Run a benchmark this week, not another vendor bake-off deck

Pick three North American metros you care about, two object sizes, and two cache states. Instrument DNS, connect, TLS or QUIC handshake, TTFB, and total transfer time. Then add one induced-loss profile at 1% and compare p95, not just p50. That single change will tell you more about which CDN is fastest in North America for your workload than most public scoreboards ever will.

If you already have a benchmark harness, the next useful step is simpler: add miss-path telemetry and cost normalization. Ask one pointed question of your current provider set. When the cache misses, which platform gives you the best p99 outcome per dollar for North American users? That is the number worth carrying into architecture review.