Picture a store owner who finally checks site speed on Saturday morning. They open PageSpeed Insights, paste the URL, get an orange number. They rerun the test and get another number. Nothing on the site changed in that minute. Easy to wonder whether the site is moody or the tool is.
Neither. The score can shift from run to run. PageSpeed Insights FAQ asks almost the same question: why the score changes when you changed nothing. More interesting: even a steady 100 does not mean the site feels fast for everyone who visits. It helps to know what sits behind the number.
What makes up the PageSpeed score
The lab part of PageSpeed Insights comes from Lighthouse. Chrome docs describe it as a weighted blend of metrics measured in controlled conditions. In Lighthouse 10 Total Blocking Time weighs 30%, Largest Contentful Paint and Cumulative Layout Shift 25% each, First Contentful Paint and Speed Index 10% each. Weights change over time as research evolves.
There is a line I would show anyone chasing 100. A perfect 100 is called extremely hard and not expected; going from 99 to 100 needs about as much metric improvement as from 90 to 94. Green starts at 90. The last points cost disproportionately and barely change life for a real person.
Why does the number jump? Docs list causes barely tied to your site: A/B tests and ad rotation, routing changes, different devices, browser extensions injecting JavaScript, even antivirus. Lighthouse suggests treating performance as a distribution, not one number. Our Saturday owner saw normal tool behavior. PageSpeed runs in a Google data center in North America, Europe, or Asia; mobile emulation is a mid-tier phone on mobile data. For buyers in Perm or Kazan, that is still a model.
Lab test versus real visitors
Lighthouse loads the page in a simulated environment: one device, one network, one visit. Handy for catching issues before users do. Web Vitals on web.dev states plainly that lab data does not replace field data. Speed depends on device capability, network, other apps on the phone, and how the person uses the page. Only real visitor data completes the picture.
Google collects that in Chrome User Experience Report. PageSpeed shows it in the real-user block: last 28 days, only when there is enough traffic. New or low-traffic pages may have no block at all. One report page holds two answers: lab behavior and behavior for people. They can disagree, and that is fine.
One easy miss: Lighthouse loads without a user, so it cannot measure Interaction to Next Paint. Lab uses Total Blocking Time as a proxy. Better TBT may improve real responsiveness—or may not show clearly. A “Add to cart” button that hesitates on a buyer’s phone is only indirectly visible in the lab score.
Load, responsiveness, stability: Core Web Vitals
Core Web Vitals are Google’s main set for page experience. Three metrics, each with a recommended threshold. Largest Contentful Paint is load: main content should appear within 2.5 seconds. Interaction to Next Paint is responsiveness: good is up to 200 milliseconds. Cumulative Layout Shift is visual stability—does the page jump under the finger—and should be 0.1 or below.
They are judged at the 75th percentile of loads, mobile and desktop separately; one visit does not decide. In plain terms, “good” means at least three quarters of visits meet the bar. That is closer to life than a single run, covering both a new flagship and an old phone on the metro.
Caveat: this is Google’s methodology. Yandex has its own tools and guidance; do not map Google rules onto it directly. The idea—lab plus real people—is useful whatever search engine you care about.
When the report does not match how it feels
If tests look fine but buyers say the phone version lags and jumps, start with what bothers people: a heavy first screen, shifting banners, slow buttons. Then use the score to check you did not break anything.
How to pick fixes without chasing the number
I start with what a person feels, then map the metric. Slow hero image—load. Text shifts when a banner or cookie bar loads and they miss the button—stability. A catalog filter that thinks so long it feels broken—responsiveness. Each issue has its cause and its fix cost.
Check mobile on its own. Desktop forgives heavy design; a weak network on a phone does not. Much weight is deliberate: hero video, animation, third-party widgets, counters. You can strip them for points, but sometimes the business needs them more than two extra points. That trade-off should be conscious.
I wrote more about Tilda sites in the SEO on Tilda article, including speed and Core Web Vitals. The short version here: a perfect score at any cost is not the goal; comfort using the site is.
When the score still helps
It would be unfair to call the lab score useless. It alarms: if a release tanks the number, find out why before visitors do. It compares versions of one page under similar conditions. It points to sections in opportunities and diagnostics.
It works poorly as the goal itself or as proof whose site is “faster.” A competitor’s 100 means their page passed one lab run. It does not tell you how it behaves for their customers.
Our Saturday owner could have saved the morning. Instead of rerunning until happy, scroll to real-user data if it exists and open the site on their own phone. Sometimes that is the honestest test of all.