Lighthouse: ☂ "Unable to load the page"

[paulirish]

Within Lighthouse, this error comes from gatherRunner.assertPageLoaded. This is called right after we finish loading the page for a pass (there are 3 passes by default). It looks for the HTML resources's network record (via some URL comparison).

If it fails to find a match, we error. Or if we find a match, but the network record is marked as failed, then we error.

There are a few cases in which this error shows up.

1. Server failure with initial request URL: The HTML request was matched but determined to be failed. This happens with incorrect server configurations, when the server does not reply at all, or replies with an empty/otherwise invalid response. Examples: #2459 (redirect configuration was botched, resulting in a error page if you navigate to the HTTP regularly in chrome) #2500 (TLS handshake error) #2646 (a local server replies with an empty response)
   Solution: Fix your server to return valid HTML documents with successful status codes.
2. Server doesn't offer HTTP: The host doesn't offer a site at the HTTP URL at all. Example: #1978
   Solution: Change your server to redirect HTTP traffic to HTTPS
3. ~HSTS: The host is using HSTS, and Chrome can't allow the browser to attempt to navigate to HTTP. Example: #2465~
4. about:blank: Audits was started on about:blank somehow. Canonical issue: #2362. This should be fixed on the DevTools side, and will ship in m61, but can still happen occasionally for unknown reasons. If this happens consistently on a particular URL for you, please file a separate issue specifying the URL.
   Solution: Restart Chrome and run Lighthouse again. If problem persists with a particular URL, file a new issue here with the title "Reproducible about:blank errors"
5. No document request found: Lighthouse was unable to identify any network request as the main HTML resource. Example: #3496
   Solution: Restart Chrome and run Lighthouse again. If problem persists with a particular URL, file a separate issue with the title "Cannot identify main document"
6. Bad TLS/certificate interstitial. Lighthouse couldn't load the page because Chrome couldn't handle the security configuration of the URL. Example #1123
   Solution: Fix your server to return a valid, secure TLS certificate.

[zhanjh]

I got this bug "#3199" because my server doesn't offer the right HTTP URL. This is my old nginx config:

server {
    listen    80;
    server_name    *.tecposter.cn;
    return 301 https://$server_name$request_uri;
}

The value of $server_name is "*.tecposter.cn" and it need to be changed to $http_host:

server {
    listen    80;
    server_name    *.tecposter.cn;
    return 301 https://$http_host$request_uri;
}

[patrickhulce]

Assigning @brendankenny for fixing the #2459 related instances

[clubclick]

the way i got around this issue was to run each audit option at a time instead of all at once

[nhoizey]

@clubclick even if I run only the PWA audit, it doesn't work on my website

[techy16]

I have opened the issue #4884 which is showing closed now as it is showing duplicate. Do you have any resolutions to this issue?

LHError: FAILED_DOCUMENT_REQUEST
at Function.getPageLoadError (/usr/local/lib/node_modules/lighthouse/lighthouse-core/gather/gather-runner.js:163:21)
at pass.then._ (/usr/local/lib/node_modules/lighthouse/lighthouse-core/gather/gather-runner.js:298:36)
at
at process._tickCallback (internal/process/next_tick.js:188:7)

[KolyaSlisarenko]

Hello, there is a lot of links in google that follows to this page, that shows a lot of cases of the error but without examples of solution of the problem. Could you provide some examples to fix these issues quickly?

[patrickhulce]

@KolyaSlisarenko the examples are outlined in the issue description as 1-6. Do none of those cases apply to you?

[KolyaSlisarenko]

@patrickhulce It's not so obvious to understand which case suits for me because it has worked for a month and now it stopped.
p.s. oom issue I've fixed

[KolyaSlisarenko]

@patrickhulce I ran lighthouse using sudo command and it works) It will be interesting how long it will work

[nitinmobikasa1234]

Hi,
Can anyone tell me how I can resolve this "Lighthouse" error.
URL: https://www.izenda.com/
And how I can analyze the cause of error in the website.

[paulirish]

Let's turn the top of this issue into an FAQ/help page.

[SamB]

I assume that, once the page is ready, the issue description will get a nice big link to the new page at the top and/or bottom? Because there are a LOT of things that link here.

[thomwoz]

