I was experiencing frequent - but seemingly random - slow page loads on opening new sites in Chrome. The wait was up to 10 seconds, but a refresh mid-wait appeared to cause it to load quickly.
Copilot gave the following explanation.
The chrome://net-internals/#dns and clear net cache seemed to yield good results, but time will tell.
What you’re describing — first navigation in a new tab taking ~10s, then a refresh becoming fast (even during the wait) — can be DNS-related, but it’s often not “basic DNS resolution”. It’s usually one of:
Chrome’s own host-resolution behavior (async resolver / internal cache / DoH) behaving differently to your terminal tools
Connection establishment delays (TCP/TLS/HTTP3/QUIC, certificate validation/OCSP/CRL, proxy/PAC, AV inspection)
Happy Eyeballs / IPv6 fallback weirdness
Chrome preconnect / preloading / service-worker / HSTS interactions that make “refresh” take a different (faster) path
Below is a practical way to narrow it down.
1) Is it DNS? (And yes: Chrome can behave differently than Terminal)
Chrome does not always behave like nslookup
nslookup queries DNS servers directly and reports what it gets back; it doesn’t necessarily mimic how applications resolve names.
Chrome/Chromium has its own host resolution stack (including caching and support for different resolution sources) rather than being a thin wrapper around the OS resolver. Chromium’s own docs describe Chrome’s host resolution implementation, including DNS/host caching and interaction with system settings. 1
Chrome also maintains a separate DNS/host cache that you can inspect and flush independently. 2
Chrome may use Secure DNS (DoH) depending on settings/policy
Chrome has a “Use secure DNS” setting that can cause Chrome to use DNS-over-HTTPS (or opportunistically upgrade to it), which can differ from what your OS / terminal uses. 3
So yes: Chrome can use a different mechanism/caching/transport than nslookup, and you can see “DNS is instant” in terminal while Chrome still stalls for reasons that look DNS-ish.
2) Why “refresh” is fast even during the wait
A refresh being fast strongly suggests the slow part is something that becomes satisfied/cached/unstuck after the first attempt starts:
DNS answer cached (browser cache, OS cache, router cache)
TCP/TLS handshake completes and is then reused (keep-alive / session resumption)
QUIC/HTTP3 path negotiation completes (subsequent request reuses state)
Certificate validation or revocation check completes (OCSP/CRL)
Proxy auto-detection (PAC / WPAD) finishes
Extension/AV scanning delays only the first request
Chrome DevTools “Initial connection” time includes time to establish the connection (TCP) and negotiate TLS where applicable. 4
3) A focused diagnostic flow (quick to do, high signal)
Step A — Use Chrome’s own network/DNS diagnostics
Open: chrome://net-internals/#dns (or in newer Chrome, use NetLog export via chrome://net-export)
Click Clear host cache
Try loading a site that shows the 10s delay
Re-open the page and inspect whether host entries appear / how they change
Chromium maintains its own host resolution stack and tooling around it. 5
What you’re looking for:
Do you see slow resolution attempts?
Are there repeated failed queries followed by success?
Does it prefer IPv6 first then fallback?
If you want the most precise view: create a NetLog (chrome://net-export), reproduce the issue once, then stop logging. The NetLog will show whether the delay is DNS, proxy resolution, TLS handshake, QUIC, etc.
Step B — Check whether it’s Secure DNS / DoH related
Go to: Chrome Settings → Privacy and security → Security → “Use secure DNS”
Toggle it off temporarily, or set it to a known provider explicitly. This setting controls Chrome’s DoH behavior. 6
Then reproduce the issue.
If disabling Secure DNS fixes it, the problem could be:
DoH endpoint latency/reachability
middlebox interference
IPv6/IPv4 path differences to the DoH resolver
Step C — Rule out proxy auto-detection (a classic “first request takes ~10s” cause)
This is very common on Windows and sometimes macOS in managed environments:
Windows: Settings → Network → Proxy → “Automatically detect settings”
Also check whether a PAC script is configured.
Proxy/WPAD delays often show up exactly like “first request after opening browser/tab is slow”.
Step D — Check IPv6 vs IPv4 weirdness
Even with fast internet, a broken/partial IPv6 path can cause a stall until fallback occurs.
Test quickly:
In terminal, resolve both A and AAAA:
nslookup -type=A example.com
nslookup -type=AAAA example.com
If AAAA exists, try temporarily disabling IPv6 on your adapter (for a test), or test a browser that you know prefers different behavior.
If disabling IPv6 makes it disappear → it’s not “DNS speed”, it’s “first connection attempt over IPv6 stalls”.
Step E — QUIC / HTTP3 negotiation
Chrome may attempt HTTP/3 (QUIC) first on some sites; if your network blocks/impairs UDP/443, you can see delays before fallback.
Quick test:
Go to chrome://flags and temporarily disable Experimental QUIC protocol (or equivalent flag if present), relaunch, retry.
If fixed: your router/firewall/ISP path may be interfering with UDP/443 or QUIC.
Step F — Certificate validation / OCSP / security software
Another common “10s on first connect” culprit:
OCSP/CRL checks stalling
Antivirus “HTTPS scanning” / corporate TLS interception
Extension doing blocking work on first navigation
Chrome’s own help guidance explicitly calls out that firewall/antivirus and extensions can cause connection/loading issues. 7
Quick isolation:
Try Incognito (extensions often disabled)
Or start Chrome with all extensions disabled
Temporarily disable “HTTPS scanning” in AV (if you have it) just to test
If Incognito is fine → extension is likely involved.
4) How to tell exactly what part is slow (DNS vs TLS vs server)
Use DevTools Network timings
Open DevTools → Network → load a site → click the first request → Timing tab.
If the delay is mostly:
“DNS Lookup” → name resolution/DoH/system resolver interactions
“Initial connection / SSL” → TCP/TLS handshake, packet loss, inspection, certificate validation
“Waiting (TTFB)” → server/app delay (less likely if it happens across many unrelated sites)
Remember: “Initial connection” is handshake setup and (where applicable) SSL/TLS negotiation. 8
5) Why your 1.6Gbps speed doesn’t rule this out
Bandwidth ≠ latency. These 10s stalls are typically:
a timeout/fallback interval
a blocked protocol (UDP/443, IPv6)
a proxy discovery timeout
a security product doing synchronous inspection
They can happen on a gigabit link just as easily.
6) Most likely culprits given your symptoms (ranked)
Based on “first request slow; refresh fast; nslookup instant”:
Proxy auto-detect / PAC delay (especially on Windows, corporate setups)
IPv6 first attempt stalls then fallback to IPv4
Secure DNS / DoH path issue (Chrome differs from terminal) 9 10
QUIC/HTTP3 attempt blocked → fallback
AV/Firewall HTTPS inspection or an extension 11
Certificate revocation checks stalling (OCSP/CRL)
7) Two super-quick “tell me the answer” tests
If you want the fastest route to a root cause, do these two:
Test 1 — Disable Secure DNS in Chrome (1 minute)
Settings → Privacy & security → Security → Use secure DNS → Off 12
Retry.
Test 2 — Disable proxy auto-detect (1 minute)
Disable “Automatically detect settings” (Windows proxy settings)
Retry.
If either fixes it, you’ve basically found the class of issue.
A couple of questions (so I can narrow it to one or two likely causes)
What OS are you on (Windows 11 / macOS / Linux)?
Does it happen on all sites (e.g., google.com, bbc.co.uk) or mostly new/less-visited sites?
If you open the same URL in Edge (Chromium) or Firefox, do you see the same first-load stall?
If you tell me those, I’ll suggest the most likely root cause and the shortest path to confirm it (and fix it).
