feat(browser): Report web vitals for bfcache restores - #23750
Draft
logaretm wants to merge 2 commits into
Draft
Conversation
… dropped
`withoutBfcache` dropped every metric web-vitals reported after a
back/forward-cache restore. That was the right call while there was
nothing to attach them to: a restore reuses the frozen document, so the
values would have landed on the span the page had before it was frozen.
Now that a restore gets its own navigation span, they have a correct
parent, so the drop becomes an option rather than a hard rule:
webVitals: { bfcache: true }
Off by default. A restore is near-instant, so its vitals are a different
population from page load vitals, and the earlier concern about skewing
aggregates still applies to anyone who has not decided how to treat them.
`browser.navigation.type: bfcache` makes them separable once enabled.
Reporting per navigation rather than per page load is now what the
tracker flag means, since bfcache restores need it for the same reason
soft navigations do. `reportAllChanges` is switched off for either, since
the per-navigation path relies on each reported value already being final
for its navigation.
Verified end to end in Chrome 152: a restore emits LCP and CLS parented
to the bfcache navigation span on the restore's own trace, and a
bfcache-ineligible back navigation still falls back to a page load.
A navigation span whose idle timeout has not elapsed when the document
goes away was reaching Sentry as a rootless trace: its children had been
streamed while the page was alive, but the root span never arrived.
`registerBackgroundTabDetection` is meant to be the safety net, but it
listens for `visibilitychange`. Measured on a same-tab cross-document
navigation in Chrome 152, the order is:
pagehide (persisted=true) -> visibilitychange (hidden)
`pagehide` comes first and freezes the document into the bfcache, so a
root span ended on `visibilitychange` is ended on a page that can no
longer send, and it is stranded on its own. That is also why the
cancellation never appears in the debug log: it is logged from a frozen
document.
`pagehide` is the last point at which a document can still send, so the
idle span is ended there instead, which also puts the root in the same
final batch as the remaining children. The trace then arrives whole or
not at all, rather than headless.
Verified against a real project: rootless traces appear without this and
consistently do not with it. Trace delivery volume is unchanged (7-8 of
10 traces over three runs each way), which is expected - this changes
whether the root travels with its children, not how much gets through.
The traces that go missing entirely are a separate problem: four envelope
requests per run are killed with `net::ERR_ABORTED` during unload, which
points at the `keepalive` budget in `fetch.ts` rather than at span
lifecycle.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
注册 for free
to join this conversation on GitHub.
Already have an account?
登录 to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reports web vitals for back/forward cache restores, which we dropped outright before.
Now that a restore gets its own navigation span in #23748, the vitals have a correct parent, so the hardcoded
withoutBfcachedrop becomeswebVitals: { bfcache: true }. Off by default, since a restore is a different population from a page load.Also ends the active idle span on
pagehideinstead ofvisibilitychange, which fires after the page is already frozen and can no longer send. That was producing rootless traces.Stacked on #23748.