Page performance

Matomo's Page Performance report — network, server, transfer, DOM-processing, DOM-completion and on-load time — is part of free Matomo core, and matomo.js fills it automatically on every real page load. If you render @matomoScript, you already have it and there is nothing to configure.

This is Matomo's own page-timing report. It is not the same thing as Web Vitals, which captures Google's Core Web Vitals (LCP, CLS, INP) as Matomo events. Both can be on at once; they answer different questions.

Three settings give you control over the parts the automatic collection cannot reach.

'js' => [
    'performance' => true,   // false => stop collecting page performance entirely
],
'spa' => [
    'performance' => true,   // forward app-measured timings on soft navigations
],
'middleware' => [
    'performance' => false,  // stamp the server generation time from the request duration
],

Turning collection off

js.performance exists only to switch the automatic collection off. There is no enable call in Matomo's tracker — collection is the default — so when this is false the snippet pushes disablePerformanceTracking before the page view.

Turn it off if your privacy posture treats the timing surface as too much information, or if you collect the same numbers through your own APM and do not want them twice.

Soft navigations

A client-side navigation produces no new browser Navigation Timing, so those rows stay empty for every virtual page view. If your application measures the timings itself, spa.performance forwards them. See SPA and soft navigation for the object shape.

Server generation time without JavaScript

middleware.performance is the one page-performance sub-timing a server legitimately knows: how long it took to generate the response. When enabled, the page-view middleware derives it from the Laravel request duration and stamps it onto the tracked page view as Matomo's server-time metric — the pf_srv tracking parameter, which fills the "server time" column of the Page Performance report.

It is off by default, because when the JavaScript tracker is present it already reports full-fidelity timings for the same page load and the two would compete. Turn it on when you track purely server-side — no snippet at all — and still want the server column populated.

The value is derived from the request's own start timestamp. If that timestamp is unavailable, no timing is sent rather than a fabricated one.