Lighthouse: PROTOCOL_TIMEOUT (Method: Page.getAppManifest)

Created on 4 Feb 2019  路  17Comments  路  Source: GoogleChrome/lighthouse

Provide the steps to reproduce

  1. Run LH on https://seo4.net or https://krakowskakancelaria.pl/

What is the current behavior?

Error: Lighthouse returned error: PROTOCOL_TIMEOUT. Waiting for DevTools protocol response has exceeded the allotted time. (Method: Page.getAppManifest) (PROTOCOL_TIMEOUT)

What is the expected behavior?

No errors.

Environment Information

  • Affected Channels: Pagespeed API returns 500, web.dev and pagespeedinsights return issue.
  • Lighthouse version: ?
  • Node.js version: ?
  • Operating System: ?

Extra info

Issues started to occur since thursday, no action were performed on website, we tried modifying appmanifest but it doesn't seem to be the issue as it is valid and working.
~100 other websites we are tracking regularly do have manifest and they work fine.

P1 PSLR bug

Most helpful comment

Dug in a bit more. A page can actually use WebSockets (although a connection will always fail). The issue looks to be the long polling. I made a minimal repro here: http://uninterested-badge.surge.sh/index4.html

Without the manifest file, PSI runs fine (no protocol timeout). With the manifest file, it times out.

internal bug: b/124008171

All 17 comments

Thanks for filing @curtchan! I'm able to reproduce this as described on web.dev/PSI and not the CLI 馃憤

@patrickhulce sorry, by CLI i meant pagespeed's api endpoint - /pagespeedonline/v5, just tested it manually, same result.

Experiencing this issue on: https://my-project-75792.firebaseapp.com/

Here's my manifest:

{ "icons": [ { "src": "/icons/icon_512x512.8b87eb0e4d43670cf11fa32b4919322c.png", "sizes": "512x512", "type": "image/png" }, { "src": "/icons/icon_384x384.6285f1fb65b23a030564566e379b1cf8.png", "sizes": "384x384", "type": "image/png" }, { "src": "/icons/icon_256x256.5941d252b94571b94a0b8a239346d577.png", "sizes": "256x256", "type": "image/png" }, { "src": "/icons/icon_192x192.f86f32a505cb0f58f097e232fb67eb6d.png", "sizes": "192x192", "type": "image/png" }, { "src": "/icons/icon_128x128.4e225849bee4b9407a94230a2f2cbfa0.png", "sizes": "128x128", "type": "image/png" }, { "src": "/icons/icon_96x96.ed9538684325ed964d8dc88122eeee02.png", "sizes": "96x96", "type": "image/png" } ], "name": "Andrew Noblet", "short_name": "AN", "orientation": "portrait", "display": "standalone", "start_url": ".", "description": "Andrew Noblet", "background_color": "#000000", "theme_color": "#000000" }

I experienced it

https://developers.google.com/speed/pagespeed/insights/?hl=pl&url=https%3A%2F%2Ficsd.shop%2F

This is a page that uses:

  • vue on aws as frontend
  • dockerized meteor on vps as backend

So the o role of websockets is important.

PSI runs LH on infrastructure that does not yet support certain types of requests:

  1. Service workers
  2. App manifests
  3. Websockets

I know for certain that the first type has never worked.

I assumed the second didn't either, @curtchan are you certain that v5 of PSI at one point didn't return (Method: Page.getAppManifest) (PROTOCOL_TIMEOUT)? I think the request never would have worked, so perhaps something changed LH-side in 4.1 (which we updated PSI to last Wednesday). @patrickhulce I see that driver.getAppManifest was changed/edited 20 days ago. So that jells.

AFAIU the third is a huge task and there are no plans currently to implement.

Relevant issue for this in our repo: #6566

Yeah @Hoten we now always try to fetch the manifest, not just in the gatherer!

I didn't realize calling getAppManifest is always guaranteed to hang the run in LR 馃槺

Luckily it seems if the page does not have a manifest, Chrome will return from the Page.getAppManifest protocol call with no data. Otherwise Chrome demands a request that we can't resolve, and it just hangs :(

This is probably serious enough to consider a quick fix + PSI push. Let's discuss in chat.

Determined that https://github.com/GoogleChrome/lighthouse/issues/7147#issuecomment-461069829 is a bit wrong. App manifest files are served just fine in our infra. The problem sites all have websockets - currently their mere existence on a page causes PSI to hang. That certainly is not ideal, and while we may not be able to fully support them yet, we should prioritize preventing a hang.

Dug in a bit more. A page can actually use WebSockets (although a connection will always fail). The issue looks to be the long polling. I made a minimal repro here: http://uninterested-badge.surge.sh/index4.html

Without the manifest file, PSI runs fine (no protocol timeout). With the manifest file, it times out.

internal bug: b/124008171

@Hoten tested again via api explorer for v5:
https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https%3A%2F%2Fseo4.net&strategy=mobile

{ error: { errors: [ { message: "Lighthouse returned error: PROTOCOL_TIMEOUT. Waiting for DevTools protocol response has exceeded the allotted time. (Method: Page.getAppManifest) (PROTOCOL_TIMEOUT)" } ], code: 500, message: "Lighthouse returned error: PROTOCOL_TIMEOUT. Waiting for DevTools protocol response has exceeded the allotted time. (Method: Page.getAppManifest) (PROTOCOL_TIMEOUT)" } }

It clearly returns server 500 error.

Can also reproduce on https://www.toyota.com/camry/ and https://www.toyota.com/ (both of which have a websocket)

@hoten Let's fix in LH and push to LR prod.... on Friday? :) Or.. Thursday!

paulirish closed this

New issue to track the failure without the timeout?

Deployed to PageSpeed Insights production. Toyota now works (usually)

@brendankenny I confirmed. In my case, it works. Thank you @Hoten and @paulirish.

The same here http://77.68.7.68/

Was this page helpful?
0 / 5 - 0 ratings