DDoS Mitigation and Performance: Protecting Without Slowing Down

Q: How much latency does always-on DDoS protection add?

Always-on protection typically adds 1-3ms of latency for traffic routed through the nearest scrubbing center.

Q: Can DDoS protection improve website performance?

Yes. DDoS mitigation services that include CDN and caching capabilities can improve performance for normal traffic by caching content at edge locations.

Q: What is the performance impact of JavaScript challenges?

Invisible JavaScript challenges add 100-500ms to the first page load while the browser executes the challenge script. Subsequent requests within the same session use a validated token with no additional delay.

Q: How do I choose between always-on and on-demand protection?

Choose always-on if your application is latency-sensitive and cannot tolerate 1-5 minutes of degradation during attack rerouting. Choose on-demand if cost is a primary concern and brief degradation is acceptable.

Q: How does rate limiting affect legitimate traffic during an attack?

Properly configured rate limits should not affect legitimate users during normal operation. During attacks, if source IPs are spoofed or shared, some legitimate users may hit rate limits.

By Elena Kowalski · June 12, 2026 · 12 min read

Distributed Denial of Service attacks overwhelm applications with traffic volumes that exceed normal capacity. Mitigation systems must absorb or filter this traffic before it reaches your infrastructure. The challenge is doing this without adding meaningful latency to legitimate user requests — every mitigation technique inspects traffic, and inspection takes time.

Modern DDoS mitigation has evolved beyond simple volumetric filtering. Application-layer attacks (Layer 7) mimic legitimate traffic patterns, requiring deeper inspection that costs more processing time. Understanding the performance implications of each mitigation layer helps you design protection that shields your application without becoming a bottleneck for real users.

Attack Types and Their Performance Impact

Attack Type	Layer	Detection Method	Mitigation Latency
Volumetric (UDP flood, amplification)	L3/L4	Traffic volume thresholds	<1ms (network-level filtering)
Protocol (SYN flood, Smurf)	L3/L4	SYN cookie validation, rate limits	<1ms (kernel/NIC level)
Application (HTTP flood)	L7	Request pattern analysis, rate limiting	1-5ms (request inspection)
Slowloris (slow connections)	L7	Connection timeout enforcement	Minimal (configuration-based)
DNS amplification	L3/L4	Source validation, rate limiting	<1ms (DNS resolver level)
API abuse (credential stuffing)	L7	Behavioral analysis, CAPTCHA	5-50ms (challenge pages)

Network-layer (L3/L4) attacks are cheap to mitigate: hardware-level filtering adds sub-millisecond latency. Application-layer (L7) attacks require request-level inspection, adding 1-50ms depending on the depth of analysis and whether challenge mechanisms are deployed.

Mitigation Architecture

Always-On vs On-Demand Protection

Always-on DDoS protection routes all traffic through the mitigation network at all times. This adds consistent baseline latency (typically 1-3ms from the nearest scrubbing center) but provides instant protection when an attack begins. There is no detection delay or traffic rerouting needed.

On-demand protection only activates when an attack is detected. Normal traffic flows directly to your origin with zero mitigation overhead. When an attack begins, traffic is rerouted to scrubbing centers — a process that takes 30 seconds to several minutes via BGP route propagation. During this rerouting window, your infrastructure is exposed to the full attack volume.

For performance-critical applications, always-on protection is recommended. The 1-3ms baseline latency is preferable to the minutes of degradation or downtime during attack rerouting.

Scrubbing Center Performance

Scrubbing centers are distributed facilities with massive network capacity (often 10-100+ Tbps aggregate) that filter DDoS traffic. When your traffic routes through a scrubbing center, the center inspects packets, drops malicious traffic, and forwards clean traffic to your origin.

Latency Considerations

Geographic proximity: Traffic routes to the nearest scrubbing center. Providers with more PoPs offer lower latency because traffic travels a shorter distance to reach the scrubbing facility.
Inspection depth: L3/L4 filtering happens at line rate with no measurable latency. L7 inspection requires packet reassembly and request parsing, adding 1-3ms.
Return path: Clean traffic exits the scrubbing center and travels to your origin. If the scrubbing center is far from your origin, the return path adds latency. Direct peering between the scrubbing provider and your hosting provider minimizes this.

Rate Limiting Strategies

Rate limiting restricts the number of requests a client can make within a time window. It serves dual purposes: mitigating DDoS attacks by preventing any single source from overwhelming your application, and protecting backend resources during traffic spikes.

Rate Limiting Algorithms

# Fixed Window: # Simple counter per time window. Burst-prone at window boundaries. # Latency: O(1) counter increment # Example: 100 requests per minute per IP # Sliding Window Log: # Tracks exact timestamps of each request. Most accurate but # memory-intensive. # Latency: O(log n) sorted insert # Memory: O(n) per client # Sliding Window Counter: # Hybrid: weighted average of current and previous window counts. # Latency: O(1) arithmetic # Memory: O(1) per client — two counters # Best balance of accuracy and performance # Token Bucket: # Tokens added at steady rate, consumed per request. # Allows controlled bursting (bucket capacity = burst limit). # Latency: O(1) token check # Most common algorithm for API rate limiting # Leaky Bucket: # Requests queue and drain at fixed rate. # Smooths bursts completely — strict output rate. # Latency: O(1) check, but requests may queue

