We've been using the origin-trial on a few surfaces of GitHub, with pretty nice results.
A bit of background - we currently use a custom metric - Highest Priority Content which tries to appoximate "When the user saw the thing they cared about" - For hard navigation with SSR we fallback often to LCP (which is unideal and makes those metrics look a bit higher than they should) and for soft navigation (turbo or react based) we attach a MutationObserver that watches the dom for a specific attribute being added to the document (which is unideal since it deflates those metrics - dom entry !== paint).
Container Timing seems so far like a great replacement option for that metric, with more faithful numbers across loading profiles.
Overall:
Filtered to hard navigations
Filtered to soft navigations
Hard navigation - relatively inline. HPC uses the LCP events, but container timing likely includes elements that painted later swaying values a bit higher - we haven’t tried adding `containertiming-ignore at all yet, but based on where we are tracking, images loading slowly, mermaid diagrams, etc are likely the cause)
Soft navigations - I believe these are expected to be higher as we were measuring insertion time and not paint time before (via mutation observer) and likely indicates out style/layout costs are high (which they definitely are at times). These separate more at p95/99 - which I think is a good indication they're better tracking paint delays that our metrics today don't have a good way to note
The API was fairly simple to implement, and maps well to the other PerformanceObservers (and our HPC observers) fairly easily. We already implement soft navigation tracking (and I believe there's another proposal for soft-navigation observers too)
Overall, we're really excited to keep tracking these
We've been using the origin-trial on a few surfaces of GitHub, with pretty nice results.
A bit of background - we currently use a custom metric -
Highest Priority Contentwhich tries to appoximate "When the user saw the thing they cared about" - For hard navigation with SSR we fallback often to LCP (which is unideal and makes those metrics look a bit higher than they should) and for soft navigation (turbo or react based) we attach aMutationObserverthat watches the dom for a specific attribute being added to the document (which is unideal since it deflates those metrics - dom entry !== paint).Container Timing seems so far like a great replacement option for that metric, with more faithful numbers across loading profiles.
Overall:
Filtered to hard navigations
Filtered to soft navigations
Hard navigation - relatively inline. HPC uses the LCP events, but container timing likely includes elements that painted later swaying values a bit higher - we haven’t tried adding `containertiming-ignore at all yet, but based on where we are tracking, images loading slowly, mermaid diagrams, etc are likely the cause)
Soft navigations - I believe these are expected to be higher as we were measuring insertion time and not paint time before (via mutation observer) and likely indicates out style/layout costs are high (which they definitely are at times). These separate more at p95/99 - which I think is a good indication they're better tracking paint delays that our metrics today don't have a good way to note
The API was fairly simple to implement, and maps well to the other PerformanceObservers (and our HPC observers) fairly easily. We already implement soft navigation tracking (and I believe there's another proposal for soft-navigation observers too)
Overall, we're really excited to keep tracking these