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
{{ message }}
Repository navigation
Commit d28566e
Browse filesBrowse the repository at this point in the historyBrowse files
authored
feat(nextjs): Wait for the resumed part of a document before starting the pageload (#25142)
Builds on #25141.
When a document resumes a prerendered shell, its `sentry-trace` tag sits
at the start of the resumed part, which arrives after the SDK has
started. In a local demo six of seven visits found no tag at init, so
the pageload could only link the server trace instead of joining it.
The app router pageload now continues whatever tag is in the document,
last one wins. In apps with `cacheComponents` enabled, if there is no
tag, no `Server-Timing` trace and the document is still streaming, it
waits for the tag before creating the pageload span. Other apps keep the
immediate start: without `cacheComponents` a tag is either in `<head>`
from the start or never comes, so waiting only held the pageload back.
The wait ends at `DOMContentLoaded` or after 10 seconds. The span still
starts at the time origin and gets its children from the performance
timeline, so it looks the same as before, only inside the server's
trace. No tag by the end of parsing means a fresh trace, which is the
fully static case.
A client-side navigation during the wait starts the pageload with a
fresh trace first, so the navigation ends it like any pageload it
interrupts, as today. Started later, the pageload would end the
navigation span instead. The pageload keeps the URL the document was
loaded with, even if the navigation already changed it.
Waiting was chosen over moving a started span to another trace. That
needs core changes and does not work with span streaming once children
are flushed. The cost: fetches, errors and clicks between SDK start and
the resumed part are not attached to the pageload. The `Server-Timing`
follow-ups (JS-3864, JS-3866) remove that window where the header can be
set.
<img width="2240" height="1904" alt="figure-ppr"
src="https://github.com/user-attachments/assets/c6049dff-1ceb-4a09-9467-b2436648cf6c"
/>
Fixes#24944
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Co-authored-by: s1gr1d <32902192+s1gr1d@users.noreply.github.com>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,7 +33,7 @@
33
33
34
34
- **feat(nextjs): Never emit trace meta tags from a prerender ([#25141](https://github.com/getsentry/sentry-javascript/pull/25141))**
35
35
36
-
Pageloads of apps with `cacheComponents` enabled are connected to their server request again. Pages that Next.js prerenders no longer carry trace information, so a cached page can no longer connect visitors to a request that was not theirs. This also applies to ISR pages.
36
+
Pageloads of apps with `cacheComponents` enabled are connected to their server request again. Pages that Next.js prerenders no longer carry trace information, so a cached page can no longer connect visitors to a request that was not theirs. This also applies to ISR pages. The pageload waits for the trace information when it arrives with the part of the page that streams in after a cached shell.
37
37
38
38
If you set up OpenTelemetry yourself and register `SentryPropagator`, register `NextSentryPropagator` instead and pass your tracer provider to `markPrerendersOnTracerProvider`, so that your prerendered pages carry no trace information either.
0 commit comments