Lighthouse returned error: PROTOCOL_TIMEOUT

What’s actually happening

The run dies partway through with PROTOCOL_TIMEOUT, naming a method like `Page.enable`, `Page.navigate`, or `Page.getAppManifest`. It's intermittent on heavy pages and reproducible on others. What's happening: Lighthouse sends a command over the Chrome DevTools Protocol and waits (default ~45s); if Chrome is pinned by a hung resource, a redirect loop, or a blocked navigation, the response never arrives and Lighthouse times out.

Common causes

• The page is genuinely too heavy — a long-running main-thread task (e.g. parsing thousands of DOM nodes or a massive JS audit) blocks Chrome from answering the protocol.
• A resource hangs and never finishes loading, so the load event the command is waiting on never fires.
• A redirect loop or slow server response stalls navigation past the timeout.
• An anti-bot / WAF challenge (CAPTCHA, JS challenge, bot-fight mode) intercepts the headless session and never serves real content.
• Underpowered or throttled CI/container runner — not enough CPU/RAM, so Chrome itself is slow to respond.

How to fix it

1. Reproduce locally and watch the networkRun the Lighthouse CLI with `--view` and `-GA` to save artifacts, or load the URL in headed Chrome DevTools and check the Network panel for a request stuck in Pending. A single hung resource is the most common cause.
2. Raise the protocol timeoutPass a larger `maxWaitForLoad` / `--max-wait-for-load` (or the CDP timeout in your runner). It won't fix a true hang, but it rules out a page that's merely slow and confirms whether the page ever finishes.
3. Check for anti-bot interceptionIf the site is behind Cloudflare bot-fight, a WAF, or a CAPTCHA, the headless UA gets challenged and stalls. Whitelist the test IP/UA, disable the challenge for the audit, or test a staging URL that bypasses it.
4. Look for redirect loops and dead resources`curl -sIL <url>` to see the redirect chain. A loop or a 30s+ server response will blow the timeout. Fix the redirect or the slow endpoint.
5. Give the runner more resourcesIn CI/containers, bump CPU and memory and add `--chrome-flags="--disable-dev-shm-usage"`. A starved container makes Chrome respond too slowly to the protocol even on a light page.