Summary of findings from previous Chromium Origin Trial

[mmocny]

As Chromium prepares for a new Origin Trial for this feature, and we have revamped substantial parts of the initial implementation, it would be useful to summarize the motivations for the changes, at least quickly.

[mmocny]

• Task Attribution:

  • v1 tried to store task ids and "back pointers" from each task to its initiator.
  • This could be followed like a linked list to the original initiator, and use that to look up data in a map.
  • v2 now establishes an "InteractionContext", assigns that value to the task attribution (akin to AsyncContext.Variable), which is automatically carried forward.
  • The v1 feature was potentially more flexible/powerful but in practice added overhead and needed to be support a limited depth, anyway. v2 is easier/cheaper and matches the public API proposal better.
  • Beyond this, since last original trial several new scheduling mechanisms were added (e.g. <link onload>) which we found were commonly used, though there are still gaps remaining (e.g. fetch response.blob()).

• Interactions:

  • Lots of feedback from developers requesting expanding the concept of interaction to more event types, and/or consolidation with Event Timing Interaction.
    • For example: requests for pointerdown, form submit, native drag&drop...
    • There are also sites that navigate with gestures: swipe, scroll, etc.
  • This work is mostly not yet completed, since the common case of click is sufficient to test the more important parts of the trial. Expanding scope to more interactions was deemed to fix last.
  • v1 only supported a single recent interaction (because each new interaction would reset things) while v2 supports multiple interactions overlapping in time/scheduling. There are still certain constraints imposed, such as "only the context for the current url" will emit entries-- but this is expected to become further relaxed.

• Paint Timing Entries:

  • Replaced "soft" largest-contentful-paint timings with a new entry: interaction-contentful-paint.
  • Replaced "soft" paint timings by just implementing PaintTimingMixin directly on soft-navigation entry.
  • This offered a few perceived advantages:
    • We no longer rely on "resetting" existing those entries, with a soft vs non-soft "mode", which risked leaking/reporting paints as non-soft if things went wrong (and we had a bugs of this type).
    • Developers listening to the API needed to opt-in to "soft" versions and then fork (based on navigationId), anyway
    • Semantically, the types of paints reported for "soft" versions of paint as not equivalent to "hard", even if they had many similarities.
  • Although most developers participated in the trail specifically for Soft navigation detection, some developers requested the ability to track Interaction -> Contentful Paint entries even without navigation changes, which is useful for rich applications (beyond INP).

• Interaction --> Paint tracking, moved from "global" to "per context":

  • In v1, we would assign a "bit" on each Node to mark it as "modified by an soft navigation".
    • We actually did this even before we knew the interaction would be a navigation, so it was more of a "modified by an interaction".
  • This bit persisted forever and would accumulate over time.
    • The first interaction would thus work better to track attribution than subsequent interactions-- especially when sites used shared layouts or when navigating back through history stack.
    • The "bit" was assumed sufficient to differentiate attributable paints to the most-recent-interaction, but really differentiated all-historical-interactions.
  • This issue was made worse by the use of a literal "reset" of all historical paint timings, which would immediately re-create for all visible content, and we relied on the "bit" to know which to re-report.
    • In other words, we intended to only record new content added by interactions, but we would actually immediately re-record all historically added content.

• PaintTimingDetectors improved for dynamic updates.

  • The PaintTimingDetectors were designed for hard LCP, and expected to work only for cases of blank page receiving brand new content.
  • There are some existing limitations with dynamically updating pages during load, but mostly this doesn't affect the single largest hard-LCP candidate.
  • We needed to support dynamic updates to existing content, and that meant re-recording new paint timings for existing records.
    • Note: Some of this work is still in progress.

• PaintTimingDetectors and Container Timing

  • One of the more significant deficiencies from v1 was that only Nodes which were directly modified by interactions would track attribution. This caused issues:
    • You had to mark every single node directly, which meant observing dom changes at every level of the dom tree as soon as it was touched. This came up as a regression in some rendering benchmarks.
    • Some web frameworks created dom trees that slipped passed our observation (e.g. template cloning, using innerHTML, or DOMparser or detached document streaming, etc)
    • Dynamic page updates would often build up dom in a disconnected state, and then attach it as a fragment/tree.
    • Updates to existing dom might affect more than just the node modified. E.g. updating inline styles or data- attributes.
  • To resolve this, we added support for "Container Timing".
    • Instead of marking nodes as densely and eagerly as possible, change to mark as lazily and sparsely as possible.
    • Interactions modify parts of the dom tree and this marks a new "Container Root", and then all paints within a container tree attribute up to the root.
    • Note: Some of this work is still in progress.
  • There is a related API proposal to expose Container Timing to web developers via explicit attribution, extending Element Timing.
    • The specific implementation of Soft Navigations Container Timing differs, as we optimized for a different use case, but we aim to try to consolidate these implementations where possible.