Hello,
my issue is very similar. I can successfully perform test using Pagespeed UI or when I request data from my application run locally, but when try to perform test from my AWS server, pagespeed responds with ERRORED_DOCUMENT_REQUEST.
So I guess there is some issue on my AWS server, since I am able to get the results requesting from other places.
Do you have any idea what might be wrong?

[vittoriograssi]

Hello everybody,
I have the same problem with PageSpeed on the domain:
www.smarshop.it

Can you help me understand what the problem may be?
I also noticed that Google Analytics also fails to intercept the traffic on this website.

[naveenrajbu]

Hi guys, my site http://ezyleads.in continues to show status 403 Errored_document_request but it works for http://ezyleads.in/index.php I built it with codeigniter
Help me to solve this problem.

[Stefadesign]

So is there any solutions for issue. I am getting the same error ?

[rahultripathi15]

I have a website where I have places Google Analytics code in Header. Initially, this property got verified and working fine.

After about a month this property itself got not verified. I have tried all possible ways including,

Verification by Analytics code
Verification by Google Tag
Verification by HTML Tag
and none of these methods worked for me.

When I tried testing my URL on Google Page Speed Test - It shows the following error:

Lighthouse returned an error: FAILED_DOCUMENT_REQUEST. Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Details: net::ERR_CONNECTION_FAILED)

Others are saying my website got penalized and it is blocked by Google. This issue will not fix.

Please help; what is the issue? How I can fix this?

My website URL is: https://bestringtones-songlyrics.com

and Speed text URL is:
https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fbestringtones-songlyrics.com%2F

Please guide.

[rahultripathi15]

Why this error.

[gamooga-echoabhishek]

Same here few days back lighthouse audits were working fine.
Today I checked it was not working. Getting the same error as rahul's.

I tried switching to incognito, updated my ssl certificates. And still get the error.

Speed test url: https://web.dev/measure/
Website link: https://as2dc10.gamooga.com:456/
Error Mesage:
Error: Error: Lighthouse returned error: FAILED_DOCUMENT_REQUEST. Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Details: net::ERR_FAILED)

[j8n]

I had the same issue 'ERRORED_DOCUMENT_REQUEST' with the 503 error code on a wordpress site! The problem was the wordfence security plugin for me. When I deactivated the plugin the problem fixed.

[ferrerluis]

I wanted to drop a comment and mention this ERRORED_DOCUMENT_REQUEST error happens when scanning Google, too, and even for different countries

Google US (i.e. .com)
Google Netherlands (i.e. .de)

I don't believe Google matches the criteria above, so I am unsure why it'd be doing that

[patrickhulce]

@ferrerluis Google case usually falls under "Server failure with initial request URL". Google servers typically reject a portion of bot traffic and have a fairly low rate limit, so depending on how you're requesting or if you're using a shared service you can hit this fairly frequently.

[jamesarosen]

Our Lighthouse logs end with

Runtime error encountered: Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Status code: 503)

but I've checked our CDN logs and we haven't served a 503 to Lighthouse in the relevant time-frame. It's certainly possible that a sub-resource returns a 503, but I can't tell which one because the logs don't specify which URL is the problem.

[patrickhulce]

503 means that the service is unavailable. Is it possible that whatever is handling the request could go down in a way that wouldn't appear in the logs you're looking at?

This error is only given when Lighthouse receives an error status code for the root document. A 503 for a subresource would not trigger this error.

[jamesarosen]

Is it possible that whatever is handling the request could go down in a way that wouldn't appear in the logs you're looking at?

That's a good question. Cloudflare is the edge of our infrastructure and is logging 200s for these requests. SpeedCurve is running Lighthouse for us in this case. I'll check with them. There may be a proxy in their system.

This error is only given when Lighthouse receives an error status code for the root document.

That's very helpful! Thank you.

[charlesmorgan40]

Within Lighthouse, this error comes from gatherRunner.assertPageLoaded. This is called right after we finish loading the page for a pass (there are 3 passes by default). It looks for the HTML resources's network record (via some URL comparison).

If it fails to find a match, we error. Or if we find a match, but the network record is marked as failed, then we error.

There are a few cases in which this error shows up.

1. Server failure with initial request URL: The HTML request was matched but determined to be failed. This happens with incorrect server configurations, when the server does not reply at all, or replies with an empty/otherwise invalid response. Examples: #2459 (redirect configuration was botched, resulting in a error page if you navigate to the HTTP regularly in chrome) #2500 (TLS handshake error) #2646 (a local server replies with an empty response)
   Solution: Fix your server to return valid HTML documents with successful status codes.
2. Server doesn't offer HTTP: The host doesn't offer a site at the HTTP URL at all. Example: #1978
   Solution: Change your server to redirect HTTP traffic to HTTPS
3. ~HSTS: The host is using HSTS, and Chrome can't allow the browser to attempt to navigate to HTTP. Example: #2465~
4. about:blank: Audits was started on about:blank somehow. Canonical issue: #2362. This _should_ be fixed on the DevTools side, and will ship in m61, but can still happen occasionally for unknown reasons. If this happens _consistently_ on a particular URL for you, please file a separate issue specifying the URL.
   Solution: Restart Chrome and run Lighthouse again. If problem persists with a particular URL, file a new issue here with the title "Reproducible about:blank errors"
5. No document request found: Lighthouse was unable to identify any network request as the main HTML resource. Example: #3496
   Solution: Restart Chrome and run Lighthouse again. If problem persists with a particular URL, file a separate issue with the title "Cannot identify main document"
6. Bad TLS/certificate interstitial. Lighthouse couldn't load the page because Chrome couldn't handle the security configuration of the URL. Example #1123
   Solution: Fix your server to return a valid, secure TLS certificate.

[rahultripathi15]

Hi,
Thank you so much for the continuous update.

Thanks

On Tue, 23 Jun 2020 at 00:49, charlesmorgan40 [e-mail]
wrote:

Within Lighthouse, this error comes from gatherRunner.assertPageLoaded.
This is called right after we finish loading the page for a pass (there are
3 passes by default). It looks for the HTML resources's network record (via
some URL comparison).

If it fails to find a match, we error. Or if we find a match, but the
network record is marked as failed, then we error.

There are a few cases in which this error shows up.

1. Server failure with initial request URL: The HTML request was
   matched but determined to be failed. This happens with incorrect server
   configurations, when the server does not reply at all, or replies with an
   empty/otherwise invalid response. Examples: #2459
   https://github.com/GoogleChrome/lighthouse/issues/2459 (redirect
   configuration was botched, resulting in a error page if you navigate to the
   HTTP regularly in chrome) #2500
   https://github.com/GoogleChrome/lighthouse/issues/2500 (TLS
   handshake error) #2646
   https://github.com/GoogleChrome/lighthouse/issues/2646 (a local
   server replies with an empty response)
   Solution: Fix your server to return valid HTML documents with
   successful status codes.
2. Server doesn't offer HTTP: The host doesn't offer a site at the
   HTTP URL at all. Example: #1978
   https://github.com/GoogleChrome/lighthouse/issues/1978
   Solution: Change your server to redirect HTTP traffic to HTTPS
3. HSTS: The host is using HSTS, and Chrome can't allow the browser
   to attempt to navigate to HTTP. Example: #2465
   https://github.com/GoogleChrome/lighthouse/issues/2465
4. about:blank: Audits was started on about:blank somehow. Canonical
   issue: #2362 https://github.com/GoogleChrome/lighthouse/issues/2362.
   This should be fixed
   https://github.com/ChromeDevTools/devtools-frontend/commit/a3b3d85785aee95f86b489c81bc8a63c1f011dcb
   on the DevTools side, and will ship in m61, but can still happen
   occasionally for unknown reasons. If this happens consistently on a
   particular URL for you, please file a separate issue specifying the URL.
   Solution: Restart Chrome and run Lighthouse again. If problem
   persists with a particular URL, file a new issue here with the title
   "Reproducible about:blank errors"
5. No document request found: Lighthouse was unable to identify any
   network request as the main HTML resource. Example: #3496
   https://github.com/GoogleChrome/lighthouse/issues/3496
   Solution: Restart Chrome and run Lighthouse again. If problem
   persists with a particular URL, file a separate issue with the title
   "Cannot identify main document"
6. Bad TLS/certificate interstitial. Lighthouse couldn't load the
   page because Chrome couldn't handle the security configuration of the URL.
   Example #1123 https://github.com/GoogleChrome/lighthouse/issues/1123
   Solution: Fix your server to return a valid, secure TLS certificate.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GoogleChrome/lighthouse/issues/2784#issuecomment-647723454,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOU3B7UIKI6VTEHZFLEVG73RX6VE5ANCNFSM4DU4WA6Q
.

[patrickhulce]

The outstanding work here is to take the body of the issue and add it to an FAQ in our readme.