How we measure WAF latency — and why we label every number

A number is only honest if you can say how you got it

“Virtually zero latency” is the standard line for a security edge. It is also unfalsifiable — there is no method behind it, so there is nothing to check. We would rather publish a real figure with the method attached, and label exactly what hardware produced it. This page is that method.

What we actually measure

The claim that matters is the added latency: the time our WAF spends inspecting a request, on top of the network round-trip you would pay anyway. We measure that at three levels.

• Per-request, at the edge. Every request the WAF processes records its own inspection time in microseconds — the waf_processing_time_us value written to our request log. That is the filtering cost in isolation: parsing, rule evaluation, the challenge-ladder decision. We convert microseconds to milliseconds for reporting and never round a sub-millisecond figure up to a friendlier-looking number.
• Distribution, not a single lucky sample. A median hides the tail, and the tail is where real users feel latency. We compute both the median and the P99 with a percentile query (percentile_disc) over the actual request-log rows in a measured window — not a synthetic average, not a hand-picked best case.
• End-to-end, through the edge. A per-request microsecond count says nothing about page experience, so we also run a Lighthouse harness that loads a real page through the edge and compares it against loading the same origin directly. That captures anything the isolated timer cannot — TLS, buffering, connection reuse.

The design budget

Our engineering target is ≤5 ms of added latency on normal traffic. That is a design budget the whole data-plane is built around — shared-memory caches ahead of Redis, no blocking I/O in the request path, a single WAF pass per request. It is the number we hold ourselves to, and the reason the architecture looks the way it does.

What the current figures mean — read the label

Every latency figure we publish today is staging-measured on a single 1-vCPU node. Our staging edge is one small VPS. It is enough to prove the method, exercise the full filtering pipeline, and produce real percentiles — but it is CPU-bound, and a one-core box is not a production edge. So we say so, every time, right next to the number. The live figure lives on our edge status page, regenerated from the same request-log query described above.

What we do not claim

Our full performance target — sustaining high throughput at a tight P99 on production hardware — is a benchmark we have not run, because the staging node cannot run it. That production-fleet result is hardware-blocked, and until it runs on real edge hardware we do not present any number as a production result. A staging figure with an honest label is worth more than a production figure we cannot stand behind.

That restraint is the whole point. If you want a WAF that tells you exactly what it measured and on what hardware, tell us your domain.