ExpressionRise
  • Performance
  • Websites
  • Core Web Vitals

What a 100/100 PageSpeed score actually means

What Lighthouse and PageSpeed Insights measure, why the score moves between runs, and the changes that took this website to 100 on mobile.

By ExpressionRise ·

We promise 100/100 PageSpeed as standard, so it is fair to ask what that number really means, and what it does not.

Two kinds of measurement

PageSpeed Insights shows two different things on the same page.

Lab data is the score out of 100. It comes from Lighthouse, which loads your page once on a simulated mid-range phone over a slowed-down mobile connection, then scores how quickly the page appears, how soon it responds, and whether things jump around while it loads. It is repeatable enough to compare changes, which makes it a useful engineering tool.

Field data comes from real Chrome users visiting your site over the previous 28 days. It only appears once a site has enough traffic, and it is what Google uses for its Core Web Vitals assessment. It is the truer picture, because it reflects your actual visitors on their actual phones.

A good site does well on both. A lab score of 100 is evidence that the build is sound; field data confirms that real visitors feel it.

The three Core Web Vitals

Google’s Core Web Vitals boil a fast experience down to three numbers:

  • Largest Contentful Paint (LCP): how long until the main content, usually a heading or hero image, is visible. Good is 2.5 seconds or less.
  • Interaction to Next Paint (INP): how quickly the page responds when someone taps or clicks. Good is 200 milliseconds or less.
  • Cumulative Layout Shift (CLS): how much the page jumps around as it loads. Good is 0.1 or less. That jump that makes you tap the wrong button is what this measures.

Why the score moves between runs

Run Lighthouse three times and you may see three slightly different scores. The test machine, the network and whatever else the computer is doing all add noise. That is why we test several runs and look at the middle result, rather than celebrating one lucky 100 or panicking over one bad 90.

What it took to get this site to 100 on mobile

When we rebuilt our own homepage, the mobile score started in the high 60s. These were the changes that mattered, in order of impact:

  1. Analytics only after consent. Google Analytics was loading on every visit, before anyone had accepted cookies, and it was the biggest single drag on the main thread. It now loads only for visitors who say yes. That is better for privacy and for speed.
  2. Self-hosted fonts. The font used to come from a third-party stylesheet that blocked the first paint. It is now served from our own domain and preloaded, with a fallback font adjusted to the same size, so nothing shifts when it swaps in.
  3. No render-blocking CSS. The stylesheet is small, so it is now inlined into the page. We also found it had been shipped twice by mistake.
  4. Animations that do not block anything. Every effect on the homepage, from the rolling score to the brushstroke under the headline, uses only transforms and opacity, which the browser can run without holding up the page. And every effect switches off for visitors who have asked their device for reduced motion.
  5. Nothing that moves. Every image has its size reserved in advance, so the layout shift score is zero.

None of that is exotic. It is a list of small, careful decisions, each checked with a measurement. That is how we approach every site we build.

Does a perfect score guarantee more customers?

No. Speed is the floor, not the ceiling. A fast page with the wrong message still will not convert. But a slow page loses people before they read a word, especially on a phone with a weak signal, and speed is one of the signals Google uses to rank pages.

If you would like to know how your site scores, and what would move it, our Product and UX audit covers exactly that, or read about how we build websites.

Want this done
for your business?

Start a conversation →