Increase Sentry pageload sample rate for reliable Web Vitals

[pettinarip]

Summary

• Replace flat tracesSampleRate: 0.01 with a tracesSampler function in instrumentation-client.ts
• Pageload transactions sampled at 10% (up from 1%) for more reliable Web Vitals data
• All other transactions remain at 1% to avoid quota impact

Context

Sentry Web Vitals insights showed many pages with exactly "100 pageloads" — this was Sentry extrapolating from a single captured trace (1 × 1/0.01 = 100). Drilling into individual pages confirmed only 1 actual trace, making performance scores statistically unreliable.

Test plan

• Verify Sentry Web Vitals insights show more pageload samples after deploy
• Monitor Sentry quota usage to ensure 10% pageload sampling doesn't exceed limits

[netlify]

✅ Deploy Preview for ethereumorg ready!

Name	Link
🔨 Latest commit	77040c3
🔍 Latest deploy log	https://app.netlify.com/projects/ethereumorg/deploys/69cecd3a8962490008b22620
😎 Deploy Preview	https://deploy-preview-17740.ethereum.it
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	7 paths audited Performance: 56 (🟢 up 1 from production) Accessibility: 94 (no change from production) Best Practices: 100 (no change from production) SEO: 98 (🔴 down 1 from production) PWA: 59 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[wackerow]

@pettinarip

Review: tracesSampler pageload check won't fire

The intent here is correct — sampling pageloads at 10% for reliable Web Vitals data while keeping everything else at 1%. However, the samplingContext.attributes?.["sentry.op"] === "pageload" check will never be true, making this functionally identical to the original tracesSampleRate: 0.01.

Why it fails

Tracing through the SDK source (@sentry/core@10.5.0):

1. _startRootSpan builds samplingContext.attributes from { ...spanArguments.attributes } — a spread of explicitly passed attributes only (trace.js:411)
2. tracesSampler is called with those attributes (trace.js:425–434)
3. new SentrySpan(...) is constructed after sampling, and it is only here that [SEMANTIC_ATTRIBUTE_SENTRY_OP]: spanContext.op gets written into attributes (sentrySpan.js:47)

So sentry.op is never present in samplingContext.attributes at sampling time — it is a post-sampling side effect.

What to check instead

The pageload span is started with this explicit attribute (from browserTracingIntegration.js):

attributes: {
  [SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN]: 'auto.pageload.browser',
}

This is available in samplingContext.attributes at sampling time.

The fix:

tracesSampler(samplingContext) {
  // 10% of pageloads for reliable Web Vitals data
  if (samplingContext.attributes?.["sentry.origin"] === "auto.pageload.browser") {
    return 0.1
  }
  // 1% for everything else
  return 0.01
},

Caveat: The beforeSampling event hook (trace.js:414) runs just before sampling and allows mutation of spanAttributes. It's possible @sentry/nextjs registers a hook there that injects sentry.op — I didn't fully audit the Next.js integration layer. A quick sanity check with Sentry debug logging in a preview deploy would confirm either way.

---

Reviewed by Claude (claude-sonnet-4-6)

[wackerow]

bump @pettinarip

[pettinarip]

@wackerow thanks. Here is the analysis I made and test to double check it works

---

The conclusion doesn't hold for @sentry/nextjs specifically.

The review correctly traces the generic @sentry/browser code path, but @sentry/nextjs takes a different path — it explicitly includes sentry.op in the attributes object before the span is created, so it's available at sampling time.

Verified locally by logging samplingContext inside tracesSampler:

{
  name: '/',
  sentry.op: 'pageload',
  sentry.origin: 'auto.pageload.nextjs.app_router_instrumentation',
  sentry.source: 'url'
}

The current implementation works as intended.