Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

First Contentful Paint ignores opacity: 0 in some situations

See original GitHub issue

Provide the steps to reproduce

Run LH on https://demo.tannerhodges.com/vitals/fcp/opacity.html.
Compare to https://demo.tannerhodges.com/vitals/fcp/index.html.

👉 See source code: https://github.com/tannerhodges/core-web-vitals/tree/main/fcp

What is the current behavior?

Lighthouse reports that FCP is the same (and sometimes better) when the body is hidden with opacity: 0 and revealed later during page load than when that style is removed and the page renders as quickly as possible.

For example, compare these WebPageTest filmstrips for the files above:

`opacity.html`	`index.html`

WebPageTest video for `opacity.html`	View WebPageTest video for `index.html`
WebPageTest summary for `opacity.html`	WebPageTest summary for `index.html`

Lighthouse correctly reports that LCP was faster in index.html, but incorrectly reports that FCP was slower. (Apparently, opacity.html rendered even sooner than the page appears in either video… 👀)

This is unexpected, and the effect grows in larger projects with similar code patterns.

In some cases, removing opacity: 0 from the body can increase FCP by as much as 1 second or more—even though the page is actually rendering much faster. 👇

Example where FCP reports ≈1s worse, even thought the page renders ≈2s faster

Unfortunately I can’t share the code for this particular project but hopefully the reduced test case replicates the same issues well enough to debug what’s going on.

What is the expected behavior?

Per the Paint Timing spec, elements with opacity: 0 should not be considered paintable.
First Contentful Paint should fire later in opacity.html than in index.html.
In these examples, FCP and LCP should both match since the h1 is the first & largest contentful element to render on the page.

Environment Information

Affected Channels: CLI, DevTools, and others. (I’ve confirmed the same result in PageSpeed Insights and WebPageTest.)
Lighthouse version: 6.4.1
Chrome version: 86.0.4240.111
Node.js version: 14.15.0
Operating System: macOS 10.15.7

Related issues

I’m still trying to get my head around Lighthouse’s internals / which issues are actually relevant, but here are some I across while researching this that might (?) help:

https://github.com/GoogleChrome/lighthouse/issues/2289 DevTools: node revealing is flaky
https://github.com/GoogleChrome/lighthouse/issues/4139 Differentiate NO_FCP failure cases

I’ve also experienced similar issues with CLS ignoring opacity: 0, so in case the topic of paintable elements overlaps with FCP here are those issues:

https://github.com/GoogleChrome/lighthouse/issues/10873 High CLS without actual content shifting
https://github.com/WICG/layout-instability/issues/61 layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

P.S. At this point I’m not sure whether this should be considered a Lighthouse bug or a Chrome bug. Appreciate any insight y’all have as to what’s going on here / next steps I should take.

Let me know if there’s any additional information I can provide.

🙏 Thanks for the help.