Page timing and Navigation Timing events
Page timing events record how long parts of a page load took — DNS, connection, time to first byte, DOM content loaded, and full load. The browser's Navigation Timing API exposes these durations precisely, and you can send them as analytics events to monitor real-world speed. They are pure timings, so they are among the safest events to collect, carrying no information about who the visitor is.
What this means
The browser's Navigation Timing API (and the newer PerformanceNavigationTiming entry) records timestamps across the page-load lifecycle: domainLookupStart/End, connectStart/End, responseStart (time to first byte), domContentLoadedEventEnd, and loadEventEnd. Subtracting these timestamps yields durations you can send as timing events to see how fast real visitors load each page.
What to record and why
Useful derived timings include DNS lookup, connection time, time to first byte (server responsiveness), DOM interactive, and full load. Field timings beat lab tests because they reflect real devices and networks. Aggregate them by page and device class, not by visitor: a timing event needs only the metric name, the value in milliseconds, and a path — never anything identifying.
- Navigation Timing exposes load-lifecycle timestamps
- Derive DNS, connection, TTFB, DOM-ready, load
- Send name + ms + path; no identity
How it appears in analytics and logs
Rising time-to-first-byte points at server or network latency; a large gap between DOM-ready and load points at heavy scripts or images on that page.
Diagnostic use case
Record real-user load milestones (TTFB, DOM ready, full load) as events to spot slow pages and server-side bottlenecks across templates and regions.
What WebmasterID can help detect
WebmasterID can ingest load-timing signals as first-party events, so real-user speed sits next to engagement metrics without cookies or fingerprinting.
Common mistakes
- Reporting a single load number and hiding where time went.
- Confusing lab timings with real-user field timings.
- Adding visitor identifiers to a timing event.
Privacy and accuracy notes
Navigation Timing values are durations measured in the visitor's browser, not identities. Send the milestone name, value, and page path only. This is educational, not legal advice.
Related pages
- Tracking Core Web Vitals as events
Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — are field performance metrics you can record as analytics events. Google's open-source web-vitals JavaScript library measures them in real browsers and hands you a value and an id you can send as a custom GA4 event. This page covers what each metric means and how to model it as an event without any personal data.
- 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.
- 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.
- Website observability
Real-user load timings as first-party events.
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.