Understanding Page Performance Metrics
Website performance can affect user experience, conversion rates and search engine optimisation (SEO). While website speed testing tools help identify potential performance issues, the Matomo Page Performance reports are based on timing data collected from real visitors’ browsers. This helps you understand where time is spent during page loading.
To open the report in Matomo, go to Behaviour > Performance.
You can use these metrics to monitor performance trends over time, identify slower pages and investigate potential bottlenecks in network requests, server responses and browser processing.
Avg. network time
The time it takes (in seconds) for the browser to prepare the network request, including DNS lookup and connection establishment when required. This may also include other browser processing, such as service worker startup. The value can be zero or very low when an existing connection is reused.
Network and infrastructure teams should investigate high values, particularly when DNS performance, connection setup or server location may be causing delays.
DNS performance, geographic distance, network latency, CDN configuration, and connection setup, including TLS negotiation.
Consider using a CDN to serve visitors closer to their location, optimising DNS performance and reducing unnecessary connections. |
Avg. server time
The time it takes (in seconds) from when the browser starts requesting the page until it begins receiving the response. This includes network latency and server processing time. It does not measure server-side page generation time alone.
Backend developers should prioritise consistently high values by investigating server processing, database queries and caching.
Database queries, application code, external API calls, server load, caching and network latency.
Investigate slow database queries, optimise backend code, enable appropriate server-side caching and check the performance of external services. Remember that network latency also contributes to this metric. |
Avg. transfer time
The time it takes (in seconds) for the browser to receive the response, from the first response bytes until the response is complete. The response may be delivered over the network, from a cache or through a service worker. This does not include the time needed to process or render the content.
Backend and infrastructure teams should investigate large responses, compression and content delivery when transfer times are high.
HTML response size, compression, available bandwidth, network conditions and caching.
Reduce unnecessary HTML, enable Brotli or Gzip compression, optimise content delivery and use caching where appropriate. |
Avg. DOM processing time
How long the browser takes (in seconds) to parse the HTML document, from when the document begins loading until its readiness state becomes interactive. This does not necessarily mean the page is visually complete or ready to respond to user interactions.
Frontend developers should focus on reducing HTML complexity and scripts that block document parsing.
HTML complexity, DOM size, parser-blocking JavaScript and resources that delay document parsing.
Simplify HTML structure, reduce unnecessary DOM elements and minimise scripts that block HTML parsing. |
Avg. DOM completion time
How long it takes (in seconds) from when the HTML document has been parsed until the document reaches its complete state. This interval includes the completion of certain scripts, events and resources that delay page loading. Lazy-loaded resources and asynchronous activity may continue afterward.
Frontend developers should investigate scripts and resources that delay document completion, particularly when they affect visible content or usability.
Deferred and module scripts, images, stylesheets, third-party resources and other activities that delay document completion.
Optimise images and other resources, reduce unnecessary JavaScript and investigate third-party scripts or resources that delay loading. |
Avg. on load time
How long the browser takes (in seconds) to dispatch and process the
Frontend developers should investigate expensive
JavaScript executed during the
Reduce expensive JavaScript operations in |
Avg. page load timeHow long it takes the browser to load a page, from the start of fetching the document until the window
Backend, frontend and infrastructure teams should use this metric to identify which loading stages need the most attention.
The combined duration of network preparation, server response, response transfer, DOM processing, DOM completion and
Identify which individual metrics contribute most to the overall loading time and prioritise those delays. We recommend keeping this under 2 seconds where possible. |
Avg. generation timeThis metric may appear if you have data from older versions of Matomo. The average time reported for generating a page, based on legacy or custom performance tracking. Depending on how tracking was implemented, this may represent server-side processing time or include other operations. It is not directly equivalent to the Avg. server time metric. |
Priority: Low-Medium
What affects it
How to improve it
Interpreting page performance data
When reviewing page performance reports, keep in mind that browser behaviour, caching and tracking limitations can affect the results. The following factors can help explain differences between visits or why some measurements may be missing or display as zero, including in Custom Reports.
- Browser support: Matomo uses the browser’s Navigation Timing API to collect page performance measurements. Available measurements depend on the browser and the timing information it provides.
- Missing measurements: Performance data may not be available for every pageview. Matomo collects timing values when a tracking request is prepared, so some measurements may not yet be available if the page has not finished loading. Missing values should not automatically be interpreted as zero.
- Caching and connection reuse: Browsers may load resources from a cache or reuse existing network connections. This can reduce certain timing values, sometimes to zero, without indicating a measurement problem.
- Single-page applications (SPAs): Navigation Timing primarily measures document navigation. Client-side route changes typically do not generate new navigation timings, even when Matomo tracks them as separate pageviews.
- Page loading versus user experience: These metrics measure specific stages of page loading. They do not necessarily indicate when a page becomes visually complete, responsive to interactions or fully usable.
- Measurement units: Browser timing values are measured in
milliseconds, while Matomo displays page performance durations inseconds.
When investigating unexpected or zero values, check when tracking requests are sent and whether the browser provides the relevant timing information. Some timing intervals can legitimately be zero.