Set up a WebTracerProvider with a configured propagator and exporter; create a named tracer using provider.getTracer('web-vitals-instrumentation') for custom instrumentation separate from auto-instrumented spans.
Use the web-vitals library's onLCP, onINP, and onCLS callbacks to receive Core Web Vitals reports; inside each callback, start a span with the metric name (e.g., 'web_vital.lcp'), set span attributes for the value, rating (good/needs-improvement/poor), and id fields from the report, then immediately end the span.
Add event listeners for 'error' and 'unhandledrejection' window events; inside each handler, start a span (or use the active span if one exists) and call span.recordException(error) to attach the error details, then set span.setStatus({ code: SpanStatusCode.ERROR }).
Set resource attributes on the WebTracerProvider (service.name, app.version, deployment.environment) using a Resource object so that all spans carry consistent service identity for filtering in the backend.
Configure the BatchSpanProcessor with the OTLP HTTP exporter; set a short maxExportBatchSize and scheduledDelayMillis appropriate for browser usage (smaller batches export more frequently, reducing data loss on page close).
Handle page unload by calling provider.shutdown() in a 'visibilitychange' or 'pagehide' event listener using sendBeacon-based transport if available; this ensures pending spans are flushed before the browser context is destroyed.
Known gotchas
The default BatchSpanProcessor may not flush all pending spans before a page navigation or tab close; configure the exporter to use the sendBeacon API (available in some OTel HTTP exporter configs) or switch to SimpleSpanProcessor during development to ensure immediate export.
INP is reported by the web-vitals library as a final value when the page is hidden (not during the interaction); setting up the onINP callback with reportAllChanges: true provides intermediate updates but the final definitive INP value only fires on page hide.
OTel spans created in browser workers (Web Workers, Service Workers) run in separate JavaScript contexts without access to the main thread's tracer; separate provider initialization is required in each worker context, and linking worker spans to the main thread requires manual context propagation via postMessage.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp