Pagespeed and web perf measurement

Blockmetry collects web performance measurements about how fast the page loaded from web browsers (if using the webpage data collection method). These are from the standard 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.

Raw data: Navigation timing metrics

Let’s start with the navtimings overview from the spec:

Navigation timing API overview.

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 navigationStart.

Calculated data

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:

  1. 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.

  2. “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.

Working around browser bugs

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.