Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lighthouse isn't consistent about Layout Shifts from IFRAMEs #11500

Closed
nicjansma opened this issue Sep 30, 2020 · 2 comments
Closed

Lighthouse isn't consistent about Layout Shifts from IFRAMEs #11500

nicjansma opened this issue Sep 30, 2020 · 2 comments
Assignees

Comments

@nicjansma
Copy link

Provide the steps to reproduce

  1. Run LH on https://nicj.net/dev/cls/cls-demo-from-frame.html

What is the current behavior?

The page has a single IFRAME which causes Layout Shifts every second. The CLS for that IFRAME is noted at the top of the page (by using Layout Instability API). You should see a "CLS: nnn.nnn" number increasing every second:

image

(The top-level page which embeds the IFRAME also reports on its own CLS from Layout Instability API. This number should be always "CLS: 0" because today CLS isn't "surfaced up" to parents without additional work.)

The page takes approx 5 seconds to load because of an image that is delayed for 5 seconds. During this time, CLS in the IFRAME should be increasing. By the end of the 5 seconds, the CLS is commonly > 1.0.

Lighthouse Performance Audit reports a CLS of 0, indicating it doesn't take IFRAME layout shifts into account of the top-level CLS:

image

However, in the diagnostics section it does show shifts from that IFRAME:

image

What is the expected behavior?

According to the Layout Instability Spec, CLS should take into account subframes:

The cumulative layout shift (CLS) score is the sum of every layout shift value that is reported inside a top-level browsing context, plus a fraction (the subframe weighting factor) of each layout shift value that is reported inside any descendant browsing context.

The subframe weighting factor for a layout shift value in a child browsing context is the fraction of the top-level viewport that is occupied by the viewport of the child browsing context.

I would expect Lighthouse to report a number similar-ish to what the IFRAME is reporting, probably reduced proportionally by the size of the IFRAME in the viewport. Instead, it reports 0.

Lighthouse seems internally inconsistent as it's currently reporting CLS=0 while there are details of shifts from that IFRAME in the Diagnostics section.

Environment Information

  • Affected Channels: Dev Tools (also seems to be the same in PSI and WebPagetest)
  • Lighthouse version: (in Chrome)
  • Chrome version: Version 87.0.4278.0 (Official Build) canary (x86_64)
  • Node.js version: n/a
  • Operating System: All

Related issues

I'm not sure if this is affected by #11311

@patrickhulce
Copy link
Collaborator

Thanks for filing @nicjansma! #11311 is indeed the root of this problem. The inconsistency with the diagnostics section is a great point though that we should fix in the meantime 👍

@adamraine
Copy link
Member

We use CLS from all frames now #12554.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants