lighthouse: ☂️ PROTOCOL_TIMEOUT
tl;dr - Chrome sometimes stops responding, most commonly when trying to clear the cache, so uncheck “Clear storage” and try again.
Explanation
This is the umbrella ☂️ issue for all PROTOCOL_TIMEOUT error reports. We’re collecting all of them in a single place so that we can easily identify which protocol methods are most problematic to prioritize to Chromium domain owners.
PROTOCOL_TIMEOUT refers to the situation when Lighthouse has been waiting for Chrome to respond to a single command for more than 30 seconds. PROTOCOL refers to the Chrome DevTools Protocol connection that Lighthouse uses to talk to Chrome.
If you experienced a protocol timeout issue, please just comment here with the method name, e.g. Network.clearBrowserCache
More recent update: https://github.com/GoogleChrome/lighthouse/issues/6512#issuecomment-924123935
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 142
- Comments: 360 (23 by maintainers)
Links to this issue
Commits related to this issue
- [Lighthouse] Use friendlyMessage for error display. We started losing important information here because of Lighthouse's i18n pipeline. See https://github.com/GoogleChrome/lighthouse/issues/6512#iss... — committed to ChromeDevTools/devtools-frontend by deleted user 4 years ago
- [Lighthouse] Use friendlyMessage for error display. We started losing important information here because of Lighthouse's i18n pipeline. See https://github.com/GoogleChrome/lighthouse/issues/6512#iss... — committed to binaryage/dirac by deleted user 4 years ago
- Specify version of Lighthouse to use Since we don't rebuild this container all the time, we already effectively use a pinned Lighthouse version. And it seems that sometimes there are bugs in newer Li... — committed to iFixit/lighthouse-docker by deleted user 3 years ago
- Specify version of Lighthouse to use Since we don't rebuild this container all the time, we already effectively use a pinned Lighthouse version. And it seems that sometimes there are bugs in newer Li... — committed to iFixit/lighthouse-docker by andyg0808 3 years ago
- update lighthouse dockerfile I ran into some issues attempting to run the current image of lighthouse through the python script. In order to fix this I needed to update the lighthouse dockerfile. Th... — committed to iFixit/lighthouse-docker by ardelato a year ago
I also experienced this bug in the programmatic usage with the lighthouse. I request to consider this as important
@Yasuslik thanks for the link, I managed to fix it with
lighthouse --chrome-flags="--disable-dev-shm-usage"🥳I too have observed the same issues on our docker container and saw many of the same error messages, sometimes they did not error from the same points in the stack trace. 🤷♀️
Running it locally by installing the lhci commandline tools and using
lhci collectwith the same settings as before gave a more insightful error object than in my AWS logs:What fixed this for me:
Passing
--collect.settings.maxWaitForFcp="45000"seemed to do the trick. As of this post the default looks like 30 seconds.https://github.com/GoogleChrome/lighthouse/blob/315c3678db586d5b1c1d76383fbbb3ad48a8ed6b/types/externs.d.ts#L153 https://github.com/GoogleChrome/lighthouse/blob/777bf1147fd0f6aca16ffefde1350bf6297476d4/lighthouse-core/config/constants.js#L97
I understand that’s a high number of 45 seconds, but you can see why I am keen to get this up and running. :p Hope this helps other people if your lighthouse containers are erroring in the same way. I was stuck on this for longer than I would care to admit…
Adding these chrome flags greatly improved performance for me (using lhci in
cypress/browsers:node14.17.6-chrome100-ff98docker image):We went from 5:50 to 2:20 for
lhci collectWe’ll have to see, ifPROTOCOL_TIMEOUTnow still occurs.Posting again, for anyone else having issues with this - we fixed our issue with the
--disable-dev-shm-usageChrome flag. With that flag in place we were also able to stop skipping thefull-page-screenshotaudit. 😎See: https://github.com/codeenigma/ce-deploy/blob/lhci-chrome-fix-plus-docs_PR_devel/roles/lhci_run/defaults/main.yml#L16
Lighthouse 7.4.0 executed via “lighthouse-batch 7.1.0” (shell)
Method: Network.enableEnvironment: gitlab-ci Image: Alpine 3.11 + Nodejs 14.x LTS Chromium: chromium@edge (91.0.4472.77-r0) (via edge package) Additional pkg: harfbuzz ca-certificates “freetype>2.8” ttf-freefont nss Error rate: 100%LH Params: none (except --port <puppeteer browser port>) Chromium Params: --no-sandbox --disable-dev-shm-usage --in-process-gpu Additional Info: We use puppeteer to spawn the browser, and then let the LH uses that instance via wsEndpoint()
Stack Trace:
It seems “resetting state with about:blank” somehow makes it stuck.
Not sure if it’s gonna help someone, but I had to remove the
full-page-screenshotaudit from my config to get around this problem:I’m getting this error for about 90% of runs against https://www.eyebuydirect.com/eyeglasses/women. Seems to happen more often on EC2 than it does on my local machine.
This is with Lighthouse 7.0. Same problem on 6.1.1 and 6.5.0.
Still getting this error: PROTOCOL_TIMEOUT
Chrome version: Version 84.0.4147.89 (Official Build) (64-bit)
@tw-360vier
We were also having an issue with a protocol timeout at Driver.sendCommandToSession for a certain test, and another one returning null, when running lighthouse in a tekton pipeline. Adding these flags to our chrome launch resolved the issue. Thanks!
PROTOCOL_TIMEOUT
Getting this error on an internal app, how do I fix this?
PROTOCOL_TIMEOUT
A few notes for everyone here…
This is not a single issue that has a single fix. This is the catch-all error name for any time that Chrome stops responding to Lighthouse’s commands. There are likely thousands of different reasons this is happening across everyone who has chimed in here.
There are, however, some very common reasons this happens, but nothing can really be done about them in Lighthouse (and sometimes not by anyone but the site owner, Lighthouse can obviously do other things than this specific error message but none that would allow the analysis to be valid after this occurs).
onerror="this.src='/404'"which is an infinite loop).--disable-dev-shm-usageChrome flag in container-like environments.As always, if anyone has a consistent repro for a specific URL that doesn’t fall into one of the top 2 cases. Please forward it our way and we’ll be happy to look into if it’s something that can be fixed in Chromium.
WHEN RUNNING WITH Applied Fast 3G throttling…
Sometimes get this instead…
Does not happen with No throttling selected.
{ "code":"PROTOCOL_TIMEOUT", "friendlyMessage": "Waiting for DevTools protocol response has exceeded the allotted time. (Method: Emulation.setScriptExecutionDisabled)", "level": "error", "lhrRuntimeError": true, "protocolMethod": "Debugger.disable" }“lighthouse”: “11.6.0”
Runtime.evaluatei’m also seeing this issue in our Gitlab CI pipeline using lhci:
I feel obligated to say that if you use identical flags from the CLI and if you use the same
CHROME_PATH, there is no fundamental difference from your script and the CLI (the CLI does exactly what this script does usingchrome-launcher), and I strongly suspect some other unobserved difference to be really at play here @Axection. My best guess is that the flags were not being passed properly in the CLI because omitting--disable-dev-shm-usagewill absolutely give you the behavior you describe.Hi - any progress on this?
We are running the
Lighthouse@6.5.0in a docker image and are facing theEmulation.setScriptExecutionDisabledtimeouts for desktop emulation.The chrome launcher settings are:
the lighthouse settings are:
we kill and respawn chrome before each run against an url but still see:
Props 🤲 to https://github.com/GoogleChrome/lighthouse/issues/6512#issuecomment-797152215 which fixed this type of timeout for us.
To run in docker and run in gitlab-ci you need use it solution https://github.com/GoogleChrome/lighthouse/issues/9212#issuecomment-607276050
In docker have troble with /dev/shm
i mouned volume to /dev/shm and problem has sold
docker-compose.yml
I’ve already been using the flags you mentioned:
I run Lighthouse on hundreds of other URLs, but for some reason these two consistently
PROTOCOL_TIMEOUT. But, oddly 1 out of 10 runs or so, they don’t.I am getting the following error when running Lighthouse:
PROTOCOL_TIMEOUT
Thanks @PeppyH,
adding the
--disable-dev-shm-usageflag is solving the issue for me!I was running into the errors below running inside docker in gitlab CI - this was caused by the following
“By default, Docker runs a container with a /dev/shm shared memory space 64MB. This is typically too small for Chrome and will cause Chrome to crash when rendering large pages. To fix, run the container with docker run --shm-size=1gb to increase the size of /dev/shm. Since Chrome 65, this is no longer necessary. Instead, launch the browser with the --disable-dev-shm-usage flag” - https://developers.google.com/web/tools/puppeteer/troubleshooting
Adding the flag ‘–disable-dev-shm-usage’ to the collect settings solved the issue as per the explaination above. Posting this in case someone else encounters the same problem
I thought this would be fixed in upcoming updates, but waiting for more than 5 to 6 updates. Nothing changed.
PROTOCOL_TIMEOUT
Please don’t do this anyone.
lighthouse_worker_module.js:1453:229is just the line that creates this error, literally everyone running into this in devtools will have this as their stack trace. This is the correct place to track PROTOCOL_TIMEOUT.As stated in the issue description this error happens when Chrome stops responding to Lighthouse commands. Obviously, this also means we can’t get any extra information from Chrome about why this happened because Chrome wouldn’t respond*. In very rare circumstances that are actually reproducible (https://github.com/GoogleChrome/lighthouse/issues/11124) there is something Lighthouse can do about it, but 99% of the URLs shared here do not reproduce in a clean Chrome environment, meaning it’s specific to the device and there’s not much we can do to investigate.
We’ve been thinking about ways to recover from this situation, but it will pretty much always involve some loud annoying error like this until whatever causes Chrome to stop responding is fixed.
Most reliable fix I’ve found (that also works with k8s) is to add flag
--disable-dev-shm-usageto disable shared memory.Any idea why would this happen?
It seems to happen when I run from Gitlab CI, locally doesn’t have any issues.
I can try later on configuring a bigger server as CI runner in Gitlab
I’m running the tests on a couple of pages, two of them work fine, two of them timeout with that error.
The pages are kind of heavy on javascript with React and other dependencies (~45 performance score on finished tests)
Hey @patrickhulce! Any updates for the fix of this issue? There have been a whole lot of complaints.
This is so frustrating. It just doesn’t work at scale. Constantly getting this protocol error and getting this since 2018.
Today i had the same case run Lighthouse programmatically in Docker. Local and from CMD was everything fine.
--disable-dev-shm-usagehelped me. I’m starting Chrome in Docker with:We’re also experiencing this
PROTOCOL_TIMEOUTfor two methods.Network.setUserAgentOverrideandRuntime.evaluateError:
Runtime error encountered: Waiting for DevTools protocol response has exceeded the allotted time. (Method: Network.setUserAgentOverride)We are getting both of the above errors intermittently on one branch and never on another.
Both branches:
We’re wondering if the fact that its running 6+ lighthouse runs at the same time in the same build (different directories for output) might cause this?
Log:
Same issue as above
Edit: Using
--disable-dev-shm-usagechrome flag fixed it and vastly improved performance results. I’m running it in a docker container.IMO, I don’t feel so much advantage to concentrate report to here related with
PROTOCOL_TIMEOUTeven a little. Since it’s not cause but result, as @patrickhulce pointing out.This issue is so much long that the people from Google search won’t be able to find suitable solution for their situation. If reporter used new issue, he will use issue template. Then the people from Google search will be able to find suitable issue for their situation from reporter’s description.
@michaltobiasz “Inspector.targetCrashed {}” in the logs means that the tab crashed in Chromium. There’s nothing we can do in Lighthouse about it, but if you can report the crash dump at crbug.com, they might be able to find the root cause.
I believe using
--collect.settings.maxWaitForFcp="45000"means you are using Lighthouse-CI, correct? I first tried it like that and realized that is the syntax for the CI CLI. Lighthouse itself needs--max-wait-for-fcp=4500.Emulation.setScriptExecutionDisabled
Running a series of Lighthouse tests using lighthouse-ci on GitHub Actions (example failing run). Works on some URLs, then fails reliably on this page if I run from GHA or from an Ubuntu Docker container using act. Running against that URL works successfully if run from macOS.
Versions: lighthouse@7.0.0, @lhci/cli@0.7.0
Thank you! Works for me too, I’m using this docker image: https://hub.docker.com/r/femtopixel/google-lighthouse
@bbuhler I noticed it started working again after updating chrome, Chrome 86 Fixed.I did this operation on million of pages & it worked
I’m running Lighthouse CI in a docker container with Gitlab CI.
I noticed, in my case, it fails when I use WEBP images either directly or in a
<picture>source. If the image returns 404 or when I use JPG or PNG instead it doesn’t fail. Also it only fails with a local running server (started withstartServerCommand). Running the CI with the same build against a public domain don’t fail with WEBP.I hope this information may help.
Happen occasionally only on specific website
I get the following error:
Method: Emulation.setScriptExecutionDisabled Method: Runtime.evaluate
https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2366297
PROTOCOL_TIMEOUT
PROTOCOL_TIMEOUT
This test was done with every category but PWA on docker for mac 2.2.0.3 (docker version 19.03.5), lighthouse version 5.6.0 on a 2,6 GHz 6-Core Intel Core i7 with 16 gigs of ram. I have however seen the same kind of issues running on ECS with both t3.xlarge and t3.2xlarge although they are more frequent on ECS than when running on prem.
What I’m seeing is the page being audited reload with “normal” performance, then appear to reload and time out.
If it’s useful, the app in question is compiled with Angular 9rc8, and has the same behavior with Angular 9rc10.
I have throttling and clear storage turned OFF, and I’m testing just for desktop.
UPDATE: Turning off the test for PWA makes the problem go away.
Is there a way to catch this error at least ? I have tried to get around this by adding some retry logic but to no avail. The error somehow gets around the try catch block and a .catch statement to kill the whole process
As a temporary solution, is there a way to increase this timeout ?
So I get a PROTOCOL_TIMEOUT intermittently but dont know how to solve it. I have tried all the solutions in this thread to no avail. Below is my stack trace:
Runtime error encountered: Waiting for DevTools protocol response has exceeded the allotted time. (Method: Emulation.setScriptExecutionDisabled) LHError: PROTOCOL_TIMEOUT at /usr/local/lib/node_modules/@lhci/cli/node_modules/lighthouse/lighthouse-core/gather/driver.js:348:50 at new Promise (<anonymous>) at Driver.sendCommandToSession (/usr/local/lib/node_modules/@lhci/cli/node_modules/lighthouse/lighthouse-core/gather/driver.js:346:28) at Driver.sendCommand (/usr/local/lib/node_modules/@lhci/cli/node_modules/lighthouse/lighthouse-core/gather/driver.js:369:17) at /usr/local/lib/node_modules/@lhci/cli/node_modules/lighthouse/lighthouse-core/gather/driver/wait-for-condition.js:476:23 at async Promise.all (index 0) at async Object.gotoURL (/usr/local/lib/node_modules/@lhci/cli/node_modules/lighthouse/lighthouse-core/gather/driver/navigation.js:127:26) at async Function.loadPage (/usr/local/lib/node_modules/@lhci/cli/node_modules/lighthouse/lighthouse-core/gather/gather-runner.js:74:36) at async Function.runPass (/usr/local/lib/node_modules/@lhci/cli/node_modules/lighthouse/lighthouse-core/gather/gather-runner.js:584:49) at async Function.run (/usr/local/lib/node_modules/@lhci/cli/node_modules/lighthouse/lighthouse-core/gather/gather-runner.js:507:29)
Has anyone found a solution ?
protocolMethod: ‘Network.emulateNetworkConditions’
Chrome version: 109.0.5414.75 Lighthouse version: 9.6.8
oh okay. sorry for not realizing that the CLI actually does the same thing. probably all this time the flags weren’t passed correctly. thanks for clarifying 😃
After some experiments, I think
PROTOCOL_TIMEOUTwas occured more often on lighthosue under plain CLI product, so I suggest to use thelighthouse-coreinstead, which so far it works on my local and our gitlab-ci (100% success in pipeline result), in addition of more stable Benchmark Index, even in randomly scaled CI runner.Though, this requires additional npm package
chrome-launcherandpuppeteer-core(+optionally axios for fetch). Plus, you need a chromium installed. The idea is to use lighthouse on already launched chrome. So overall it looks like this:A bit more scripting, but I think you guys doing lighthouse in runner, VM or some cronjob, so a lil bit extra js/ts file won’t hurt your pipeline 😉
FWIW, that tells me that the most likely issue at play here is that the page is altering its content based on geography in a way that sends it into an infinite loop and/or crashes. Unfortunately, we don’t have the bandwidth to be in the business of debugging infinite loop root causes, but we do plan on using a separate error message for when we detect this is the case in the future.
You can send them my way.
Thanks @patrickhulce. I’m not trying to be a pest, so please bear with me. Over the years I’ve certainly tried every setting mentioned in this issue and other places online… and my own experimentations. I’ve tried every Docker Image flavor in existence.
In my case, I’m not the site owner of the URLs as I provide this service to the site owners. Ultimately I just want to have a path forward for them to tell them what exactly is causing the problem and have suggestions for them.
The above is tricky when these URLs seem to only fail in under certain scenarios - namely geographic location.
I’ll go through and put together my newest list of URLs and curate based on how consistently I can reproduce locally. I’d rather not post them publicly.
Is there a private channel or email I can send them to when I have them?
Hello, could you solve the issue? Mine get stuck also after Get webapp installbility errors. I m using a React app. This happens only when i register service worker.
`` status Get webapp installability errors +18ms
status Disconnecting from browser… +30s
ChromeLauncher Killing Chrome instance 13076 +1ms
Runtime error encountered: Waiting for DevTools protocol response has exceeded the allotted time. (Method: Page.getInstallabilityErrors) LHError: PROTOCOL_TIMEOUT at Timeout.<anonymous> (C:\Users}\AppData\Roaming\npm\node_modules\lighthouse\lighthouse-core\gather\driver.js:322:21) at listOnTimeout (internal/timers.js:554:17) at processTimers (internal/timers.js:497:7) ``
Timing out on
Page.getInstallabilityErrorsTry skipping the SEO category. It worked for me –only-categories=performance,accessibility,best-practices,pwa
Worked but I get a “question mark” on performance…
Version: @lhci/cli@0.7.0
Same error on third try:
Hey all, I’m getting this consistent error while attempting to run lighthouse programmatically via AWS.
This script was previously not getting this error in AWS, and continues to not get this error when executed on my local machine.
In AWS I am using the Ubuntu 18.04 aws/codebuild/standard:4.0 image
Notable dependencies: “chrome-launcher”: “^0.13.4”, “chromedriver”: “^87.0.7”, “lighthouse”: “^7.0.0”
Any thoughts or ideas as to why this could’ve started happening?
Chrome Version 86.0.4240.183 (Official Build) (x86_64) Mobile mode. Incognito.
Thanks for sharing that URL @bbuhler I can reproduce that roughly ~5% of the time!
It looks like in this case Chrome is completely crashing on this page.
@adamraine if you’re looking into PROTOCOL_TIMEOUT issues might want to do a test of disabling source maps gatherer to see how that affects things (I suspect request interception is the crash trigger, I disabled those audits and couldn’t repro in 100 runs compared to 5/100 with)
@patrickhulce you can test with https://www.elitesingles.com/
Thanks @bbuhler do you have this site available on the internet anywhere for us to test?
PROTOCOL_TIMEOUT
Method: Runtime.evaluate
Nope.
Lighthouse v6.3.0 running on a Heroku worker (with Chrome build pack)…
Hi, I’m trying to run Lighthouse CLI on a bunch of pages in a dockerized environment and I get this error 10/10 times :
I ma facing the same issue for the website I want to perform the test
☁️ Internet (not localhost) ☑️ Performance ☑️ Best practices ☑️ SEO
I was making some changes to our website, to solve some issues marked by Lighthouse, suddendly it started throwing the next error on both Desktop and Mobile
PROTOCOL_TIMEOUT
PROTOCOL_TIMEOUT
This was caused due to missing file named asset-manifest.json But is this fire really required??
@patrickhulce
Looks like most of the time, this error is produced by
Network.clearBrowserCache.That’s legit, but do you think that in order to mitigate these kinds of problems, could be a thing the ability to skip browser setup & teardown?
At least for my use cases, these steps aren’t necessary (since a browser is bootstrapped before the audit and it dies after the audit)
Disabling these stages can have better output timing, I guess.
I’ve solved the problem in my machine by following steps:
I ran into this issue with lighthouse running on an Alpine docker container within Jenkins. We tried to increase the timeout and modify a few settings and nothing worked. But, what did work was modifying the base container from Alpine to Debian-based. Not entirely sure why, although I thought it would be good to point out here.
@patrickhulce getting this error while using Node API Run on Docker lighthouse Version: 5.4.0
LHError: PROTOCOL_TIMEOUT at Timeout._onTimeout (/docker/xxx/node_modules/lighthouse/lighthouse-core/gather/driver.js:409:21) at listOnTimeout (internal/timers.js:549:17) at processTimers (internal/timers.js:492:7)We can consistently reproduce this error when running Lighthouse on slower hardware. Here’s an example result in WPT on a Raspberry Pi. It runs successfully on a decent laptop. I can also reproduce this in SpeedCurve’s test agents (LH fails on a c4.large EC2 instance but succeeds on on a c5.2xlarge).
Last few lines of output from a failed run:
PROTOCOL_TIMEOUT
I get this error whether or not “clear cache” is checked. The error noted is without it checked.
Sample repo: https://github.com/NexulAcademy/classroom-simple-crm-v2/commit/94c0c3441c60f587c75adc77c58e2c178ba0cba4
Start the sample repo by running the .net project, which serves the API and Angular app. API requires the Entity Framework Db migrations to run. directions in the repo. (README-MIGRATIONS.md)
For the record, unchecking clear local storage prevents the error.
A work around not really a long term fix.
PROTOCOL_TIMEOUT
PROTOCOL_TIMEOUT Channel: DevTools Initial URL: https://www.reesby.com.au/ Chrome Version: 74.0.3729.169 Stack Trace: LHError: PROTOCOL_TIMEOUT at eval (chrome-devtools://devtools/remote/serve_file/@78e4f8db3ce38f6c26cf56eed7ea9b331fc67ada/audits2_worker/audits2_worker_module.js:1170:210)
Got error { LHError: PROTOCOL_TIMEOUT at Timeout.setTimeout (/home/chrome/lighthouse/node_modules/lighthouse/lighthouse-core/gather/driver.js:399:21) at ontimeout (timers.js:436:11) at tryOnTimeout (timers.js:300:5) at listOnTimeout (timers.js:263:5) at Timer.processTimers (timers.js:223:10) name: ‘LHError’, code: ‘PROTOCOL_TIMEOUT’, friendlyMessage: ‘Waiting for DevTools protocol response has exceeded the allotted time. (Method: Emulation.setScriptExecutionDisabled)’, lhrRuntimeError: true, protocolMethod: ‘Emulation.setScriptExecutionDisabled’ } Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27)
Can confirm the same “solution” based upon the following response:
A workaround for me was to un-check the “Clear storage” option
Lighthouse Version: 3.3.0.4001 Lighthouse Commit: 66100367e39d970f8208bd30c10bd97cc7240784 Chrome Version: 70.0.3538.110 Initial URL: https://golftocs.com/ Error Message: PROTOCOL_TIMEOUT Method: Storage.clearDataForOrigin Stack Trace:
Very strange - I just ran LightHouse successfully 2 days ago on this site.