DNS is usually the first network lookup involved in reaching a hostname. That makes resolver performance interesting when a site feels slow, especially on networks where DNS requests are frequent. But DNS speed is only one part of page performance, so a resolver benchmark should…
DNS is usually the first network lookup involved in reaching a hostname. That makes resolver performance interesting when a site feels slow, especially on networks where DNS requests are frequent. But DNS speed is only one part of page performance, so a resolver benchmark should be used as a focused diagnostic signal.
What WebLens measures
For a hostname, WebLens sends DNS-over-HTTPS requests to three public resolvers: Cloudflare DNS, Google DNS, and AdGuard DNS. It measures elapsed request time from the WebLens server, keeps successful responses as timing results, and sorts available results from fastest to slowest.
The benchmark therefore describes resolver access from WebLens infrastructure. It is not a measurement of your home connection, office network, or mobile carrier.
How to run the comparison
- Enter a domain with public DNS records.
- Run the WebLens DNS Speed Check.
- Compare measured milliseconds and resolver availability.
- Repeat at different times when investigating intermittent performance.
What “fastest” means
The tool identifies the resolver that returned a successful response in the shortest measured time during that run. A difference of a few milliseconds may be real but operationally insignificant for one page load. Larger, repeatable differences can be more interesting.
Resolver caching matters. A resolver that already has an answer cached may respond differently from one that must retrieve it. TTL, cache state, congestion, and the route from WebLens to each provider all influence the result.
A useful troubleshooting example
Imagine users report that a domain occasionally takes several seconds before the page starts loading. A WebLens comparison shows all three public resolvers responding quickly. That evidence makes a widespread public resolver delay less likely from the WebLens location. Investigate the origin, CDN, TLS handshake, routing, or affected users’ local resolver next.
If one resolver is repeatedly much slower while the others remain consistent, that becomes a more specific lead. It still does not prove that the same resolver is slow for every user because the measurement path differs.
Why your result can change
Internet latency changes from minute to minute. Resolver infrastructure is distributed, the selected resolver node can vary, and WebLens runs the three requests sequentially. Each measurement therefore occurs at a slightly different moment.
What this tool does not measure
This is not a complete website speed test. It does not measure Time to First Byte, page rendering, JavaScript execution, image delivery, database latency, or local DNS cache performance. It also does not compare every public DNS provider.
Use resolver speed with DNS correctness
Speed only helps when the resolver returns the right information. If a domain resolves to the wrong address, use the WebLens DNS Lookup. If the domain resolves correctly but connections are slow, combine the result with the Ping / Latency Checker and website status results.
Ready to compare? Run the WebLens DNS Speed Check and treat the fastest result as a measurement from this checking location.
How to make a resolver comparison meaningful
Repeatability matters more than one impressive number. Run the same hostname several times and look for a consistent pattern. If one resolver is occasionally slow while the other two remain stable, record the variation instead of treating a single slow sample as a permanent property.
It is also useful to test a domain with known DNS activity and then compare the results with an ordinary DNS lookup. A fast resolver returning an unexpected answer is not useful for the application. Correctness and latency should be considered together.
When resolver speed is not the bottleneck
DNS usually occurs early in a connection, so a very slow resolver can add visible delay. But once resolution is complete, page delivery can dominate total time. If DNS checks are consistently quick while users report slow pages, shift attention to TCP connection time, TLS, HTTP response time, server processing, and assets. The speed checker is most valuable when used to eliminate one possible layer quickly.