What a PageSpeed Score Actually Tells You

Published

A PageSpeed score is useful. It is also very easy to ask it to answer a question it cannot answer.

It can help show whether a page has performance problems. It cannot tell you whether a visitor understood the offer, found the right service, trusted the business, or became a customer.

So when somebody sends you a green score, the next question should not be “Can we make it 100?” It should be:

What was measured, what actually improved, and does it matter on the pages customers use?

What the big PageSpeed number actually is

PageSpeed Insights can show two different kinds of evidence.

The large Performance score comes from a simulated test run using Google’s Lighthouse tool. Think of it as a controlled test of one page under a defined set of conditions. It is useful for finding problems and comparing similar tests. It is not a recording of every customer’s visit. [1]

The score is built from several performance measurements, and the result can change when the test conditions or Lighthouse version change. That is why a single screenshot with a big green number tells you much less than a before-and-after comparison run under similar conditions. [2]

Ask for the actual page tested, whether the test was mobile or desktop, and the important timings behind the score.

A score of 96 instead of 92 does not mean the website became 4% faster, 4% better, or 4% more profitable.

Lab test, real visit data, and business result answer three different questions. Full comparison in the text description below.

Three different questions. Three different sources of evidence. A green score is not a sales report.

Diagram in words
  1. LAB TEST

    Question: What performance problems can we diagnose now?

    Evidence: PageSpeed / Lighthouse test

  2. REAL VISIT DATA

    Question: How has the site behaved for actual Chrome users?

    Evidence: Core Web Vitals, when enough data exists

  3. BUSINESS RESULT

    Question: Are suitable visitors becoming inquiries?

    Evidence: inquiry and sales records

Real-user data answers a different question

When enough data exists, PageSpeed can also show how real Chrome users experienced the site.

This information looks back over the previous 28 days. It may describe the exact page you tested, or it may fall back to broader site-level data when the page itself does not have enough measurements. Sometimes there is not enough real-user data to show a result at all. [1]

That distinction matters.

If a developer fixed something this morning, the lab test can help check the change immediately. The real-user report will take time to reflect the new experience because it still contains visits from earlier days.

And if PageSpeed says there is “no field data,” that does not mean the page passed. It means Google does not have enough of that kind of data to make the report.

Core Web Vitals, in normal language

Google currently focuses on three Core Web Vitals. The names sound more technical than the underlying questions.

Largest Contentful Paint (LCP): How quickly does the main visible content appear?
Google’s “good” threshold is 2.5 seconds or less.

Interaction to Next Paint (INP): When somebody clicks, taps, or types, how quickly does the page respond?
The “good” threshold is 200 milliseconds or less.

Cumulative Layout Shift (CLS): Does the page stay visually stable, or do things jump around while it loads?
The “good” threshold is 0.1 or less. [3]

Google evaluates these at the 75th percentile. In plain English, the experience should be good for at least three quarters of the measured visits, not just for an average or a lucky fast test. Mobile and desktop are considered separately. [3]

These measurements are useful because they point to different problems. Slow main content, sluggish interaction, and jumping layouts need different fixes.

They still do not tell you whether the page explains the service well.

Test the pages customers actually use

A fast homepage is nice. It is not enough.

A customer may enter the site through a service page, a location page, an article, or a case study. Those pages can use different templates, images, scripts, and layouts.

Test representative pages that matter to the business, especially the path from arrival to inquiry.

Also distinguish a first visit from a repeat visit. A returning visitor may benefit from files already stored in the browser, while a first-time visitor still has to download them.

Then use the site on a phone like a customer would:

  • Can you quickly tell whether the service fits?
  • Is the important evidence visible?
  • Is the next step obvious?
  • Does the form behave properly when somebody makes an ordinary mistake?

The speed score will not answer those questions for you.

Our website design and development work treats performance and the purpose of the page as part of the same job. Removing useful content just to make a score prettier can produce a faster page that tells the customer less.

Do not turn 100 into the business goal

If real users are having a poor experience, fix the problem that is actually hurting them.

If a test points to an oversized image, optimize the image and make sure it still does its job. If one page template is slow and another is fine, work on the slow template instead of assuming the entire website has one problem.

If the site is technically fast but suitable inquiries are weak, the next issue may be the offer, the traffic, the page content, or the contact journey.

Google says Core Web Vitals are used by its ranking systems, but good scores do not guarantee top rankings. Google also warns against chasing a perfect score purely for SEO. [6]

That is a useful business rule too.

A PageSpeed score is evidence about performance. It is not a percentage score for sales, trust, SEO, or customer satisfaction.

Our SEO measurement guide covers the broader habit of keeping different measurements separate instead of blending them into one impressive-looking number.

Ask for a handover you can understand

A useful performance handover should tell you:

  • which page and release were tested;
  • mobile or desktop;
  • whether before-and-after tests were comparable;
  • which important timings actually changed;
  • whether real-user data was available and what it covered;
  • what was changed on the website;
  • which important customer journeys were checked separately.

That is enough for a business owner to understand what happened without becoming a Lighthouse specialist.

Keep business measurement separate as well. Analytics and conversion work can help show what people did after arriving and where the inquiry journey breaks down.

Use PageSpeed to diagnose performance. Use real-user data to understand delivered experience. Use inquiry records to judge the business outcome.

Once those three questions stop competing for one score, the next decision becomes much easier.

Sources

  1. Google — About PageSpeed Insights:https://developers.google.com/speed/docs/insights/v5/about
  2. Chrome — Lighthouse performance scoring:https://developer.chrome.com/docs/lighthouse/performance/performance-scoring
  3. web.dev — Core Web Vitals:https://web.dev/articles/vitals
  4. Chrome — CrUX in PageSpeed Insights:https://developer.chrome.com/docs/crux/guides/pagespeed-insights
  5. web.dev — Why lab and field data can differ:https://web.dev/articles/lab-and-field-data-differences
  6. Google Search — Page experience guidance:https://developers.google.com/search/docs/appearance/page-experience

Back to Blog