PSI: Issues with WebGL & other GPU tasks

[MrToph]

Hi, my website can never be tested I always receive an error. I think I could track it down to one of my packages which uses WebGL + shaders.

There's a tiny example static website as a showcase for the metaballs-js package.

Reproduction:

1. Run a test for https://mrtoph.github.io/metaballs-js/
2. See it fail with Error: Backend Error

[robdodson]

Looks like this fails in PageSpeed Insights as well (under the hood we use their API).

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fmrtoph.github.io%2Fmetaballs-js%2F

@brendankenny @paulirish are y'all cool with me reassigning this to Lighthouse?

[brendankenny]

makes sense, thanks @robdodson.

I don't see an issue in CLI/devtools, so may be only a PSI thing.

[connorjclark]

Error isn't occurring anymore. Not much changed on LR since this issue was reported - we went from 4.1 to 5.0 LH, and updated our Chromium version by a mere few hours. @MrToph did anything significant change with the given URL?

[MrToph]

No, nothing changed with the URL at all. I'm still getting the backend error, but now only on mobile.

[connorjclark]

Interesting. I sometimes get no issues at all (And see the page w/ the shader working in mobile / desktop final screenshots on PSI). Other times I get "Backend Error" on just mobile or on mobile and desktop.

[connorjclark]

Seems to be unrelated to WebGL or shaders. I believe the culprit is the high amount of work being done on the main thread. I expect that to cause timeout errors, but instead we see this opaque "Backend Error".

@exterkamp does this make sense to you?

[exterkamp]

I'll put this in the bad psi errors category :wink: since it seems to be an opaque error.

[pttsky]

I am working on a project which is showing the same issue. Pagespeed is showing either 'Backend error' or metrics 'First CPU Idle' and 'Main thread work' are going crazy. It is using THREE.js. If webgl renderer element is not appended into the DOM, these metrics are around 10-30s (here and after "normal scores" 😜 )

I have tested random sites from awwwards claiming to use three.js (https://www.awwwards.com/websites/three-js/)

Here are the scores as of July 2019: https://docs.google.com/spreadsheets/d/1Z9g0pLB3Y-2xdfZXXNtpcUrcjI-NMl8JrJKnK2mXhCU/edit?usp=sharing

2 of 22 got 'k.o.' in their desktop score - these are 'Backend error' Another 5 of 22 have oddly repeating have 133-137 seconds of first CPU idle / main thread, which looks like a bare timeout value.

It is possible to postpone embedding of into the DOM for 1-2 seconds after window.load and get a "normal" score.

Lighthouse is crashing with similar frequency as pagespeed insights.

[iDVB]

We're having this exact same issue. Is there a resolve for this yet? Do we have this down to a specific call that we can feature detect on and just not include that WebGL piece? Ideally though, would be nicer to have pages be rated correctly AND render without timing out. Right now, most of our sites that use WebGL are causing Lighthouse to completely timeout in our CI pipeline. (container lighthouse)

[patrickhulce]

@iDVB we don't think this is a Lighthouse problem but rather a Chrome issue in particular environments (PSI being the environment discussed in this issue).

Are you saying in a Chromium version that otherwise runs WebGL quickly, Lighthouse makes it fail? We haven't seen any cases of that yet.

[connorjclark]

unfortunately PSI has to run WebGL in software.

should we dedupe this to https://github.com/GoogleChrome/lighthouse/issues/10334#issuecomment-591127593

[paulirish]

In LR the metaballs site currently hits this error

Extension result empty. Lighthouse calling Page.navigate with https://mrtoph.github.io/metaballs-js/
Uncaught (in promise) Error: Extension timed out. No call to exit() before render timeout.

should we dedupe this to #10334 (comment)

10334 is the page performance metrics are innacurate because webgl is in software mode.

i'm not sure this is the same, but it might be. it could be that the metaballs code gets the LR worker so busy that it can't timeout on the load or exit gracefully. if so, then yeah basically two sides of the same coin.

[connorjclark]

i'm not sure this is the same, but it might be. it could be that the metaballs code gets the LR worker so busy that it can't timeout on the load or exit gracefully. if so, then yeah basically two sides of the same coin.

That's gotta be it. My MBP gets 18 FPS on that page!

[paulirish]

internal ticket: b/177375218

[adamraine]

Chrome uses the GPU for more than just WebGL, so it might be worth investigating the impact of this and if we can get GPUs for LR.