[css-view-transitions-2] Define impact of cross-document view transitions on Core Web Vitals

[yoavweiss]

Note

🤖 This issue was filed by an AI agent (Claude, running in the Pi coding agent) on behalf of @yoavweiss, while migrating still-relevant issues out of WICG/view-transitions before that repository is archived.

This is a migration of an existing discussion, not a new proposal. The original author is credited below and the original thread is linked. @yoavweiss is accountable for it — please correct, retitle, or close if the migration is misjudged.

Migrated from: WICG/view-transitions#57 — originally filed by @khushalsagar on 2021-09-09.

---

Cross-document view transitions have shipped since this was first raised, but the interaction with Core Web Vitals was never specified. The original concern, restated:

We need to make sure that CWV metrics like Largest Contentful Paint (LCP) or First Contentful Paint (FCP) are not delayed for cross-document transitions.

Similarly the feature should be a no-op for Cumulative Layout Shift (CLS). Computing this metric should only be dependent on the start/end state, as if the browser switched to the end state directly without an animation.

First Input Delay (FID) should also not be impacted. This is good to keep in mind if we end up having to ignore input during the transition.

What's still unspecified

FCP / LCP. For a cross-document transition, the new document's first paint happens while the old document's snapshot is still being displayed and animated. Neither css-view-transitions-2 nor paint-timing says whether paint timing should be measured at the point the new content is first painted (i.e. under the outgoing snapshot), or when the transition settles and the content is actually visible to the user. These can differ by the whole transition duration, and they are meaningfully different things to report.

CLS. The original requirement — that CLS should be computed from start/end state as if no animation occurred — isn't stated anywhere. The transition pseudo-elements animate transform in the snapshot containing block rather than laying out in the document, which suggests they shouldn't contribute layout shift, but it would be good to have that be explicit rather than an implementation artefact.

FID → INP. FID has been retired in favour of INP, which changes the analysis rather than removing it. Two things have improved since 2021: the pseudo-elements no longer block hit-testing (they behave as pointer-events: none), and scoped view transitions mean a transition need not freeze the whole document. But rendering suppression for view transitions still sits in the interaction-to-next-paint path when a transition is started in response to an interaction, which is exactly the INP measurement window.

Note on venue

Filed here because View Transitions is specified in this repo and the VT editors would need to weigh in. If the resolution turns out to need normative changes to the metric definitions themselves, follow-ups in w3c/paint-timing and w3c/layout-instability would be the right next step. Adjacent: w3c/navigation-timing#193.

Original issue text

We need to make sure that CWV metrics like Largest Contentful Paint (LCP) or First Contentful Paint (FCP) are not delayed for cross-document transitions.

Similarly the feature should be a no-op for Cumulative Layout Shift (CLS). Computing this metric should only be dependent on the start/end state, as if the browser switched to the end state directly without an animation.

First Input Delay (FID) should also not be impacted. This is good to keep in mind if we end up having to ignore input during the transition.

@vmpstr added: "it would also be recorded at the beginning of the animation, since we already know the end state."