Load, Performance, and Penetration Testing

Edge Delivery Services is built on a serverless, CDN-first architecture that is designed to absorb traffic at scale without the need for any manual intervention or capacity planning. We trust this architecture to serve a quiet Monday morning as well as Black Friday, which is why we do not require customers to seek approval before running reasonable load tests, performance tests, or penetration tests against their sites.

That said, we do monitor all traffic to our infrastructure continuously. We can tell when a test is running, we can tell when a test is not achieving anything useful, and we will tell you. This guide explains how to test effectively and what to avoid.

Three different disciplines

Customers frequently treat load testing, performance testing, and penetration testing as interchangeable. They are not. Each validates a different aspect of your site and requires different tools, different targets, and a different interpretation of results.

Load testing answers the question: can the system sustain the traffic volumes I expect? The goal is to verify that all components of the delivery chain, from CDN edge to origin to third-party backends, continue to function correctly under realistic concurrent load.

Performance testing answers the question: does the experience remain fast? This is about measuring user-facing metrics like Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint under varying conditions, not about saturating the origin.

Penetration testing answers the question: can the system be exploited? This is a security exercise aimed at discovering vulnerabilities in the application layer, the CDN configuration, or the content pipeline.

What you are actually testing

In a traditional monolithic CMS, a load test that hammers the origin server with HTTP requests is a meaningful exercise because the origin is the bottleneck. Edge Delivery Services is not a traditional monolithic CMS. Content is being served from globally distributed CDN edge locations. The origin is serverless and scales horizontally without limit. A raw HTTP flood proves exactly one thing: that the CDN can serve cached responses. It always can. The delivery tier already applies strict path filtering that is functionally equivalent to a web application firewall, blocking thousands of illegitimate requests per minute.

Load testing

Edge Delivery Services hosts thousands of websites, serving billions of page views per month. Unless your site is in the 100 most visited sites in the world, your day-to-day traffic won't have an impact on our overall load, and you can save yourself the effort and cost of a load test.

If you are still convinced that you need to perform a load test, we kindly ask you to follow these rules:

1. Test against your production CDN origin. Your visitors do not hit *.aem.page or *.aem.live directly; they hit your CDN. A load test that bypasses your CDN is testing an architecture that no visitor will ever experience.
2. Use browser-based load testing tools that render pages fully. Tools like WebPageTest, Lighthouse CI, Playwright-based harnesses, or commercial real-browser platforms generate the kind of load that reflects actual user behavior. They execute JavaScript, fire third-party tags, and trigger the same API calls a real session would.
3. Simulate realistic traffic patterns. Real visitors do not request the same URL ten thousand times per second. They land on different pages, navigate through the site, interact with forms and carts, and leave. Your load test should model this diversity.
4. Stay within realistic volumes. Test at or slightly above the 99th percentile of your actual traffic, not at arbitrary multiples. Edge Delivery Services enforces rate and volume limits on a per-project basis, and extreme volumes will result in your IP being blocked. On some days, a single customer's load test exceeds the combined traffic of all AEM customers. This is neither useful nor appreciated.
5. Use Operational Telemetry (RUM) data to establish your baseline and identify the pages that actually receive the most traffic. Test those pages under load rather than inventing synthetic scenarios that do not reflect your site's real traffic profile.

Common mistakes to avoid in load tests

🚫 Hitting a single URL repeatedly

A test that requests the same URL thousands of times per second validates nothing but the CDN's ability to serve a cached response. The response will be cached after the first request and served from edge memory thereafter. You will see excellent numbers. They will be meaningless.

🚫 Testing at unrealistic volumes

Edge Delivery Services is multi-tenant infrastructure with strict rate and volume limits. Tests that exceed 200 uncached requests from a single IP per second, or otherwise vastly surpass your site's actual traffic patterns, will be rate-limited or blocked. This is not a limitation of the architecture; it is a deliberate protection for all customers sharing the infrastructure.

If you have a legitimate reason to validate behavior at extreme scale, coordinate with Adobe through Teams, Slack or Adobe Support so we can distinguish a legitimate test from an attack.

🚫 Testing at the network layer

Useful load tests simulate real users in real browsers navigating real pages. They execute the full page rendering, including JavaScript execution, third-party resource loading, and API calls. Network-level HTTP generators like ab, wrk, or vegeta do not do this.

🚫 Testing against the origin

The hostnames *.aem.page or *.aem.live serve Adobe's built-in preview and delivery tiers. They are not your production origins. Your visitors reach your site through your CDN, which may apply its own caching rules, edge logic, security policies, and geographic routing. Testing against *.aem.page or *.aem.live bypasses all of that and produces results that do not reflect the experience your visitors will have.

Additionally, *.aem.page uses different caching rules optimized for content preview immediacy, not production delivery. Performance characteristics measured against *.aem.page are not representative of your published site.

Performance testing

Performance testing does not require high traffic volumes. It requires accurate measurement of the experience as perceived by a real browser.

Use Operational Telemetry as your primary performance measuring tool. RUM data collected from actual visitors provides the most accurate picture of real-world performance across devices, networks, and geographies. Synthetic lab tests are useful for identifying regressions during development, but field data from RUM is the authoritative source.

For synthetic testing, tools like PageSpeed Insights, WebPageTest, and Lighthouse provide detailed performance diagnostics. Run these against your production CDN hostname with appropriate geographic distribution to reflect your visitor base.

Establish performance budgets based on Core Web Vitals and monitor them continuously through RUM rather than relying on periodic test runs. A site that passes a lab test on Tuesday can degrade on Thursday when a marketing team adds a new third-party script. Continuous monitoring catches this; scheduled tests do not.

Penetration testing

As stated in our Security Overview, you are permitted to perform penetration tests against our services without advance notice. We ask that you follow two rules:

1. Perform load tests including simulated (D)DoS attacks only against production infrastructure, which includes your CDN
2. If you find a vulnerability, disclose it responsibly to psirt@adobe.com

Penetration testing should target the full production stack: your CDN, your custom edge logic, and any backend integrations. Testing against origin environments or bypassing the CDN does not reflect the attack surface that a real adversary would encounter.

What you should focus on

Your testing effort is best directed at the components which you control: your CDN configuration, your client-side code, your third-party integrations, and your backend services. These are the components that determine whether your visitors have a good experience under load, and they are the components where testing produces actionable results.

If your CDN is not on the list of supported CDNs, fixing that will do more for your site's performance than any load test. See Unsupported Integrations for common pitfalls.