From field data to traces: audit web performance

In this scenario, a Next.js application serves public pages and a signed-in product area. Local tests look healthy, yet support reports slow interactions on mobile and Core Web Vitals vary widely between routes.

The team has already applied the obvious optimisations. Another checklist will not reveal where time is actually being lost, so the audit starts with an observed user experience and works back to a cause the team can verify.

We choose an affected journey: open an item, change a filter, then render the results. Field data shows which population experiences the slowdown; a controlled test then replays the sequence with representative network and CPU constraints.

Poor INP may come from an expensive React render, a long task or a third-party script. A poor LCP may be caused by server response time, late resource discovery or image decoding. The metric narrows the investigation, but it does not identify the culprit on its own.

The investigation ends with a testable hypothesis for a specific population and action. A targeted fix does not claim to speed up every page.

A field measurement becomes actionable when it includes a normalised route, build, viewport class, navigation type, page ID and timestamps. Those dimensions identify the relevant segment without collecting unnecessary personal data.

They do not prove that a Web Vital corresponds to a particular trace span. Exact correlation requires an ID created on the server, exposed to the browser and propagated through the relevant requests. Without that mechanism, Next.js and OpenTelemetry traces can still be compared for the same route, build and time window, but the analysis must be described as a comparison rather than a one-to-one link.

import { onCLS, onINP, onLCP, type Metric } from 'web-vitals'

let registered = false

type ViewportClass = 'mobile' | 'desktop'

function getViewportClass(): ViewportClass {
    return matchMedia('(max-width: 767px)').matches
        ? 'mobile'
        : 'desktop'
}

export function registerWebVitals(normalizedRoute: string) {
    if (registered) return
    registered = true

    const pageId = crypto.randomUUID()
    const report = (metric: Metric) => {
        const payload = {
            route: normalizedRoute,
            build: process.env.NEXT_PUBLIC_BUILD_ID ?? 'dev',
            viewport: getViewportClass(),
            navigation: metric.navigationType,
            pageId,
            pageStartedAt: performance.timeOrigin,
            reportedAt: new Date().toISOString(),
            metric: {
                id: metric.id,
                name: metric.name,
                value: metric.value,
                rating: metric.rating,
            },
        }

        const body = new Blob([JSON.stringify(payload)], {
            type: 'application/json',
        })
        navigator.sendBeacon('/api/vitals', body)
    }

    onCLS(report)
    onINP(report)
    onLCP(report)
}

Register this callback once per document load; this snippet does not report each App Router soft navigation as a separate measurement. The application must inject the build ID at deployment. A sound diagnosis depends on consistent dimensions and an honest statement of confidence.

The audit moves one journey at a time. Each step produces something the team can inspect or measure: a segment, trace capture, hypothesis, diff or production result.

1. 01

   Validate the field signal

   Validate collection, split the data by route and isolate the affected population.

2. 02

   Reproduce the journey

   Use a stable scenario, a credible device profile and the same build.

3. 03

   Find where the time is going

   Combine a flame chart, React Profiler and server spans when the request is instrumented.

4. 04

   Address one cause

   Shorten a long task, move a calculation, remove a request waterfall or prioritise a resource.

5. 05

   Measure after release

   Compare the same segment on the new build and keep a regression check in place.

If the expected signal does not move, the hypothesis is rejected and documented. That prevents the team from repeating an appealing but ineffective optimisation.

Product, design and engineering use the same evidence. An alert names the affected population and action; a PR states the expected signal. Support can pass along the route, build and viewport context without asking the user to open DevTools.