What a browser can reveal on page load

The load of a page is already a measurement. A beacon — the small event a page sends to a server — comes later, and it is optional. Before it is sent, the browser has timed the navigation, listed every request, and exposed a set of client signals to the page itself.

The lab on this site shows those layers side by side. This note is the map.

The navigation is a timeline

performance.getEntriesByType("navigation") returns one entry for the document. From it you can read DNS, the TCP connection, TLS, time to first byte, and the moments the DOM became interactive, content loaded, and the load event finished.

Those numbers are how the page experienced the network. They are not a guess reconstructed by a tag manager after the fact.

Core Web Vitals sit on that same timeline. Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint are observed with PerformanceObserver. They describe the visit, and they are available in the page without calling home.

Every request leaves a row

Resource Timing records each fetch the document makes: the page itself, styles, scripts, fonts, images, and later the beacon. Each row has a URL, an initiator type, a start time, and a duration. Group the rows by host and the split is obvious. The same host as the page is first-party. Any other host is third-party.

Transfer size is sometimes zero. That usually means the response was cached, or the other server did not grant Timing-Allow-Origin, so the browser hides the body size. The request still happened. The missing number is part of the story.

This site does not load third-party tags. The network panel should be mostly this origin, including POST /api/collect once you allow a beacon. If a vendor script were added, its domain would show up on its own.

What the page can read about the client

A handful of ordinary APIs describe the environment the page is running in:

• navigator.userAgent, and where the browser supports them, User-Agent Client Hints
• screen size, viewport, and device pixel ratio
• language and time zone
• the Network Information API, when it exists (effectiveType, downlink, round-trip time, save-data)
• document.referrer
• campaign parameters on the URL (utm_source and the rest)
• the names of cookies and localStorage keys — presence, not a dump of values

None of that requires a request. It is already in the browser. That is why the lab can show it before any consent decision: reading it on the device is not the same as sending it.

What the browser cannot see

The server that receives a beacon sees a different slice. It sees when the request arrived, the User-Agent header as the client sent it, and whatever an edge added: a forwarding header, a country, a colo. On a laptop those headers are often absent. That absence is informative. IP-derived fields are server-side enrichment, not a field the page filled in.

Open the lab and grant consent. Then watch /api/collect appear in the network list, and the enriched record appear beside the body you sent.