Timing and performance events
Universal Analytics had a dedicated user-timing (timing_complete) feature. GA4 has no direct equivalent, so site-speed and timing measurement is done with custom events carrying numeric parameters, often sourced from the browser's Performance APIs and Core Web Vitals. This page explains how to measure timing in GA4 without inventing benchmarks, and how Web Vitals map onto custom events.
What changed from UA
Universal Analytics offered user timings (the timing_complete hit) for measuring durations like load time. GA4 removed that as a built-in feature. To measure timing now, you send custom events with numeric parameters representing milliseconds.
The data usually comes from standardised browser APIs — the Performance and PerformanceObserver interfaces — rather than ad-hoc timers.
Web Vitals and Performance APIs
Core Web Vitals (LCP, INP, CLS) are measured in the browser via the Performance APIs and can be forwarded to GA4 as events, often using Google's web-vitals library. Each vital becomes an event with a value parameter you can aggregate. Report distributions, not invented thresholds — describe how the metric is defined and let your own data set the baseline.
- No built-in GA4 timing hit; use custom events
- Source values from Performance / PerformanceObserver
- Web Vitals (LCP, INP, CLS) can be sent as events
How it appears in analytics and logs
Timing events expressed as custom metrics let you watch how load and interaction latency trend — slow trends point to performance regressions.
Diagnostic use case
Capture page-timing and Web Vitals in GA4 using custom events fed from browser Performance APIs, since UA's timing hit was removed.
What WebmasterID can help detect
WebmasterID's observability surface can pair timing events with traffic so you see performance and behavior in one first-party view.
Common mistakes
- Expecting a GA4 equivalent of UA's user-timing report.
- Quoting invented 'good' thresholds instead of your own distribution.
- Sending timing values without a consistent unit.
Privacy and accuracy notes
Timing values are durations, not personal data. Web Vitals derive from the user's own session and need no cross-site identifiers. Educational, not legal advice.
Related pages
- Custom events: tracking what matters to you
Custom events capture meaningful actions a pageview cannot — a CTA click, a signup, a video play, a form submit. The value is in a consistent naming taxonomy and well-chosen properties. The risk is putting personal data into event names or properties, which turns analytics into surveillance. This page covers both.
- Event parameters: adding context safely
Event parameters are the key-value details attached to an event: which button, which product, which step. They are what turns a bare event name into something analysable. The craft is choosing a small, stable set of parameters with consistent names and values — and the discipline is keeping every one of them free of personal data, because parameters are stored and widely visible in tooling.
- The exception event (error tracking)
An exception event records that a client-side error occurred — a JavaScript error or a failed operation. GA4 supports an exception event for this. Tracking errors in analytics ties reliability to behaviour: you can see which pages throw and whether errors correlate with drop-off. The catch is that error messages and stack traces can leak personal data, so what you capture needs care.
- Website observability
Pair performance signals with traffic.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.