Carousel\Slider and double LCP event for the same image issue.

[alexd-3d]

Provide the steps to reproduce

1. Run LH on https://yk4bs.csb.app/

What is the current behavior?

If you open "View original Trace" or run it manually in Performance tab - you can clearly see that LCP event if fired twice for the very same image (first slide named 400x400 named for easy distinguishing, next ones are 410,420,430). The second event comes VERY late for the same image.

What is the expected behavior?

The first even should be counted as real LCP and it's when user actually sees it. But somehow, after jQuery carousel initialization (that's 6-7x times longer that 1st real LCP event) - you can see that it was fired again. I've read specifications and thought that some sizing change might be issue. The document says that if the "next LCP event's SIZE is same or smaller - do not count it as LCP". I've inserted observer to verify it and I see 2 evens in console that were fired that have identical image path and sizes. That's frustrating, as carousel are often are actual LCPs on the page and LCP dramatically pulls the overall score down. This issue is not related to Slick-slider. I've checked it on Owl-carousel and I've seen some other users also stuck the very same issue on Stackoverflow but with no answers. The only thing that saved is Keen-slider that used some other way to initialize and render slides. I don't consider it as 3rd-party issue - because I believe lighthouse should report and reflect real user experience. And the real experience is that user DOES see the first LCP correctly. And there's definitely something wrong with second LCP that reports same size property as previous one.

Thanks for any help!

Environment Information

• Affected Channels: CLI, Node, Extension, DevTools
• Lighthouse version: 6.4.0
• Chrome version: 87.0.4280.88 (64bit)
• Node.js version: 12
• Operating System: Win10

[patrickhulce]

Thanks for filing @alexd-3d! What you're describing is a property of the LCP definition in Chromium and was recently changed to no longer drop removed elements from consideration (I think exactly what you're asking for?).

If you're still seeing this in Chrome Canary and the event you're seeing isn't following the spec, then an issue at http://crbug.com/ would be appreciated :)

[alexd-3d]

Hi @patrickhulce , thanks for reply!
It seems like Chrome Canary team has fixed the issue with LCP

LCP event occurs only once (the early one is correct) in the console and in the Performance tab if is run.

However, you can see a strange issue with Lighthouse tab (Canary). It uses 7.0.0 Lighthouse and still reports wrong (way too long LCP time) for carousel BUT indicates true LCP on View Original Trace timeline. I know that timescales are different (due to simulated throttling) but please note the time difference. Here's the LCP by 7.0.0 lighthouse (generally - as high as in 6.4.0).

and here's it's View Original Trace:

FP,FCP - 579.8ms

LCP - same 579.8ms (sometimes it's 20-40ms later but still very close to start of FCP and that's correct):

How come FCP in Lighthouse final stats can be 2.3s and LCP is more than 5s if Original trace shows 0-20ms difference?

I may be wrong but it seems like Trace View and the Final LCP score on Lighthouse tab are measuring different LCP events. Seems like Trace View relies on correct "fixed" version of LCP whereas Lighthouse LCP SCORE counts "old double same LCP event".
What I'm afraid of is that PageSpeed inside is based on the same Lighthouse codebase and it may still report wrong LCP values in reports.

Thank you!

[patrickhulce]

If you uncheck the "Simulated throttling" checkbox to use "Applied throttling" instead, is the issue resolved?

[alexd-3d]

Checked.
Chrome Canary with 7.0.0 lighthouse shows correct LCP with turned off Simulated throttling, whereas Chrome 87 (Lighthouse 6.4.0) shows same wrong result for Simulation turned OFF and ON:

Not sure what mode PSI uses, but final LCP results for PSI (6.3.0 lighthouse) are even worse - and that's what worries me :(

[patrickhulce]

Thanks @alexd-3d!

This appears to be a bug in simulated throttling. It's in the same class of known issues where simulated throttling overzealously includes unnecessary resources and script execution that just happens to occur before LCP. Unfortunately there's not any immediate resolution for this that doesn't regress overall accuracy, it will take time.

[alexd-3d]

Thank you, @patrickhulce !
Good to know the issue is accepted and may be eventually fixed. Thanks once again and good luck!

P.S. For those who faced the same issue here's my personal solution: avoid using JS carousels that fit in mobile viewport at top of the page and strongly increase LCP time. Seems like issue is caused by DOM-change by carousels via moving DOM-nodes of images and creation of multiple additional wrappers. Slick and OWL do that. I've replaced them to super fast keen-slider and it works just as expected. No additional dynamic DOM-wrappers, no jQuery needed, no false LCP events.

[paulirish]

See also https://chromium.googlesource.com/chromium/src/+/master/docs/speed/metrics_changelog/lcp.md

The "ignores removed content by default" change definitely affects carousels and probably resolves this issue.