Core Web Vitals sound technical because they are, but the business impact is simple. If your site is slow, jumpy or frustrating on mobile, fewer people enquire. Google also uses page experience signals as part of the broader picture of whether a page is satisfying to use.
Do not chase a perfect score for sport. Chase the fixes that help real visitors load the page, read the offer and take action without friction.
The three numbers
LCP is Largest Contentful Paint. In normal language: how long the main visible content takes to show up. If your hero image or headline takes too long, people feel the page is slow.
INP is Interaction to Next Paint. It measures how quickly the page responds when someone taps, clicks or types. Heavy JavaScript and bloated plugins often hurt this.
CLS is Cumulative Layout Shift. It measures whether the page jumps around while loading. If a button moves just as someone taps it, that is a layout-shift problem.
What usually breaks small business sites
Mobile matters most
Most local-service searches happen on mobile, often from someone who wants a fast answer and a phone number. A desktop score can look fine while the mobile experience is painful. Always test the pages that matter on mobile widths, not just a big monitor.
The key pages are the homepage, service pages, suburb pages and contact page. If those are fast and stable, the commercial path is healthier.
Practical fixes
Compress hero images. Remove unused scripts. Defer non-critical JavaScript. Use system fonts where possible. Give images width and height. Avoid intrusive popups. Keep the main call-to-action visible. Use caching and a decent server.
On many small business sites, this is not a mystery. The problem is usually years of bolt-on tools and no one taking responsibility for the whole load path.
How to think about the score
A score is a diagnostic, not the business goal. The business goal is more qualified enquiries. Performance work should make the page easier to use, easier to crawl and easier to convert. If the fix does not help those things, it is probably not the next priority.
Where to start fixing
Start with the template used by the commercial pages. If the homepage, service pages and contact page all share the same bloated header, scripts and image treatment, fixing that shared layer can improve the whole site. If only one landing page is slow because it uses a massive hero video, fix that page first.
Do not spend the first week chasing tiny gains on pages that do not produce leads. A privacy policy score does not pay the bills. The pages that bring customers in should get priority.
Images are usually the easiest win
Many small business sites upload photos straight from a phone or camera. Those images can be several megabytes each. On a mobile connection, that is painful. Compress them, use modern formats, size them for the layout and avoid loading a full-screen hero image if the visible slot is much smaller.
Also set width and height so the browser can reserve space before the image arrives. That one detail can reduce layout shift and make the page feel more stable.
Be careful with widgets
Chat widgets, review embeds, maps, booking tools and video embeds can be useful, but they often load heavy third-party scripts. They should be used where they help the user, not sprayed across every page by default.
A map might belong on a contact page or service-area page. It probably does not need to block the first load of every article. A review widget might be useful, but static review excerpts can often do the same trust work with less load cost.
Performance and conversion are connected
Slow pages create doubt. A customer waiting for a plumber page to load may hit back and call the next result. A form that lags after tapping submit creates uncertainty. A page that shifts while loading can make the site feel cheap even if the business is excellent.
This is why Core Web Vitals should not be treated as a nerd score in isolation. They are measuring parts of the experience that shape whether a customer stays, trusts and acts.
What to report
A useful performance report should show the affected pages, the user impact, the fixes made and the remaining trade-offs. "PageSpeed score improved" is less useful than "homepage hero image reduced from 2.4 MB to 180 KB, mobile LCP improved, and the enquiry button is now usable faster".
Plain reporting keeps the work tied to outcomes. It also stops performance work becoming an endless chase for perfect lab numbers.
A simple triage workflow
Run the important pages through PageSpeed Insights or Lighthouse, then group the problems by cause. Image issues go in one bucket. JavaScript goes in another. Layout shift, font loading, server response and third-party embeds each get their own bucket. This makes the work easier to plan.
Then estimate impact. A single oversized hero image on the homepage is usually a high-impact fix. A minor warning on an old article may not matter yet. A third-party script that slows every page may be worth replacing. A decorative animation that hurts mobile interaction should probably go.
After fixes, test again on the same pages and viewport types. Do not assume the desktop result proves the mobile result. Do not assume a lab score proves real visitors are happy. Use the score as evidence, then confirm the site actually feels better on a normal phone connection.
Performance should protect the brand
A premium-looking site that loads badly still feels cheap. A simple site that loads quickly, stays stable and makes enquiry easy can feel more professional than a heavy design full of effects. For service businesses, the brand promise is competence. The website should behave like it.