Lighthouse: Differentiate NO_FCP failure cases

[elliotmassen]

I'm encountering an issue when running Lighthouse from DevTools: for many performance metrics I get an audit error "No usable firstMeaningfulPaint(Candidate) events found in trace". However there's really not too much going on the page, so I'm not sure why it is happening.

However when I run Lighthouse as a Chrome Extension instead I don't get these errors. I've included the JSON export for Lighthouse in DevTools and then as an Extension below.

If there's any other information you'd like, just let me know!

Lighthouse DevTools JSON export
Lighthouse Extension JSON export

[vinamratasingal-zz]

Hi Elliotmassen- thanks for the thorough bug request! Were you doing other stuff in Chrome (like looking at other tabs, loading other pages, etc.) while Lighthouse was running on DevTools? If so, that could have caused the interference and the issue you were seeing. We'd recommend just running Lighthouse again and seeing if that fixes the issue.

I'm going to close out this issue for now, but feel free to reopen if you still see this issue :)

[paulirish]

This is one of our top failures in Sentry.

on CLI it's caused by the launched Chrome window being behind/occluded other windows, and Mac OS is treating the app as non-visible. In devtools/extension, it's because the user has switched to another tab and has that tab backgrounded. In both cases, there is no more VSYNC ,which means no paints.

[paulirish]

For CLI, I believe Mac OS may be the only OS where this is a problem. Here's one solution:

tell application "System Events"
    set frontmost of every process whose unix id is 26178 to true
end tell

And we could run that with osascript -e. And do that in chrome-launcher...

[patrickhulce]

@paulirish what is still left unexplained is why so much of the sentry numbers come from WPT where supposedly this occlusion issue shouldn't be a problem.

[AttilaVM]

I experienced the same error when I tried to append a WebP image into the DOM from JS, then directly with HTML. Surprisingly the problem vanished when I fell back to PNG.

The WebP image however is rendered perfectly.

So I made very simple HTML file with the same WebP image in its body, it did not trigger the error.

I began to make lesions on my original code. First I removed all the JS code, but the error remained, then I removed the stylus (CSS transpileable language) code, and the error disappeared, I continued, and narrowed down to a simple class with one property, which defines a font family from a custom font face.

The relevant code snippet in the transpiled CSS:

 @font-face {
  font-family: "poppinsRegular";
  src: url("./static/Poppins-Regular.eot");
  src: url("./static/Poppins-Regular.eot?#iefix") format("embedded-opentype"), url("./static/Poppins-Regular.otf") format("opentype"), url("./static/Poppins-Regular.svg") format("svg"), url("./static/Poppins-Regular.ttf") format("truetype"), url("./static/Poppins-Regular.woff") format("woff"), url("./static/Poppins-Regular.woff2") format("woff2");
  font-weight: normal;
  font-style: normal;
}
.primaryFont {
  font-family: "poppinsRegular";
}

Then I changed the font-family to our in-house improved version of Software Tester 7, then to Arial, and in both cases Lighthouse did not throw a NO_FMP error.

So the scary conclusion:

If I use WebP image format and certain type of fonts (presumably not Poppins Regular is the only problematic font) then I get No First Meaningful Paint error. It would be possible to investigate this further, but the time is 1:13 AM here and this is one of the nastiest heisenbugs I've ever seen. So I rather go to sleep.

Tomorrow I will try to make a self contained example of this issue.

My environment:
OS: NixOS 17.09 “Hummingbird” (Linux 4.9.85)
Node: 9.6.1
Chromium: 65.0.3325.162
Lighthouse: 2.9.4

[patrickhulce]

thanks so much for all the investigation @AttilaVM!! the URL where we can find these poppins fonts to reproduce would be 💯

[dannyrb]

I am experiencing the same issue when using Lighthouse from Chrome Dev tools while serving up the development version of my app with Vue CLI 3.0 PWA plugin setup.

Oddly, the tip above about using the Lighthouse Chrome Plugin worked as a work around for me 👍

[bencollinsuk]

This has been a consistent problem for me and I am convinced it is caused by a frameset. The Chrome extension does not have the problem.

[nitelite]

@AttilaVM Where you able to provide them with the font file needed to reproduce? I am having some of the same problems, and I know my page includes both webp and webfonts, so I guess it might be some of the same issues.

[paulirish]

We know the window occlusion is a problem. Also framesets aren't handled well.

Improving FCP within Chromium is the best solution right now.

[paulirish]

(updated)

NO_FCP cases still need to be split apart more.

• framesets are still unhandled.
  
  
  
  • just an iframe too (assuming no content besides an iframe)
  
  
• blank pages vs no paints because occlusion vs no paints because backgrounded.
• occlusion should be sorted by https://github.com/GoogleChrome/lighthouse/pull/9904

related: #3654 #9650