How Firewalls Affect Response Time
A web application firewall (WAF) inspects every HTTP request before it reaches your application, checking for malicious patterns like SQL injection, cross-site scripting, and known attack signatures. This inspection adds latency — but how much depends entirely on where the firewall runs. The difference between a plugin-based WAF and a DNS-level WAF is not just architectural; it produces fundamentally different performance characteristics.
Plugin-Based WAFs
A WAF that runs as a WordPress plugin executes inside PHP on your server. Every request — including legitimate page views from real visitors — triggers the firewall’s inspection code before WordPress processes the page. This adds CPU load and memory usage to your server, increasing TTFB by anywhere from 10 to 100+ milliseconds depending on the ruleset complexity and server resources.
The key limitation: plugin-based WAFs consume the same server resources that WordPress needs to generate pages. Under heavy traffic or during an attack, the firewall’s processing competes directly with page rendering. A brute force attack that generates thousands of login attempts per hour forces your server to evaluate each one through the WAF rules, potentially slowing responses for legitimate visitors at the same time.
DNS-Level and CDN-Based WAFs
Services like Cloudflare, Sucuri, and Fastly run their WAF at the network edge, before traffic ever reaches your server. Malicious requests are filtered at the CDN layer and never consume your server’s resources. Legitimate traffic passes through with minimal added latency — typically 1-5 milliseconds — because the inspection happens on infrastructure purpose-built for high-throughput traffic analysis.
This architecture has a significant performance advantage: during an attack, your server does not even see the malicious traffic. A DDoS attack that would overwhelm a plugin-based WAF (and your server along with it) is absorbed at the edge. Your server continues serving pages normally because the attack traffic never arrives.
The Trade-Off
DNS-level WAFs require routing your traffic through a third-party service, which means a DNS change and trusting an external provider with your traffic. Plugin-based WAFs are simpler to install and keep everything on your own server. For sites where security plugin overhead is causing measurable TTFB increases, moving WAF functionality to the DNS level is one of the most effective performance improvements available — it removes processing from your server entirely rather than trying to optimize it.
Some site owners run both: a DNS-level WAF for primary protection and a lightweight plugin for WordPress-specific monitoring like login attempt logging. This layered approach works as long as the plugin layer is kept minimal to avoid duplicating the overhead.
Further Reading
- Hardening WordPress (WordPress Developer Resources) — Server-level security measures that complement or replace plugin-based firewalls.
- Web Application Firewall (OWASP) — Technical overview of WAF architectures and how they protect web applications.