A business receives a PageSpeed report, sees a number out of 100 and assumes it represents the quality of the website. It does not. That number can help identify technical problems, but it cannot tell you whether the offer is clear, the content is credible or the enquiry route makes sense.
It also needs context. A controlled test and a real customer using a phone on an ordinary connection are different kinds of evidence. Both are useful, provided you know which one you are looking at.
Three measures of the experience
Google describes Core Web Vitals as measures of real-world loading performance, interactivity and visual stability. The current metrics are LCP, INP and CLS. They describe different frustrations, so one good result does not cancel out a problem with another.
LCP: when the main visible content appears
Largest Contentful Paint records when the largest qualifying image or text block in the visible area is rendered. In everyday terms, it helps show how long someone waits for the main content to appear. A good LCP is 2.5 seconds or less.
A business homepage might show its navigation quickly while the large opening image arrives much later. The page has started loading, but the useful first impression is still incomplete. Finding what delays that element is more productive than simply declaring the whole site slow.
INP: whether interaction feels responsive
Interaction to Next Paint measures the delay between an interaction and the next visible update. A good INP is 200 milliseconds or less. It concerns responsiveness across the visit, rather than only the first moment the page appears.
Think of pressing a menu button and waiting for anything to happen. Heavy scripts can occupy the browser even after the screen looks complete. INP does not mean that an entire network-dependent task, such as sending an enquiry, must finish within 200 milliseconds.
CLS: whether the page stays in place
Cumulative Layout Shift measures unexpected movement of visible content. A good CLS is 0.1 or less; this is a score, not a duration. An image arriving without reserved space can push text or a button away just as someone is about to use it.
These thresholds are assessed at the 75th percentile in field data, with mobile and desktop considered separately. For each metric, at least three quarters of the measured experiences should meet its good threshold. Google’s Web Vitals guidance explains that assessment across all three measures.
A lab score answers a narrower question
Lighthouse runs a controlled test. Its performance score combines several measurements under the test’s conditions. Lighthouse’s scoring documentation explains the weighting and why results can vary. A score is a diagnostic aid, rather than a universal grade for a business.
PageSpeed Insights can show both a Lighthouse test and field data collected from real Chrome users, where enough data is available. Look at which section you are reading and whether the field results describe the exact page or a broader origin. A quiet site may not have sufficient field data; an absent report is not evidence of a pass or a failure.
Lab testing is useful before launch and when investigating a specific change. Field data helps show what happens under varied devices, connections and visits. A normal Lighthouse navigation test does not reproduce the full range of interactions needed to judge real-user INP.
Ask a supplier to explain the difference between the two, especially when a report looks excellent but the site still feels slow. Repeat comparable tests and investigate patterns instead of treating one run as the verdict.
Remove unnecessary technical weight.
Oversized imagery is a common place to start. A photograph should have appropriate dimensions, compression and delivery for its role. Sending a large original file to a small card adds work without adding useful detail. Equally, an important opening image should not be unnecessarily delayed.
Review JavaScript by purpose. A modest business site may have accumulated several plugins, duplicate tracking integrations and a widget for a feature nobody uses. Removing a dependency responsibly can be more useful than trying to make an unnecessary feature load fractionally faster.
Third-party scripts deserve particular attention because their cost is not always obvious in a design review. A chat widget, booking service or embedded video may be worthwhile, but test its effect on the page and the visitor’s task. Treat it as a product decision as well as a technical one.
Fonts, image dimensions and content inserted after loading can affect stability. Hosting response time and delivery configuration also matter. A page builder can produce excessive markup or scripts, but the diagnosis should identify the actual output rather than blame a platform by name.
Visual restraint and technical restraint are different
A mostly white page can still load a large script bundle. A visually rich portfolio can be carefully optimised. Judge the work needed to deliver the design, rather than assuming that a sparse appearance means lightweight implementation.
Animation is a useful example. A small transition may clarify an interaction; a sequence that delays the content or makes every section move may simply add waiting. A redesign that makes a website heavier is not automatically an improvement.
Mobile is a useful reality check. Test a service page and the enquiry route on more than a fast desktop connection. A site that fits a phone but responds poorly can still be underselling the business behind it.
Set a useful budget, rather than chasing 100
A performance budget sets limits for a project, such as the size of images, the amount of JavaScript and the loading experience expected on key pages. There is no single byte allowance that suits every business. Agree the limits around the content and functions the site actually needs.
Test with realistic photographs, copy and integrations before approval. An empty demonstration page tells you little about the finished product. Record a baseline so later additions can be assessed against it.
Chasing a perfect score can become counterproductive if it removes useful evidence or consumes the budget while a broken form remains untouched. Prioritise delays that affect real tasks, then address the remaining technical work in proportion to its benefit.
Improve the experience, then choose the scale of work
Google recommends good Core Web Vitals, and page experience matters in search. Passing the thresholds does not guarantee a ranking increase. Relevant, useful content and other search signals remain fundamental. The same restraint applies to claims about AI search readiness.
Stable, responsive pages also contribute to a trustworthy business website. They let the visitor concentrate on the offer rather than the mechanics of getting through the page.
If one image or an obsolete script causes the problem, optimisation may be enough. If every change exposes the same limitations, a rebuild may be justified. Our redesign versus rebuild guide helps frame that decision. Start with the cause and the customer’s task, not with a score you want to display.