Lightrider RPC deadline instead of LHR+timeout

[JoshKNYC]

We have never been able to run a successful measurement for any other page on our site. We used to receive the Error: 500, now we're seeing other issues. Example:
Error: Lighthouse returned error: RPC::SERVER_ERROR: Client could not parse server reply; initialization error is: ''

Here is a sample url from our site: https://www.techlicious.com/tip/how-to-delete-your-old-facebook-account/

[robdodson]

@ebidel does that sound like a LR error?

[ebidel]

Verified that the LH API times out on that URL. Looks like the backend is hitting the 60s timeout limit.

[exterkamp]

Instrumented this site in devtools and it seems like it never calms down on the main thread work:

Which definitely causes LH to wait for a long time for a quiet period. In this case it seems to take ~80 seconds to run on LR, which is well above the 60s timeout. I don't think there's much we can do from our end, we have to wait for main thread quiet periods in order to run LH, and there doesn't seem to be any in this page load within our timeouts. @patrickhulce might have some more context.

[patrickhulce]

Yikes, that seems like a case where we should be killing JS and returning our new "page hung" error instead. Outcome to the user probably isn't that different other than the error message.

[JoshKNYC]

If I run this watching resources through Chrome Task Manager, I'm not seeing the constant CPU activity. Page loads, then CPU drops off to zero (one time it did keep running with significant usage, culprit was doubleclick.net in the Task Manager). Any sense for why Chrome Task Manager would show different CPU activity than LH/LR?

[exterkamp]

Lighthouse uses the tracing data from Chrome Devtools to analyze page performance, which is more fine grain than the overall task manager footprint. To look at this data without lighthouse consult this. I used the performance panel in devtools to look at the JS activity for this site vs a sligthly more quiet site.
Flame chart for https://www.techlicious.com/tip/how-to-delete-your-old-facebook-account/:

Flame chart for https://amazon.com:

Techlicious never seems to calm down on the JS calls. (Seems like some Timers keep firing forever in rapid succession maybe?)

This makes it so that LH can not finish analyzing the page, therefore web.dev and pagespeed insights will timeout.

Hope this helps.

[paulirish]

@JoshKNYC this is something we'll look into.

We need to understand where in the LR run this gets to. We shouldn't hit DEADLINE_EXCEEDED.

[JoshKNYC]

FWIW, I suspect the issue may be related to ad refresh.

[JoshKNYC]

@JoshKNYC this is something we'll look into.

We need to understand where in the LR run this gets to. We shouldn't hit DEADLINE_EXCEEDED.

Is there any update on this issue? We're having the same problem now with Pagespeed Insights. The error message gets thrown after 25 seconds, so doesn't seem timeout related unless you've shortened your timeout from 60 seconds.

[exterkamp]

You get a DEADLINE_EXCEEDED after 25 seconds? That is definitely not expected, the timeout is still 60s.

No updates on this yet unfortunately 🙁

[JoshKNYC]

Error we see is the same as in my first post "Lighthouse returned error: RPC::SERVER_ERROR: Client could not parse server reply; initialization error is: ''.

It was Google devs above who suggested this is a timeout issue with DEADLINE_EXCEEDED. However, we're seeing the error I referenced consistently at 25 seconds, which suggests a fixed timeout on your end or some process that kicks off on our end at 25 seconds that kills your process. Though we have no idea what that would be on our side, and the error gives us nothing to go on.