CI server dashboard unresponsive

Hi,

Firstly, thanks for all your work on Lighthouse-ci, it is amazing!

I noticed an issue when setting up that I wanted to report as it’s a bit strange… When visiting the main dashboard page performance seems really poor. Opening the sidebar takes about 7 seconds and I only see about 3 frames of the animation. Hovering over a project card also makes it clear something odd is going on as the hover styles take a second or two to apply.

I don’t think I’ve done anything weird, and have just setup LHCI server on AppEngine, although I see the same behaviour by just following the docs and running the server locally:

npm install -D @lhci/cli @lhci/server sqlite3
npx lhci server --storage.storageMethod=sql --storage.sqlDialect=sqlite --storage.sqlDatabasePath=./db.sql

My machine is a 15" MacBook Pro 2019.

Digging into this a bit:

Looking in DevTools I can see some really long RasterizePaint events (~7s):

---

When I’m viewing a report diff view or lighthouse report I don’t see this issue. It only seems to be a problem on the main dashboard page.

If I display: none the <div class="project-list__confetti-background"> the issue goes away. Looking into the SVG I see a that there is significant usage of mix-blend-mode:multiply, and removing this inline style from the source SVG fixes the performance problem (but obviously changes how the background appears):

Perhaps we need to go easy on mix-blend-mode?

[patrickhulce]

Thank you very much for this excellent report with great detail! You’ve certainly done Lighthouse CI proud we really appreciate your time on this 😃

A few notes on what’s going on here:

The “Rasterize Paint” times are unfortunately just broken in DevTools Performance panel and have been for a little while. Using chrome://tracing reveals that the actual raster tasks are just a few ms long but DevTools UI displays them as start tasks without an end and automatically extends them to the end of the trace. Even with your fix if I let the trace continue for 20s, then the “RasterizePaint” times are reported as… you guessed it 20s 😃

If rasterize paint isn’t the problem then what’s going on? I would assume, and traces seem to confirm, that multiply blend mode gets applied at the GPU. Having about 100 multiply blend modes on top of each other in the same compositor layer is a relatively taxing operation compared to normal layering (roughly 400x more taxing according to my traces, ~0.5ms -> ~200ms). Additionally, because it’s happening on the GPU, DevTools CPU throttling doesn’t appear to do anything to help simulate worse experiences. Because of this and the fact that my 2014 macbook is always plugged in to external monitors so I’m always in high-performance graphics mode, even my performance tests at 6x throttling don’t recreate the behavior you describe.

This might be a good category to introduce to Lighthouse audits “long GPU tasks” and a candidate for improved simulation.

Long story short, IMO multiply is a nice touch but not an essential factor to the design here and not worth the performance cost, so we’ll happily remove it.

[WillsB3]

😄 Thanks for the followup - Good to know it wasn’t just me.

Good stuff on the fix 🎉