Load Bands
asset.js measures how long the page took to reach a usable state and places that measurement in one of four named bands. The board shows how many visits fell into each band during the selected period.
How the timing is measured
The script reads a timing value from the performance API at the point it executes, relative to navigation start. This gives a rough measure of elapsed time from when the browser began loading the page to when DOMContentLoaded fired and the script ran. The result is in milliseconds.
The millisecond value is mapped to a band. The raw value is not included in the beacon. The band name is included. This coarsens the timing from a precise measurement to a category, which reduces the identifying potential of the field and produces a board column that is easier to reason about than a distribution of raw millisecond values.
The four bands
Fast: page reached DOMContentLoaded in under approximately one second. These pages felt instant to the visitor. Medium: one to three seconds. Perceptible but acceptable on most connections. Slow: three to ten seconds. Visitors likely noticed the wait. Stalled: over ten seconds. Pages in this band have a meaningful probability of abandonment before DOMContentLoaded.
The exact millisecond thresholds are set in the script source. The current values are visible on the Features page. The four-band model is designed so that each band corresponds to a qualitatively different experience — not arbitrary quantiles, but points where user perception of speed changes.
What you can infer from the distribution
A high share of Fast visits across all pages tells you the site loads quickly for most visitors under real conditions. A page that is predominantly Fast in aggregate but shows a spike of Slow visits on specific days may have had a performance incident or a heavy resource added temporarily.
A page where Slow and Stalled visits dominate despite the page feeling fast in your own testing may be receiving traffic from connections or devices that differ significantly from your test environment — slower network types, older hardware, geography with higher latency to your host. The band distribution tells you the scale of the gap; finding the cause requires server logs or a dedicated performance tool.
What the band does not tell you
The load band is a single coarse measure. It does not tell you the server response time, the time to first byte, the time to first paint, the Largest Contentful Paint, or the Cumulative Layout Shift. Those measurements require instrumentation beyond a minimal beacon script.
The band also does not tell you why a load was slow. A Stalled visit could be caused by a large synchronous script, a slow server, high geographic latency, a throttled mobile connection, or a combination of those. The band tells you that the load was slow by the visitor's clock. Diagnosing the cause is a separate step.
Troubleshooting
If all visits appear in the Fast band even for a page you know loads slowly in your testing, check whether your tests hit a CDN edge cache that returns a prebuilt response. Those cached responses genuinely load fast for the visitor. The measurement is from the visitor's device, not from a synthetic test at a fixed location. Real user traffic from slower connections or farther geographies will produce different band distributions.
If no speed data appears for a page — all visits show no band assignment — confirm that asset.js is loading and firing on that page. Check the Network panel for a successful request to statelessid.com. If the beacon fires but no speed column data appears, the performance API may be unavailable in the browser environment. Some automation tools and headless browsers do not expose performance.now().