Website-speed conversations often begin with a screenshot: a coloured PageSpeed score and an urgent request to “make it 100”. The score can be useful, but it is not the goal. The goal is a website that becomes usable quickly, responds promptly and remains visually stable for real visitors.

PageSpeed Insights, Lighthouse and Core Web Vitals describe related but different things. Understanding the difference helps a business prioritise fixes instead of chasing a number.

What website speed really includes

Speed is not one moment. A visitor experiences a sequence:

  • the browser begins receiving and displaying content;
  • the main content becomes visible;
  • the page responds when they interact;
  • images, fonts and components settle without unexpected movement.

A page can appear quickly but freeze when someone opens the menu. It can feel responsive but shift the enquiry button just as the visitor taps. Performance work therefore needs several measurements and direct observation.

It also varies by device, network, location, browser, cache state and page type. A fast office laptop on fibre is not representative of every mobile customer.

What Core Web Vitals measure

Google's Core Web Vitals are field metrics focused on three aspects of real-world experience.

Largest Contentful Paint

Largest Contentful Paint (LCP) measures loading performance by identifying when the largest relevant content element in the viewport is rendered. This is often a hero image, heading block or large content panel. Google defines a “good” LCP as 2.5 seconds or less.

Slow server responses, an oversized hero image, render-blocking resources or an important image discovered late can all delay LCP.

Interaction to Next Paint

Interaction to Next Paint (INP) measures responsiveness across user interactions. It reflects the delay between an interaction—such as clicking a menu or selecting an option—and the next visual update. A good INP is under 200 milliseconds.

Long JavaScript tasks, complex rendering and expensive event handlers can make a page look ready while feeling unresponsive.

Cumulative Layout Shift

Cumulative Layout Shift (CLS) measures unexpected visual instability. A good CLS score is below 0.1. Common causes include images without dimensions, late-loading adverts or embeds, injected banners and font changes that alter layout.

The published thresholds are assessed at the 75th percentile, which is intended to represent a broad majority of visits rather than an ideal laboratory run.

What PageSpeed Insights shows

PageSpeed Insights (PSI) combines two kinds of evidence when available.

Field data comes from the Chrome User Experience Report. It represents aggregated experiences of real Chrome users over time. Depending on data availability, it may be reported for the specific URL or the wider origin.

Lab data is produced by Lighthouse in a controlled test. It helps diagnose a single run and provides opportunities and technical detail. Because it is simulated, the laboratory score can change between runs and does not guarantee the experience of every visitor.

This distinction explains why a page can have good field data but an unimpressive lab score, or the reverse. Field data tells you what eligible real users have experienced; lab data helps you investigate what might be causing the result.

Do not optimise the score in isolation

The Lighthouse performance score is a weighted summary of lab metrics. It is convenient for tracking, but the number can encourage unhelpful work.

A team may remove a useful feature to gain points, optimise a low-value page while a critical landing page remains slow, or repeatedly test until a flattering run appears. A perfect score is not a search-ranking guarantee and does not prove that the commercial journey works.

Use the report to answer:

  • Which experience is poor for real users?
  • Which page templates affect the most valuable journeys?
  • What is the underlying cause?
  • Which fix creates the greatest user benefit for reasonable effort and risk?

A practical audit process

Choose representative pages

Test the homepage, main service pages, key campaign pages, article template, contact journey and any page using unusual components. One URL cannot represent an entire site.

Review field evidence

Use PageSpeed Insights and the Core Web Vitals report in Google Search Console. Look for groups of similar URLs and changes over time. Remember that field data is aggregated and delayed; it is not a live acceptance test.

Reproduce problems in the lab

Run Lighthouse and inspect the browser's Performance panel. Test mobile conditions and use a fresh session. Identify the LCP element, long main-thread tasks and layout-shift sources rather than copying the first recommendation into a development ticket.

Observe the page directly

Use real mobile devices on ordinary networks. Open navigation, consent controls, forms, filters and embedded tools. Metrics should support human observation, not replace it.

Prioritise by cause

Typical high-value actions include:

  • improving server and cache behaviour;
  • compressing and correctly sizing images;
  • ensuring the LCP image is discoverable and not unnecessarily lazy-loaded;
  • reducing unused JavaScript and CSS;
  • deferring non-critical work;
  • reserving dimensions for images and embeds;
  • reviewing third-party scripts;
  • simplifying components that perform excessive client-side work.

Measure before and after each meaningful change. Several symptoms may share one cause, while one recommendation may have little visible effect.

Make performance an operating practice

One optimisation project can be undone by a new tracking tag, uncompressed campaign image or heavy embedded widget. Introduce a performance budget and clear ownership.

Your release process might check image dimensions, JavaScript size, representative Lighthouse runs and visual stability. Monitor field data after launch. Give marketing a safe process for adding tags and embeds rather than treating performance as a developer-only concern.

Record trade-offs. A video, personalisation tool or customer-support widget may be valuable enough to keep, but the business should understand its cost and load it as efficiently as practical.

FAQ

Is a PageSpeed score of 100 necessary?

No. Treat 100 as a possible result in a particular lab run, not the business objective. Prioritise good real-user experience on important pages and fix identified causes.

Google recommends good Core Web Vitals for users and Search, but page experience is one part of broader ranking systems. Relevant, useful content remains essential; performance is not a substitute for it.

Why does the score change when nothing changed?

Lab tests are affected by run conditions, server response and variability. Compare several runs, use consistent settings and examine metric patterns. Field data is better for longer-term user experience.

Website performance is most valuable when it removes friction from real journeys. If you need help turning reports into a prioritised technical and commercial plan, Yieldberg Studios can assess the experience across design, content and implementation.

Sources

Continue reading