paulirish
commented
9 months ago This big JS cost is on the old features page.
The new features page doesn't have this big JS cost.
But the network request to /api/v0/features seems to take 3-5 seconds. Definite room for improvement there, since it's in the critical path.
jstenback
I noticed chromestatus doesn't do so well in Lighthouse 6.0. Mostly because of poor scores for TBT and LCP.
Here's a complete LH report using the latest and greatest: https://googlechrome.github.io/lighthouse/viewer/?gist=c72fa612d2d8e0648c0c7281af9d3c9e
I've had chromestatus in some automated performance monitoring for a while (just by chance, tbh.) You can see there was a large regression in the lighthouse performance score on January 21st.
I took a look at a trace to see what's up. This trace was captured on my very new corp-issued imacpro (it's a fast machine). No throttling.
https://trace.cafe/t/OR8OkWKxSD
The key feature of the trace is a 1s long task for _enqueueUpdate which handles all the connectedCallbacks of the lit-html elements.
I didn't dig in too deep here, but it looks like each
<chromedash-feature>is taking ~2ms to render/commit. And ideally doing all of them would be split up into multiple tasks instead of 1 big one. That would drive down the TBT a lot.The LCP is just late because there's a lot of JS to be done. If you rendered the first 10-20 features and yield to let the browser ship a frame, then LCP would probably be satisfied as the above-the-fold content is all painted.