A page that feels instant on the office connection can still be the page a customer abandons on a phone, outdoors, with one hand free. Speed is not a vanity score. It is whether the offer appears, whether a tap does something, and whether the layout stays still while that happens. Firms without a performance specialist can still put the work in a sensible order. They should not expect a tool to award a ranking, or a redesign to repair a cause nobody has measured.
This is the sequence: what the three current metrics mean, which fixes usually come first, and how to read the Google tools a non-technical owner can actually open. The longer explanation of how to judge the numbers is in what UK businesses should measure.
Why a slow page costs enquiries
Visitors meet the delay before they meet the firm. A service page that takes several seconds to show its main photograph, a quote button that does nothing after a tap, or a form that jumps just as someone is about to press it, all interrupt the enquiry. People with slower connections, older phones, or assistive technology feel that interruption first. Staff feel it too, when the page they use to check a booking is the same heavy template as the public site.
Search is a separate effect, and it is easy to overclaim. Google's Search Central guidance on Core Web Vitals says the metrics measure loading, responsiveness and visual stability, and recommends good results for Search and for users. The page-experience documentation says ranking systems use Core Web Vitals, that there is no single page-experience score, and that a strong report does not guarantee a top position. Other aspects of page experience, such as mobile display, matter to users and are not described as direct ranking boosts. Treat a faster page as care for the visitor that can support search. Do not treat it as a control that produces a place in the results, or a promised rise in enquiries.
The three Core Web Vitals in plain language
Google's current set, documented on web.dev, is three field metrics. Judge each at the 75th percentile of page views, separately for mobile and for desktop. A page is in good shape on a metric when at least three quarters of those visits meet the good line, not when one test on a developer's laptop looks fine. The definitions can change, with notice. First Input Delay is no longer the responsiveness metric.
LCP: Largest Contentful Paint
Largest Contentful Paint is how long the largest image, text block or video in the visible area takes to appear, counted from the start of the navigation. On a business homepage that is often the main photograph or the main heading. Google's LCP guidance sets a good experience at 2.5 seconds or less. Above 2.5 seconds and up to 4 seconds needs improvement. Above 4 seconds is poor. A logo that appears at once, followed by a long wait for the actual offer, can still be a poor result.
INP: Interaction to Next Paint
Interaction to Next Paint is how long the page takes to show a response after clicks, taps and keyboard input during the visit. The visitor feels the gap between a tap and the next thing they can see: a menu opening, a form acknowledging a field, a filter applying. Google's INP guidance calls 200 milliseconds or less good, above 200 milliseconds and up to 500 milliseconds in need of improvement, and above 500 milliseconds poor. A page can look loaded and still feel stuck. That is why this metric is separate from LCP.
CLS: Cumulative Layout Shift
Cumulative Layout Shift adds up unexpected movement of content the visitor can see. Google's CLS guidance treats 0.1 or less as good and anything above 0.25 as poor, with the band between them needing improvement. Movement the visitor asked for, such as opening a section, is not the target. The shifts people resent are the ones that happen as they are about to tap: a banner pushing a button down, an image arriving with no space reserved, a late font reflowing a paragraph.
What to improve, and in which order
Start with the pages that earn the enquiry or the sale. A fast homepage with a slow service page is a slow site for the person who came to ask. The list below is a priority, not a shopping list of tools. Stop when the field data for those pages is in a range you can explain. Chasing a perfect lab score on every URL is a poor use of a small budget.
1. Image compression and modern formats
Photographs are often the heaviest files, and often the Largest Contentful Paint. Export them near the size they occupy, in a modern format, and do not upload a print original "so it stays sharp". Do not lazy-load the main image. Images further down the page can wait.
2. Responsive images and honest dimensions
A phone does not need the desktop file. Serve a smaller candidate to a smaller screen, and reserve the space in the layout before the file arrives. That reservation is what stops the page jumping.
3. Caching and a content delivery network, where they fit
Files that are the same for every visitor can be stored and served from nearer the visitor. That does not help a page built differently for each person, such as an account screen, and it does not excuse a file that should never have been so large.
4. Less JavaScript, split by page
Script can delay the first view and keep the page busy after a tap, which is where Interaction to Next Paint suffers. Remove code the page never uses, and do not make a service page download the rest of the site. Ask whether a chat widget, a tag or an embed is needed before the offer has been read.
5. CSS and anything that blocks the first paint
The browser must read the styling for the first screen before it can paint it. Shipping every template's styles on every URL delays that paint. Keep the first screen small and load the rest afterwards.
6. Hosting and the wait before the first byte
Nothing in the browser can finish until the server starts to answer. A slow plan or a page rebuilt from scratch on every view can use up the LCP budget before an image is requested. Hosting is part of the page, not a line underneath it. A new host will not fix a site that still sends too much.
7. Fonts and layout stability
A late typeface can reflow the text, which shows up as layout shift, and unused weights are extra download. Use the weights the design needs, and reserve room so a swap does not push the enquiry button.
8. Mobile testing and real visits
Test on a phone-sized screen and on a connection closer to a customer's than to the office Wi-Fi. Lab tools reproduce a fault. Field data, from real Chrome users, shows whether visits sit inside the good band. A quiet site may have no field data yet. That is a small sample, not a pass. Your own monitoring helps when the public reports are not detailed enough.
9. Regular checks, not a one-off project
A campaign script, a new hero and a font added "just for this page" each look small. Together they move the 75th percentile. Put a short check on the same calendar as other site care, and note the URL, the device and the metric that changed. Maintenance is where that check lives after a project ends.
How to use the three Google tools
PageSpeed Insights is the simplest public check of one URL. Where enough visits exist, it shows field data from the Chrome User Experience Report, which is what real users saw, and a lab run you can use to find a heavy file or a blocking request. Read the field section first. A green lab score on a page whose field data is poor has not fixed the visitor's experience.
Lighthouse, in Chrome DevTools and inside that PageSpeed run, is the lab audit. It can measure LCP and CLS for the controlled load. It cannot measure INP, because nobody is clicking through the page. Google notes that Total Blocking Time is the lab proxy, and that improving it may improve INP in the field. Use Lighthouse to find a cause. Do not quote its performance score as the Core Web Vitals result.
The Core Web Vitals report in Google Search Console groups similar URLs and shows Good, Needs improvement or Poor for mobile and desktop, from field data. The group's status follows its worst metric. You need a verified property, and groups with too little traffic will not appear. It is the right place for a monthly review, because it answers "which templates are failing visitors?" rather than "how did the homepage do in one test?"
A first checklist when nobody in-house owns performance
- List the URLs that produce enquiries: the main service pages, the form, and any landing page a campaign uses.
- In Search Console, note mobile and desktop status for those groups. If a group is missing, say so, and do not treat silence as success.
- Run PageSpeed Insights on three of those URLs. Write down field LCP, INP and CLS where they exist, and the largest file the lab run complains about.
- Replace oversized images, reserve their space, and stop lazy-loading the image that is the main content.
- Remove or delay chat, tags and embeds that are not required before the first screen.
- Retest the same URLs after the change. If field LCP is still poor, then look at server response, caching and JavaScript weight.
- If the layout jumps, fix image space, late banners and font loading before you restyle the page.
- If the page ignores taps, treat that as an INP problem, not as a reason to compress another photograph.
- Book the next check. A single good lab run is not a monitoring system.
Hand a developer that list, the URLs and the before-and-after notes. A brief that only says "make it score 100" invites work on the lab test rather than on the pages customers use. If the cause is the architecture rather than the assets, the choice is closer to a rebuild than to a visual refresh, which is the decision in redesign versus rebuild. A page that is fast but impossible to enquire from is a different problem, covered in the signs a website is losing customers.
Commission a measurement, not a promise
Performance work belongs inside web development and technical SEO. The stack, including Next.js where a public site needs it, can help with images, splitting code and preparing pages ahead of the visit. It does not guarantee a lab score. A fast framework with an oversized hero and a chat widget on every template misses the same thresholds.
Web Works Rise is a UK-led team in Birmingham, with a development hub in Tunisia for delivery. If an important page is slow, or you want the checklist above done against the URLs that actually produce work, contact the team with those addresses. A look at the pages that matter is a better start than a promise about a number.