Provide the steps to reproduce
- 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:
(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:
However, in the diagnostics section it does show shifts from that IFRAME:
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
Provide the steps to reproduce
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:
(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:However, in the diagnostics section it does show shifts from that IFRAME:
What is the expected behavior?
According to the Layout Instability Spec, CLS should take into account subframes:
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
Related issues
I'm not sure if this is affected by #11311