☂ "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/nodemodules/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 notifications@github.com 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.

[padam2403]

Hi,

While using the Google Pagespeed v5 Lighthouse API, I generally face the HTTP 500 Error.

After some time, when I rerun for the same URL, I get the data.

Can anyone help how can I overcome this?

Thanks, Padam

[Bryze]

In my case, was checking a few urls, which to my surprise works fine on web.dev / page speed insights.

But, when I run the test via cli in a dockerised environment, lighthouse returns me the following errors (although works fine on my local docker instance)

 GatherRunner:error 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: 403) https://www.magicbricks.com/prestige-lakeside-habitat-whitefield-bangalore-pdpid-4d4235303139343638

another one

GatherRunner:error 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: 417) https://www.99acres.com/search/property/buy/residential-all/gurgaon?search_type=QS&refSection=GNB&search_location=CP1&lstAcn=CP_R&lstAcnId=1&src=CLUSTER&preference=S&selected_tab=1&city=8&res_com=R&property_type=R&isvoicesearch=N&keyword_suggest=gurgaon%3B&fullSelectedSuggestions=gurgaon&strEntityMap=W3sidHlwZSI6ImNpdHkifSx7IjEiOlsiZ3VyZ2FvbiIsIkNJVFlfOCwgUFJFRkVSRU5DRV9TLCBSRVNDT01fUiJdfV0%3D&texttypedtillsuggestion=gurgaon&refine_results=Y&Refine_Localities=Refine%20Localities&action=%2Fdo%2Fquicksearch%2Fsearch&suggestion=CITY_8%2C%20PREFERENCE_S%2C%20RESCOM_R&searchform=1&price_min=null&price_max=null

Could someone help identify whether the problem lies in how it is being executed, or there is something wrong with the page itself.

Environment Details Lighthouse Version: 7.0.1

[pattarika]

Same issue with Brzye. Keeping getting 503 inside docker. "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/90.0.4414.0 Safari/537.36", "environment": { "networkUserAgent": "Mozilla/5.0 (Linux; Android 7.0; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4143.7 Mobile Safari/537.36 Chrome-Lighthouse", "hostUserAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/90.0.4414.0 Safari/537.36", } }, "lighthouseVersion": "7.1.0", "runWarnings": [ "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)" ],

[SamB]

Hmm. it would be easier to figure out what's going on if lighthouse could show you the failing request (if any), rather than just the status code.

[clubclick]

The HyperText Transfer Protocol (HTTP) 500 Internal Server Error reset service workers

On Fri, 19 Feb 2021 at 17:28, Samuel Bronson notifications@github.com wrote:

Hmm. it would be easier to figure out what's going on if lighthouse could show you the failing request (if any), rather than just the status code.

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

[clubclick]

https://play.google.com/store/apps/details?id=com.app.buckinghampalce

On Mon, 22 Feb 2021 at 12:36, clubclick.online clubclick.online < leepettengell@gmail.com> wrote:

The HyperText Transfer Protocol (HTTP) 500 Internal Server Error reset service workers

On Fri, 19 Feb 2021 at 17:28, Samuel Bronson notifications@github.com wrote:

Hmm. it would be easier to figure out what's going on if lighthouse could show you the failing request (if any), rather than just the status code.

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

[pattarika]

@SamB I call this command inside docker

!/bin/bash

while IFS= read -r line do echo $( date +%X ) 'Creating report for ' $line lighthouse --quiet --no-enable-error-reporting --skip-audits redirects-http \ --chrome-flags="--headless --disable-gpu --no-sandbox --disable-dev-shm-usage --ignore-certificate-errors" \ $line --output html --output json done < 'urls.txt'

[zqbe]

My ticket has been closed automatically. but I'm still having the below issue.

When using PageSpeed for testing the site below, we got an error.

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.qbe.com%2Fau

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_CONNECTION_FAILED)

But the site is accessible. The wired thing is if we use PageSpeed from US region then it works fine. However, it's not working in Australia region.

[mreduar]

@zqbe how do you change the region?

[Mbellsudteen]

ในวันที่ ศ. 1 ต.ค. 2021 07:33 น. Eduar Bastidas @.***> เขียนว่า:

@zqbe https://github.com/zqbe how do you change the region?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GoogleChrome/lighthouse/issues/2784#issuecomment-931800742, or unsubscribe https://github.com/notifications/unsubscribe-auth/APZGLURACL7FUPWQW7GOW73UET6UNANCNFSM4DU4WA6Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[PachVerb]

i just run lighthouse --help

tips Error:

ighthouse --help                                ✔  10030  22:17:37
internal/process/esm_loader.js:74
    internalBinding('errors').triggerUncaughtException(
                              ^

Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader. Received protocol 'node:'
    at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:751:11)
    at Loader.resolve (internal/modules/esm/loader.js:85:40)
    at Loader.getModuleJob (internal/modules/esm/loader.js:229:28)
    at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:51:40)
    at link (internal/modules/esm/module_job.js:50:36) {
  code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'
}

who can help me?

[PachVerb]

i want to know what happen?

[jigneshbhavani]

@PachVerb Updating my node version to 16.0 resolved the same issue.

i just run lighthouse --help

tips Error:

ighthouse --help                                ✔  10030  22:17:37
internal/process/esm_loader.js:74
    internalBinding('errors').triggerUncaughtException(
                              ^

Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader. Received protocol 'node:'
    at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:751:11)
    at Loader.resolve (internal/modules/esm/loader.js:85:40)
    at Loader.getModuleJob (internal/modules/esm/loader.js:229:28)
    at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:51:40)
    at link (internal/modules/esm/module_job.js:50:36) {
  code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'
}

who can help me?

@PachVerb Updating my node version to 16.0 resolved the same issue.

[PachVerb]

@PachVerb Updating my node version to 16.0 resolved the same issue.

i just run lighthouse --help tips Error:

ighthouse --help                                ✔  10030  22:17:37
internal/process/esm_loader.js:74
    internalBinding('errors').triggerUncaughtException(
                              ^

Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader. Received protocol 'node:'
    at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:751:11)
    at Loader.resolve (internal/modules/esm/loader.js:85:40)
    at Loader.getModuleJob (internal/modules/esm/loader.js:229:28)
    at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:51:40)
    at link (internal/modules/esm/module_job.js:50:36) {
  code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'
}

who can help me?

@PachVerb Updating my node version to 16.0 resolved the same issue.

ok, work for me. thanks guys

[Mannyflow7]

304 Not Modified Access-Control-Allow-Origin: * Age: 2318192 Cache-Control: public, max-age=315360000 Connection: keep-alive Date: Mon, 18 Jul 2016 16:06:00 GMT Server: Apache Vary: Accept-Encoding Via: 1.1 3dc30c7222755f86e824b93feb8b5b8c.cloudfront.net (CloudFront) X-Amz-Cf-Id: TOl0FEm6uI4fgLdrKJx0Vao5hpkKGZULYN2TWD2gAWLtr7vlNjTvZw== X-Backend-Server: developer6.webapp.scl3.mozilla.com X-Cache: Hit from cloudfront X-Cache-Info: cached

[adamraine]

I dug through the history of this issue and it does seem obsolete. However the last triage was this comment https://github.com/GoogleChrome/lighthouse/issues/2784#issuecomment-486856089 indicating we should create some permanent FAQ for this. So there is still work to do, but no bugs to fix and at this point there are few enough issues related to main document errors that we can handle them on a case-by-case basis.