Navigation Timing (navtimings) API. Further, Blockmetry calculates the duration some steps took during loading from the navtimings metrics.
The raw data and calculated metrics are exported in the Blockmetry analytics record.
Because the data is collected on a per-page basis, it can be queried and segmented as required by a data analyst, for example by device, time, country, etc.
Let’s start with the navtimings overview from the spec:
All events are collected by Blockmetry for each page load, as a map (dictionary) stored in the
PerfMetrics property of the record. The map is keyed by event name (e.g.
connectEnd) and the value stored is the time difference between the event and
navigationStart (i.e. not the actual timestamp generated by browsers). This normalization means
navigationStart is always stored as zero, and all events will be positive numbers in relation to
Additionally, Blockmetry calculates certain durations based on the raw data to aid analysis. These are stored in the
NavTimingsComputedproperty of the exported Blockmetry record.
Two example calculated metrics Blockmetry calculates by default:
The “time to first byte” (TTFB) metric, which is
responseStart - navigationStart. Note that because of the normalization of the raw data described above, TTFB is equal to responseStart.
“Processing overall”, defined as
loadEventStart - responseEnd.
Blockmetry can be extended to calculate other metrics at the time of collection. Please contact your account manager to do so.
The navigation timing API depends on high-resolution monotonic timers that should translate into later events being recorded at later time points than earlier events. However, that is not always the case (in Blockmetry, this is seen around 1% of the time in some browsers). Blockmetry detects non-monotonic navigation timing measurements, and our processing will reject all navtiming metrics and will not store any in the produced Blockmetry record. This means that not all Blockmetry records will contain navtiming measurements.