Performance Impact of Rate Limiting

Rate limiting itself adds negligible latency (under 0.5ms) because the algorithms are simple counter operations. The performance impact comes from the response to rate-limited requests: returning a 429 status code immediately is fast, but challenge mechanisms (CAPTCHAs, JavaScript challenges) add 50-500ms to the user experience as they complete verification.

Challenge Pages and User Experience

Challenge pages verify that a request comes from a real browser operated by a human, not an automated bot. They are effective against sophisticated L7 attacks but add significant perceived latency for legitimate users.

Challenge Types and Latency

Challenge Type	User Delay	Effectiveness	User Impact
JavaScript challenge (invisible)	100-500ms	Blocks simple bots	Transparent to users
Managed challenge (adaptive)	0-2s	Adapts to threat level	Minimal for most users
Interactive CAPTCHA	5-15s	Blocks sophisticated bots	Frustrating, accessibility issues
Proof-of-work challenge	1-5s	Compute-cost-based deterrent	Delays page load

The best practice is progressive challenge escalation: start with invisible JavaScript challenges for all suspicious traffic, escalate to managed challenges for persistent offenders, and reserve interactive CAPTCHAs for confirmed attack patterns. This minimizes user friction while maintaining strong protection.

CDN as DDoS Shield

CDN networks provide inherent DDoS resilience by distributing traffic across hundreds of edge locations. A volumetric attack targeting a single IP address is absorbed across the CDN's distributed infrastructure. Cached content continues to be served from edge PoPs even if the origin becomes unreachable.

The performance benefit is that cached requests experience zero DDoS-related latency: they never reach the origin or the scrubbing infrastructure. For content-heavy websites where 80-90% of requests can be cached, a CDN dramatically reduces the attack surface by limiting origin-bound traffic to the 10-20% of requests that require dynamic processing.

Origin Cloaking

For CDN-based DDoS protection to be effective, attackers must not be able to bypass the CDN by targeting the origin IP directly. Origin cloaking involves removing the origin server's public IP from DNS records, restricting origin access to CDN IP ranges via firewall rules, and using authenticated pull from the CDN to the origin.

Application-Layer Defenses

Connection Limits

Limit concurrent connections per client IP to prevent slowloris-style attacks that hold connections open indefinitely. Set connection timeouts aggressively: a legitimate HTTP request completes headers within 5 seconds and the full request within 30 seconds. Connections exceeding these timeouts should be terminated.

Request Validation

Validate requests at the earliest possible point. Reject malformed requests, oversized headers, and invalid HTTP methods before they reach application code. This reduces the processing cost of attack traffic and prevents application-level resource exhaustion.

Monitoring During Attacks

During a DDoS attack, monitoring must distinguish between attack traffic (to measure mitigation effectiveness) and legitimate user experience (to verify that mitigation is not degrading performance for real users).

Attack metrics: Requests per second (total and blocked), bandwidth consumed, unique source IPs, geographic distribution of attack traffic
User experience metrics: Core Web Vitals from RUM data, error rates for legitimate users, response time percentiles (P50, P99), availability from synthetic monitors at multiple locations
Infrastructure metrics: CPU and memory utilization on mitigation appliances, bandwidth utilization on upstream links, connection pool saturation, server health indicators

If legitimate user P99 latency increases by more than 20% during an attack, your mitigation is too aggressive and needs tuning. The goal is to maintain pre-attack performance levels for real users while absorbing attack traffic.

Frequently Asked Questions

How much latency does always-on DDoS protection add?

Always-on protection typically adds 1-3ms of latency for traffic routed through the nearest scrubbing center. This includes the detour through the scrubbing facility and basic L3/L4 inspection. L7 inspection adds an additional 1-3ms. For CDN-integrated protection, the overhead is often absorbed within existing CDN latency since traffic already routes through CDN PoPs.

Can DDoS protection improve website performance?

Yes. DDoS mitigation services that include CDN and caching capabilities can improve performance for normal traffic by caching content at edge locations. They also filter bot traffic that consumes origin resources, effectively increasing available capacity for legitimate users. Many sites see lower origin load and better response times after deploying DDoS protection with caching.

What is the performance impact of JavaScript challenges?

Invisible JavaScript challenges add 100-500ms to the first page load while the browser executes the challenge script. Subsequent requests within the same session use a validated token with no additional delay. The challenge is transparent to users — they see a brief loading indicator, not an interactive prompt. For most websites, this one-time delay is acceptable for the security benefit.

How do I choose between always-on and on-demand protection?

Choose always-on if your application is latency-sensitive and cannot tolerate 1-5 minutes of degradation during attack rerouting. The constant 1-3ms overhead is lower than the spike during rerouting. Choose on-demand if cost is a primary concern and brief degradation during attack onset is acceptable. E-commerce, financial services, and SaaS applications generally require always-on protection.

How does rate limiting affect legitimate traffic during an attack?

Properly configured rate limits should not affect legitimate users during normal operation. During attacks, if source IPs are spoofed or shared (NAT/corporate networks), some legitimate users may hit rate limits. Mitigate this by using per-endpoint limits rather than global limits, whitelisting known good IP ranges, and implementing progressive challenges instead of hard blocks.