Repository navigation
feat(sveltekit): Mark pageloads of prerendered pages - #26301
Merged
Merged
Conversation
mydea
approved these changes
Nov 11, 2026
Contributor
size-limit report 📦Compared: f4bd435 (PR test merge using develop at 187ee90) Against: 187ee90 (develop) · base run #65693 ✅ Baseline matches: this diff contains only this PR's changes.
|
This was referenced Nov 11, 2026
s1gr1d
added a commit
that referenced
this pull request
Nov 13, 2026
**Why:** Visitors of a Nuxt page cached by a route rule (`cache`, `swr`, `isr` on Vercel/Netlify) continued the server trace of the request that rendered it. Like Next.js (#25318) and SvelteKit (#26301), these pages now get a `sentry-cache-origin` meta tag in place of the trace tags. The pageload is `static` and links the render if it was sampled. `isr` only counts as cached on presets with a platform cache: on `node-server`, Nitro renders `isr` pages per request. Tested on a Vercel deploy. **How to review:** Start with `runtime/utils/pageMetaTags.ts` (server decision) and `runtime/utils/cacheOriginPageload.ts` (pageload). **Unsure about:** `withCacheOrigin` now exists in Next.js, SvelteKit and Nuxt. I plan to share it from `@sentry/browser` in a follow-up. Example with the UI changes from getsentry/sentry#130771 <img width="1374" height="390" alt="image" src="https://github.com/user-attachments/assets/d066316e-63ec-44ba-8105-3acdbeb46fe7" /> https://sentry-4x3dkn58u.sentry.dev/explore/traces/trace/e7492219ab72481989d6a2cd670fe8d9/ Linear: [JSSDK-36 ](https://linear.app/getsentry/issue/JSSDK-36/nuxt-rendering-modes) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
s1gr1d
added a commit
that referenced
this pull request
Nov 13, 2026
Stacked on #26301. **Why:** Vercel ISR (`config.isr`) caches the HTML of one request and serves it to every visitor until it expires. That HTML holds the live `sentry-trace` and `baggage` tags of the render, so every visitor continued the same old server trace. Next.js had the same bug, fixed in #25141. Now a page that Vercel renders for its ISR cache gets a `sentry-cache-origin` tag with the render's `sentry-trace` in place of the trace tags. The pageload starts its own trace, gets `page.server_rendering.type: static`, and links the render with a `cache_origin` link, as in Next.js (#25318). To detect an ISR render, `sentryHandle` reads the `x-vercel-isr` request header. Vercel sends it to every invocation of an ISR function, also for background revalidations and for routes that get `config.isr` from a layout. The adapter's own `__pathname` marker is gone before Kit sees the request, and `handle` cannot see the route config (tested both on a Vercel deployment). Like a `use cache` hit, the pageload links only a sampled render. An unsampled render still marks the pageload as `static`. A page with `ssr = false` gets no tags, as in the build. **How to review:** Start with `getCacheOrigin` in `handle.ts`. It returns the render's trace (ISR), `''` (build) or `undefined` (rendered for this request only). Then `withCacheOrigin` in `client/traceMetaTags.ts`. The two browser-tracing variants only wrap their existing span options. **Unsure about:** A client can send `x-vercel-isr` to a normal SSR route, and the function sees it. That only changes the pageload of the request that sends it: it links its own server request instead of continuing it. I think that is acceptable. I did not check draft mode (`bypassToken`), where Vercel does not cache the render. Example with the UI changes from getsentry/sentry#130771 (a visitor that got an already happened ISR render): <img width="1378" height="418" alt="image" src="https://github.com/user-attachments/assets/842594fd-38cc-418f-b981-369da8305375" /> https://sentry-4x3dkn58u.sentry.dev/explore/traces/trace/63b1dbe5fe3849f2b13df81530857c03/ Linear: [JSSDK-37](https://linear.app/getsentry/issue/JSSDK-37/sveltekit-page-options)
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Why: Pageloads of pages prerendered during
vite buildlook like they have no server instrumentation. Now these pages get an emptysentry-cache-originmeta tag, and the pageload getspage.server_rendering.type: static. Unlike Next.js (#25318), the pageload gets no link, because the SDK does not reliably send spans from the build.Unsure about: To leave out
ssr = falseshells, the server checks fornode_ids:in Kit's boot script, which Kit writes only for server-rendered pages (source).Example (with UI changes from getsentry/sentry#130771 applied) or pre-rendered, static page: https://sentry-4x3dkn58u.sentry.dev/explore/traces/trace/97190404f66048bd89da29cc0a21304f/
Linear: JSSDK-37