How to Compare Website Performance: A Fair Speed and UX Test

Your competitor scores 92. Your site scores 68. Someone drops the screenshots into Slack and decides the entire website needs rebuilding.

Slow down. Was one test mobile and the other desktop? Did you compare a product page with a homepage? Was the cookie banner open on one site? A performance comparison built on different conditions can send a team straight into the wrong project.

To compare website performance properly, match the pages, keep test conditions consistent, separate real-user data from lab results, and inspect the actual interaction path. Use the measurements to choose specific fixes.

What does a website performance comparison measure?

A useful comparison asks three practical questions: how quickly does useful content appear, how reliably does the page respond, and how much does the layout move while someone tries to use it?

It also asks what happens after loading. Can a visitor open the menu, choose a plan, or submit a form without waiting or losing their place?

Keep this review focused. Traffic, keyword rankings, and conversion rates answer different questions. A public speed test cannot tell you your competitor's real sales performance. For the broader search comparison, use our side-by-side SEO audit checklist.

1. Match pages that do the same job

Start with three page pairs: the homepage, a comparable product or service page, and a pricing or conversion page. A lightweight brochure homepage and a product configurator are not a useful head-to-head test.

Record the final URL after redirects. Note the device mode, tool, time, consent state, and whether you are signed in. If one page serves different content by region, record that too.

A consent banner that blocks the primary action belongs in the UX notes. Do not silently dismiss it on one site and leave it open on the other.

2. Separate real-user experience from a lab test

PageSpeed Insights gives you two different views. Field data reflects measured visitor experience through the Chrome User Experience Report. Lighthouse lab results inspect a simulated visit and help diagnose bottlenecks. Google's PageSpeed Insights documentation explains the distinction and the 28-day field-data window.

Record whether the field results describe the exact URL or the wider origin. Comparing one page's data with the other site's origin-level data can hide important differences. If field data is unavailable, write “unavailable.” That is a missing measurement, not proof of good or bad performance.

Keep field measurements, lab results, and interaction notes in separate columns so readers can see what each conclusion rests on.

3. Compare the metrics behind the score

The three Core Web Vitals cover loading, responsiveness, and visual stability. Google's Web Vitals guidance sets these good-experience thresholds at the 75th percentile, assessed separately for mobile and desktop:

When all three field metrics have sufficient data, the Core Web Vitals assessment requires all three to meet their thresholds. PageSpeed Insights can still assess LCP and CLS if INP has insufficient data; missing LCP or CLS prevents an assessment. A standard Lighthouse navigation run does not measure INP. It reports Total Blocking Time (TBT), a lab diagnostic related to responsiveness, which must stay in its own column.

Inspect the page behind each number. If LCP is weak, identify the largest content element and its loading path. If interaction is sluggish, test the controls visitors actually use. If layout movement is visible, note which component moves and what action it interrupts.

4. Repeat the test before declaring a winner

Run each matched URL three times with the same settings. Alternate the URLs rather than testing one site in the morning and the other hours later. Keep the individual results and compare the median for each metric.

Three runs are a practical starting method for this review, not a Google certification standard. If the results swing widely or the gap is small, collect more evidence before choosing a winner. Google's Lighthouse variability guidance documents why measurements can change between runs.

Measured example: two website-grading homepages

On 22 October 2026, we tested the SavageAudit homepage and HubSpot Website Grader, alternating three mobile navigation runs per URL. Both pages ask visitors to submit a website for assessment. SavageAudit is our product; this example demonstrates the measurement method rather than an independent product ranking.

We used Lighthouse CLI 13.5.0 and headless Chrome 155 on the same local machine. Settings stayed at a 412 × 823 CSS-pixel viewport, simulated mobile throttling, 150 ms RTT, 1,638.4 Kbps throughput and 4× CPU slowdown. Each run started in a fresh browser session, signed out, with no consent clicks or form submissions. The six runs began between 17:15 and 17:16 UTC.

The useful finding is the spread: SavageAudit’s lab LCP ranged from 1.76 to 2.75 seconds, while Website Grader’s ranged from 9.07 to 13.69 seconds in this sample. Those swings deserve investigation and more runs before drawing a durable conclusion. Website Grader displayed a cookie banner, which we left untouched. The results describe each page as served to this runner, including its default consent interface and network path.

We did not collect field data or INP, and these navigation runs did not test form completion. The numbers do not establish either product’s real-user Core Web Vitals status, audit quality, rankings or conversion rate. Use the same method with your own matched pages, and check the reports for errors or verification screens before accepting a measurement.

Download the six measured runs as CSV to inspect the unrounded metrics, timestamps and settings.

5. Test the mobile journey after the page loads

A page can earn an attractive score while making the next click miserable. Open both sites at the same mobile viewport and perform the same task.

• Open and close the navigation. Check whether the content underneath jumps or the menu blocks the next action.
• Follow the primary CTA. Confirm that it leads to the expected destination and gives a visible response.
• Use the pricing toggle, accordion, product selector, or search control relevant to that page.
• Inspect the form before entering personal information. Check labels, validation cues, and whether overlays obscure fields.
• Scroll through images, reviews, and embedded media. Note delayed content that moves the page unexpectedly.

Write observable findings. “The pricing toggle took two taps before showing the annual plan” is useful. “Their UX is better” gives a developer nothing to fix.

For a wider review of the relationship between loading and usability, see our speed, UX, and SEO audit guide.

6. Turn the comparison into three fixes

Do not copy a competitor's entire design because one metric is better. Use the report to identify the component or request responsible for a measurable problem, then test a specific change.

Choose three actions with an owner and a success measure. For example: “Reduce the matched product page's median mobile lab LCP under the same test conditions” is a useful goal. “Beat the competitor's score” can encourage changes that remove useful features without helping visitors.

After release, repeat the same tests. Lab checks can show an immediate change; the rolling field-data window takes time to reflect new visitor experiences. Use your own analytics to evaluate business outcomes. You cannot infer the competitor's conversion rate from their speed report.

Download the comparison worksheet

Use the website performance comparison worksheet (CSV) for your next review. It has six blank run rows for alternating two URLs, separate lab and field columns, and space for the observed task, fix, owner and retest measure. Import it into Google Sheets or Excel, then add rows for further page pairs.

Record missing field data explicitly and keep INP separate from TBT. Retain the original reports with your notes so another person can reproduce the comparison.

A website performance comparison checklist

• Match equivalent page roles and record the final URLs.
• Keep mobile and desktop results separate.
• Record consent, login, tool, and test settings.
• Label field data as URL-level, origin-level, or unavailable.
• Keep lab measurements separate from field metrics.
• Repeat each lab test and retain the individual runs.
• Check the primary mobile interaction on both pages.
• Assign three evidence-backed fixes with owners.
• Retest under the same conditions after release.

Your comparison should produce a small action plan with evidence and a way to check whether each change helped.

Where SavageAudit fits into the comparison

Use SavageAudit's website comparison tool to start a broader review of two sites. Keep the speed evidence alongside the page's copy, UX, and conversion findings so the team can see what deserves attention first.

This article's repeated-test worksheet is a manual review method. Retain the original PageSpeed reports and test notes for each URL. If the same problem appears across several templates, move from a single comparison to a full-site audit.

For shared definitions behind the review, use our website audit categories. For traffic estimates rather than speed measurements, read what website traffic comparisons can and cannot tell you.