# Metrics and measurement

Each metric describes a particular set of sessions, actions or requests. Failures and missing measurements help put the timings in context.

## What each measurement counts {#dictionary}

| Measurement | What is measured | Interpretation |
| --- | --- | --- |
| Avg load time (Pages) | Milliseconds for a successful Open step or successful step whose URL changes. Includes the action and waiting for the page or next element; grouped by URL without query strings. | Includes more than network transfer time and does not guarantee that all background requests have finished. |
| Avg duration (Steps) | Milliseconds spent on an action and waiting for the page or next element; successful steps only. Pauses between steps are excluded. | Compare failures separately; failed action durations are excluded. Explicit Wait steps contribute session time but no step-timing sample. |
| TTFB | Time from starting navigation until the browser receives the first byte of the page response, in milliseconds. Counted when a new page loads and the measurement is available. | Includes the document response path; not isolated database execution time. |
| LCP | Latest Largest Contentful Paint reported when vitals are read after the step, milliseconds. New-document observations only. | A lab paint observation at collection time, not a real-user field percentile. |
| API calls | XHR/fetch request timing in milliseconds until response end; failures can use elapsed time since the request event. Cancelled/unfinished calls are excluded from timing aggregates. | These are calls made by the website during browser execution, not API-only load tests. Timed failures remain in the distribution; inspect outcomes as well as the mean. |
| Average session duration | Average time from scenario start to end or last report. Includes waits and time between actions. | The sum of recorded seconds also informs usage; it differs from elapsed run time. |
| Failed sessions | Failed sessions divided by sessions with recorded outcomes, ×100; rounded to two decimals. | Includes failed steps, timeouts, sessions that could not start and sessions that stopped reporting. Sessions without an outcome are not counted as successful. |
| Failed requests | Failed network requests plus HTTP responses ≥400, divided by recorded requests, ×100. Navigation cancellations are excluded from failures. | A different denominator from Failed sessions; one session can make many requests. |

## Means, percentiles and missing values {#aggregation}

The average is calculated from the available measurements. A percentile describes how those measurements are spread: p90, for example, is the value at or below which at least 90% of measurements fall. UserLimit uses the nearest-rank method and rounds timing summaries to whole milliseconds. Missing measurements are omitted rather than counted as zero. When no measurements are available, no average or percentile is shown.

~~~text
10 samples averaging 1 s + 90 samples averaging 3 s
Sample-weighted mean = (10 × 1 + 90 × 3) / 100 = 2.8 s
Mean of the two group means = (1 + 3) / 2 = 2.0 s
~~~

The overall mean depends on the number of samples in each group. Percentiles cannot be combined by averaging the percentiles of individual pages. UserLimit’s timing summaries show p50, p90 and p99.

## Coverage and navigation limitations {#coverage}

A client-side route change can produce a page-duration measurement without loading a new document. In that case, the existing document’s TTFB and LCP are excluded from the new route’s timing aggregates. Interrupted sessions, failed pages and early collection can also leave measurements unavailable, so a missing LCP should not be interpreted as a fast result.

UserLimit reports TTFB and LCP, but does not provide FCP, INP or CLS summaries. LCP is therefore the only Core Web Vital included in these reports. Its value reflects the test’s browser version, fresh session state, server caches and location, rather than the full range of conditions experienced by real visitors.

The Pages table counts page loads without exposing separate sample counts for TTFB and LCP. Those page-load totals cannot be used to calculate metric coverage because some loads may have no corresponding timing measurement. Support can help investigate missing measurements when that distinction affects the interpretation.

Reports contain a limited number of API calls, endpoint groups and error examples to support investigation. A more complete request history requires the website’s own logs and monitoring.

## From a measurement to an investigation {#interpret}

A higher TTFB suggests that more time is being spent before the page response begins, but does not identify which part of that response path is responsible. Application logs, cache behaviour and access rules can help distinguish possible causes. When LCP increases while response time stays similar, rendering and asset delivery are useful areas to investigate.

Traffic and measurement coverage also affect the interpretation. Missing or delayed sessions can mean that the intended workload did not reach the site, while missing timing samples can change which observations contribute to an average. The [troubleshooting guide](https://userlimit.com/documentation/help/troubleshooting.md) covers these cases. Further context is available in the guides to [Web Vitals](https://web.dev/articles/vitals) and [lab and field differences](https://web.dev/articles/lab-and-field-data-differences).

## Related guide {#next-step}

[Interpret the report](https://userlimit.com/documentation/results/read-a-report.md)