Key takeaways
- When a CDN or edge platform serves your site, a load test mostly measures the edge and its cache, not your origin. Your own servers may barely be touched.
- Decide what you want to learn: cache-hit behaviour at the edge, edge function limits, or origin capacity on a cache miss. Each needs a different test.
- Edge functions have hard platform limits (CPU time, memory, subrequests) that a load test can hit long before you run out of capacity.
- Never load test a CDN or edge platform you do not own. Read the provider’s testing policy first; some require notice, and flooding is prohibited.
Edge computing runs code and serves content from locations near the user instead of from one central region. For load testing that means a test aimed at your public hostname usually measures the edge network first, so the result can look excellent while your origin is untouched, or look terrible because a security rule blocked your generators. This article explains what such a test measures, what the main edge platforms limit, how to test them, and what the providers say about testing at scale.
Distance and connection setup are covered in the network latency and load testing accuracy post and delay variation in the network jitter post, so this one stays on the edge itself.
What does a load test of an edge-served site actually measure?
It measures whichever layer answers. A request to a cached object is answered by an edge location without reaching your servers; a request that misses the cache, or is marked uncacheable, goes through to your origin. If you point a load test at a cached page, you are testing the CDN.
Illustrative arithmetic (invented numbers): a test sends 1,000 requests per second at a page with a 95% cache hit ratio. About 50 requests per second reach the origin. If the same page were uncacheable, all 1,000 would. Both are valid tests, but they answer different questions, and the first says very little about how your origin copes with a cold cache after a deploy or a purge.
Three more effects follow from how edge networks work:
- Each location generally keeps its own cache. A generator sending traffic to one location warms that location only. Generators in other regions meet a cold cache until their first requests fill it, so early results from a new region look worse than later ones.
- Where the generator sits decides which edge location answers. Traffic from a generator in Frankfurt is typically served by a nearby location, not the one your users in Sydney reach. Multi-region generators are the only way to cover several locations; LoadFocus runs tests from 25 AWS regions (loadfocus.com/load-testing, read 23 October 2026).
- Security rules treat load as an attack. Rate limits, bot rules and web application firewalls can answer test traffic with 403 or 429 responses. A test report full of those measures your firewall, not your site. Allowlist your generators for the test window, on infrastructure you control.
What can you test, and how?
| Goal | Where to aim the test | What it tells you |
|---|---|---|
| Cache and CDN behaviour | The public hostname, from several regions, with a realistic mix of cached and uncached URLs | Hit ratio, edge response times, how the first request per location behaves |
| Origin capacity | The origin directly (your own server) or a path you have made uncacheable | What your servers sustain when the cache does not help |
| Cold-cache recovery | The public hostname right after a purge or deploy | How much load reaches the origin while the edge refills |
| Edge function behaviour | The public hostname on routes that run the function | Latency and error rate under load, and whether platform limits trip |
Keep cached and uncached traffic in separate scenarios so one does not hide the other. A known trap is varying a query string to defeat the cache: that tests your origin through a slower path and can also fill the cache with junk entries, so use a header or a path you have configured to bypass the cache instead, where your setup allows it.
What do edge function platforms limit?
Edge functions run small pieces of code on the request path, for redirects, header changes, authorization checks or whole backends. Their limits are tight, which is exactly what a load test can reveal. The figures below come from each provider’s own documentation, read on 23 October 2026.
| Platform | What the documentation says |
|---|---|
| Cloudflare Workers | Workers run in V8 isolates. Free plan: 10 ms CPU time per request, 128 MB memory per isolate, 50 subrequests per invocation and 100,000 requests a day (above that, requests return error 1027). Paid plan: 30 seconds CPU time by default, configurable up to 5 minutes, and up to 10,000 subrequests. Time spent waiting on fetch() or storage does not count as CPU time. |
| CloudFront Functions | JavaScript (ECMAScript 5.1), sub-millisecond duration, 2 MB memory, 10 KB maximum code size, no network or file system access and no access to the request body. Scales to millions of requests per second. |
| Lambda@Edge | Node.js and Python; up to 30 seconds duration; 128 MB memory for viewer events and up to 10 GB for origin events; network access and request body access allowed; scales to up to 10,000 requests per second per Region. |
| Fastly Compute | Fastly’s documentation says each incoming request creates one function instance. Read Fastly’s current Compute limits page for CPU and memory caps before sizing a test; they were not confirmed for this article. |
Two practical consequences. First, a load test on the Cloudflare free plan will hit the daily request cap quickly: a test running at about 28 requests per second uses 100,000 requests in an hour. Run edge function tests on a plan and account you are allowed to push, not on the free tier. Second, Lambda@Edge’s per-Region scale figure means a high-rate test can hit throttling that CloudFront Functions would not, so check quotas before the test, not after the failure.
How do you test an edge function under load?
- Test the function’s logic first in the provider’s local or staging tooling, so the load test measures capacity and not bugs.
- Use a staging hostname with the same function configuration and an isolated origin.
- Ramp gradually and watch the provider’s metrics (errors, CPU time, throttles) beside the load test’s response time and error rate.
- Test from several regions, since the function runs in whichever location answers.
- Look for a knee, not an average. The percentile chart shows the point where limits begin to bite earlier than the mean does.
Can I load test a CDN I do not own?
You can test your own site behind a CDN, within that provider’s rules. You must not use load to test the CDN itself, or to test sites you do not own. Policies differ, and several were read on 23 October 2026:
- AWS lists CloudFront among the services customers can penetration test without prior approval, but its policy prohibits denial-of-service testing, including request flooding. It points anyone planning a network stress test to a separate Stress Test policy, and notes that AWS may shape traffic when surges exceed 25 Gbps. Read that policy before a large CloudFront test.
- Fastly asks for at least two business days’ notice for security testing of your service, including DDoS testing, with service IDs, source IPs, dates and whether the test will significantly raise traffic. Its page names security testing, not load testing, so ask Fastly support before a large load test.
- Cloudflare: I did not find a Cloudflare page that sets a load testing policy. Cloudflare’s documentation does describe skip rules for letting trusted traffic past rate limiting and bot rules, and says rate limiting is approximate, so some excess requests can reach your origin. Check your plan’s terms and talk to support before a test at scale.
In every case: test only what you own, tell the provider when its rules say so, keep a stop condition, and never aim load at a shared platform to see what it will take.
What about hybrid edge and cloud setups?
When part of a system runs at the edge and part in a central cloud, test each layer’s limit, then test the combined path at a realistic mix. Edge AI, 5G and IoT traffic raise the volume of small requests but do not change how to test them. The IoT load testing challenges post covers device traffic patterns, and edge locations in cloud testing covers choosing generator locations.
Frequently Asked Questions
How does edge computing change load testing?
It changes what you are measuring. A test of an edge-served site usually measures the CDN cache and edge functions. To test your origin you need a path that reaches it, so plan separate cached and uncached scenarios.
Should I load test from multiple regions when I use a CDN?
Yes. Each region reaches a different edge location with its own cache state and latency. Multi-region results show the spread your users get.
Do edge functions need load testing?
Yes, because they have hard limits on CPU time, memory and subrequests, and some plans cap daily requests. A load test finds those limits before production traffic does.
Is it allowed to load test through a CDN?
For your own site, usually within the provider’s policy. Providers prohibit flooding and denial-of-service testing and some require advance notice. Read the current policy and contact support before a large test.
Why does my load test return 403 or 429 through the CDN?
Probably rate limiting or bot protection. Allowlist your generators for the test window, on rules you control, or test a staging hostname without those rules.
Sources
Read on 23 October 2026 and named as plain text: Cloudflare Workers limits and “How Workers works” docs; Cloudflare WAF docs on skip rules and rate limiting; AWS documentation “Differences between CloudFront Functions and Lambda@Edge”; AWS penetration testing policy and EC2 testing policy pages; Fastly security measures, security testing and Compute billing pages; LoadFocus load testing page.
Published with PostNext
