You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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)
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 👍
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
The text was updated successfully, but these errors were encountered: