Matomo vs Google Analytics Performance Data

Quick answer: use field evidence to scope a site-specific decision

The public evidence makes Matomo worth considering when performance and data-control requirements are both material, but it does not prove that migrating from Google Analytics will improve your Core Web Vitals. Google Analytics appears across a much larger detected population, and either product can be implemented narrowly or allowed to accumulate tags, destinations, plugins, and page-wide triggers.

The practical decision is not “which script has the better aggregate median?” It is:

• What measurement must remain reliable?
• What data-control and consent requirements apply?
• Which templates need analytics at initial load?
• Who owns the tag inventory, reporting definitions, and removal decision?
• Can a loading-policy change solve the problem without a platform migration?

HTTP Archive detects technologies on an origin’s home page and one interior page, then combines detected-technology classifications with origin-level Chrome UX Report data. The June 1, 2026 snapshot below is mobile-only. It is useful for identifying patterns to test; it cannot measure the incremental impact of enabling, disabling, or migrating one analytics implementation on your site.

“Good CWV” is the share of assessable origins passing the report’s Core Web Vitals assessment. The comparison with all origins is an unadjusted percentage-point difference, not a vendor treatment effect. It should not be converted into expected ranking, conversion, or revenue gains without a same-site test.

What most Matomo versus Google Analytics comparisons miss

The expensive mistake is treating platform selection as a snippet-size contest. Analytics performance depends on the implementation around the platform: consent handling, tag manager rules, event design, destinations, marketing pixels, reporting dependencies, and the templates where code is allowed to load.

A site can keep Google Analytics while reducing its startup cost by removing unused destinations, limiting tags to relevant templates, or loading nonessential functionality later. A site can migrate to Matomo and still create a slow or fragile experience if the implementation adds plugins, duplicate tracking, or unowned integrations. The platform decision and the loading-policy decision are related, but they are not the same decision.

Technology-present and technology-absent sites are also not comparable populations. A large commerce or SaaS site may combine analytics with experimentation, advertising, chat, consent, personalization, and a substantial first-party application. A small content site may use a much narrower stack. At least five confounders matter:

1. Traffic rank: higher-traffic origins often have different infrastructure, budgets, audiences, and product requirements.
2. Site type: commerce, publishing, SaaS, and brochure sites have different templates and interaction patterns.
3. Co-installed technologies: a detected analytics product may be a proxy for a much larger marketing or commerce stack.
4. Total page composition: images, fonts, video, markup, and first-party bundles can dominate page weight.
5. Implementation quality: the same platform can load everywhere, only after consent, after critical content, on selected templates, or after an intent signal.

This is the causal-language boundary for the rest of the article: the HTTP Archive results identify an observed population profile. They do not establish that Matomo or Google Analytics caused that profile.

What the June 2026 mobile snapshot shows

For all detected origins in the snapshot, the Matomo Analytics population had 723,243 median JavaScript bytes, 2,733,392 median total bytes, and a 62.6% good-CWV share. The Google Analytics population had 1,054,960 median JavaScript bytes, 3,111,311 median total bytes, and a 52.4% good-CWV share.

The same data shows different signals rather than a simple winner:

The Matomo-detected population has lower median JavaScript and a higher good-CWV share in this all-origin snapshot. That is a useful screening signal if you are evaluating a migration or a new deployment. It does not tell you whether the tracking code itself, the sites that chose it, their templates, or other technologies explain the difference.

Google Analytics also has much broader detected coverage in this comparison. Its aggregate profile represents a much larger and likely more varied set of sites. Coverage is not a quality score, but it is a reason to avoid reading the table as a product ranking.

For an individual buyer, the table should change the next action: build an equivalent, pre-agreed test for the relevant implementation options. It should not settle the platform choice before the team defines reporting requirements and an acceptable operational cost.

Rank sensitivity: a useful stability check, not an adjustment

Traffic-rank slices help show whether the observed pattern is stable across different origin groups. They still do not adjust for site type, stack complexity, ownership maturity, or page composition.

Each cell shows good-CWV share followed by median JavaScript. In the top 100k group, the Matomo-detected population retains a higher good-CWV share, while its median JavaScript is higher than the Google Analytics population’s. That is precisely why “lighter JavaScript” and “better field CWV” should not be treated as interchangeable conclusions.

Ask four questions before using these figures in a recommendation:

• Which rank and site-type population most resembles the target site?
• Is the relevant template image-heavy, interaction-heavy, or application-heavy?
• Which other tags, destinations, and embeds appear alongside analytics?
• Does the business need all current events and reports at page startup?

Use the snapshot to prioritize an investigation. Use your own field and lab evidence to authorize a production change.

Matomo versus Google Analytics: the decision matrix

The right choice depends on what must be controlled, not only on what appears in a technology report. This matrix separates documented decision areas from site-specific validation.

The documented sources can explain why third-party JavaScript and loading strategy matter. web.dev’s guidance on third-party JavaScript describes how such code can add network and main-thread work, while also emphasizing implementation choices. It does not prove that a named analytics platform caused the origin-level differences above.

The platform choice should usually follow the measurement and governance design. If Google Analytics provides reports that operations genuinely depend on, begin by testing whether scope and timing are the real problem. If privacy, data control, or ownership requirements cannot be met under the existing arrangement, evaluate migration—but treat data continuity and reporting reconciliation as first-class work.

A controlled implementation path

Start with the business job

Write the operational job the analytics stack supports in a form that can be tested. Examples include measuring completed purchases, identifying checkout friction, attributing qualified lead flows, or monitoring a content journey that informs a real publishing decision.

“Marketing needs analytics” is not a sufficient requirement. It does not establish which events are critical, which templates require startup tracking, who approves measurement loss, or how long an unowned tag should remain installed.

This is the same governance discipline used in a broader website technology tax assessment: every technology needs a purpose, owner, loading policy, and review path. It also aligns with practical AI website maintenance automation: automate inventory and review tasks where appropriate, but keep a named owner accountable for change approval and exceptions.

Establish a baseline before changing code

Use field data to understand real-user conditions and a repeatable lab process to diagnose a specific configuration. Google’s PageSpeed Insights methodology explains why these sources can differ: field data summarizes recent eligible user experiences, while Lighthouse supports controlled diagnostic work.

For each important template, capture:

• p75 LCP, INP, and CLS by device class where field coverage exists;
• JavaScript transfer, requests, execution cost, and long tasks;
• third-party domains and which triggers caused them to load;
• consent-state behavior;
• error rate and event-delivery failures;
• the business outcome the implementation is expected to support.

Do not change the analytics platform, consent configuration, theme, tag container, and advertising destinations in one release. If the result changes, the team will not know which intervention mattered.

Test the smallest reversible change first

A migration is not always the first experiment. Consider these controlled alternatives:

• load analytics only on templates where the measurement is required;
• delay noncritical destinations until critical content is visible;
• remove duplicate tags and legacy event listeners;
• reduce plugins, integrations, and unnecessary event volume;
• require consent before applicable tracking loads;
• use an intent signal where startup tracking is not necessary;
• separate essential product telemetry from optional marketing instrumentation.

Public practitioner discussions support these as common questions, not as universal benchmarks. An r/SEO discussion about third-party tags asks whether chat, heatmaps, analytics, and similar tools need to load immediately. An r/TechSEO discussion about tag-manager bloat highlights the operational issue of accumulated tags without clear ownership. These are useful prompts for an inventory review, not evidence of typical byte savings or Core Web Vitals impact.

If your team needs to choose a platform or clean up an existing stack, scope the discussion around a tag inventory, measurement requirements, loading policy, experiment design, approval owners, and rollback path—not a generic “speed audit.”

Worked pilot scorecard: retain, narrow, migrate, or remove

The following is an illustrative planning assumption, not an observed Arsum result or a universal threshold. Its purpose is to prevent a team from declaring success based on only page speed or only report continuity.

A concrete illustrative decision rule might read: “Retain the current platform only if critical reporting reconciles, approved privacy conditions hold, and the technical no-regression bounds are met. Narrow the loading policy if reporting remains intact but startup work is avoidable. Approve phased migration only if equivalent required measurement, governance approval, and rollback readiness are demonstrated. Remove the integration if no owner can name a continuing business use.”

That rule prevents a common failure mode: a technically capable implementation receives more autonomy simply because it can collect more data. High failure cost, weak ownership, or irreversible reporting disruption should reduce the scope of change until controls are proven.

Disqualifying conditions and common failure modes

Do not authorize a platform migration or broad loading-policy change when any of the following is true:

• No one owns the event dictionary, key reports, or dashboard decisions.
• The team cannot identify which tags, destinations, or templates are actually required.
• Consent and data-handling responsibilities are unresolved.
• The business has no agreed source of truth for reconciliation.
• A release cannot be rolled back quickly through a documented path.
• Critical reporting depends on historical continuity that has not been planned for.
• The test combines multiple unrelated changes.
• The team is using an aggregate benchmark as a promise of site-specific outcomes.

Common failures are operational rather than model-specific. A team migrates but does not map downstream reports. A tag is delayed and a necessary event disappears. A consent update changes behavior without a performance owner noticing. A container grows because nobody has authority to remove obsolete scripts.

A disciplined inventory makes those failures visible. For a broader implementation perspective, see Arsum’s guide to consulting web development, the decision framework for building a website with AI, and the operational considerations in AI for ecommerce. The useful connection is governance: new tooling should enter a workflow with defined requirements, review points, and a reversible release path.

Methodology, sources, and limitations

This page uses the June 1, 2026 mobile HTTP Archive Core Web Vitals Technology Report API snapshot. HTTP Archive combines detected technologies with field-performance distributions from the Chrome UX Report. Detection is limited to the home page and one interior page, and CrUX includes eligible, publicly discoverable pages and origins with sufficient samples. See the HTTP Archive Technology Report and CrUX methodology.

The rank table is a sensitivity check across all origins, the top 1 million, and the top 100,000. It remains unadjusted for site type, co-installed technology count, total page-size band, audience geography, hosting, consent behavior, engineering maturity, and other unmeasured differences.

A stronger observational approach would compare technology-present and technology-absent origins within matched strata for traffic rank, site type, co-installed technology count, and page-size band. That matched analysis has been designed but has not been executed, stored, reviewed, or sensitivity-tested in an authorized Google Cloud environment. Even if run, it would show an adjusted association rather than randomized causation.

The decision remains straightforward: use the public comparison to identify questions, then authorize retention, narrowing, migration, or removal using evidence from your own templates, business requirements, controls, and rollback plan.