A slow website does not just test a visitor’s patience. It wastes the money and effort used to get them there. If a prospective customer clicks through from Google, waits for the page to load, then leaves before seeing what you do, that is a lost opportunity. To improve Core Web Vitals properly, focus on the obstacles between a visitor arriving and taking the next step.
Core Web Vitals are not a magic SEO lever. A green score alone will not turn a weak website into a lead-generation machine. But poor performance can damage search visibility, frustrate real users and suppress conversion rates – particularly on mobile, where slower connections and less capable devices expose every technical shortcut.
For businesses relying on their website for enquiries, the aim is simple: make key pages quick, stable and responsive enough that prospects can understand your offer and act without friction.
What Core Web Vitals actually measure
Google’s Core Web Vitals focus on three parts of the user experience. They are measured using real-world visitor data where enough data is available, rather than only a controlled speed test on an agency laptop.
Largest Contentful Paint (LCP) measures how quickly the main visible content appears. On a service page, that may be the hero image, headline area or main banner. A good LCP is 2.5 seconds or less.
Interaction to Next Paint (INP) measures how quickly the page responds after someone clicks, taps or types. It matters when users open menus, submit forms, choose options or interact with calculators. A good INP is 200 milliseconds or less.
Cumulative Layout Shift (CLS) measures unexpected movement on the page. If a button shifts just as someone tries to click it, or a banner pushes content down after loading, your CLS is likely part of the problem. A good CLS is 0.1 or below.
These thresholds are useful benchmarks, not commercial targets in isolation. A page that loads in 1.8 seconds but gives visitors no reason to enquire is still underperforming. Equally, a highly useful page may retain visitors despite a modest technical issue. The best approach is to fix performance problems on pages that affect revenue first.
Improve Core Web Vitals where the commercial damage is greatest
Do not start by trying to optimise every page on the site. That approach creates work without a clear return. Start with the pages that attract organic traffic, receive paid traffic or sit closest to an enquiry: core service pages, location pages, high-performing articles, product pages and contact or quote-request journeys.
Look at three things together: your Core Web Vitals data, organic landing-page traffic and conversion performance. A page with poor LCP and substantial traffic is a sensible priority. So is a page where visitors regularly start but abandon a form. A rarely visited archive page with a weak score can wait.
This is where many website projects go wrong. Teams celebrate an improved overall performance score while the pages driving leads still carry huge images, excessive scripts and clumsy form tools. Traffic alone means nothing if the website does not perform when a buyer is ready to act.
Use field data before lab scores
Tools that simulate page speed are useful for diagnosing faults, but they are not the full picture. They can vary by test location, device profile and timing. Google’s field data shows what real visitors experience over a rolling period, making it more valuable for prioritisation.
Use lab testing to identify why a page is slow. Use field data to confirm whether users are actually affected and whether your changes have worked. Expect field-data improvements to take time to appear. This is not an overnight reporting exercise.
Fix LCP by dealing with the biggest visible problem
Poor LCP is often caused by an oversized hero image, a video banner, slow server response or essential content being delayed by scripts and stylesheets. On many SME sites, the largest element is simply an image uploaded far larger than the space it occupies.
Start by checking the main element on each priority page. Compress images properly, use modern image formats where suitable and serve images at sensible dimensions. A 4MB homepage banner may look impressive in a design review, but it is expensive for someone using mobile data on a train.
Avoid loading every image immediately. Images further down the page can usually load as the visitor approaches them. However, do not apply lazy loading to the main hero image if it is the LCP element. That delays the very content Google and your visitor are waiting for.
Server performance also matters. A heavily customised website, poor hosting configuration or an overloaded server can delay everything before the page even starts rendering. Caching, efficient hosting and a well-built content management setup can make a meaningful difference, but only if they are configured for the site rather than installed as a collection of plugins.
There is a trade-off. Removing every image and visual element may improve a test score but make the page less persuasive. The objective is not a bare page. It is a page where useful content appears quickly and the design supports, rather than blocks, a buying decision.
Reduce INP by cutting unnecessary browser work
A page can look loaded but still feel slow when visitors try to use it. This is usually an INP issue, and excessive JavaScript is a common cause.
Website builders, old themes and plugin-heavy sites often load scripts for sliders, pop-ups, animations, chat widgets, social feeds, cookie platforms and tracking tools on every page. Each one might seem harmless. Together, they create a page that responds late when a visitor clicks a menu or fills in a form.
Audit third-party scripts honestly. Ask whether each tool contributes to enquiries, compliance or meaningful measurement. If the answer is no, remove it. If it is only needed on certain pages, do not load it site-wide.
Be particularly careful with pop-ups and chat tools. They can help in some businesses, especially where prospects need quick reassurance. They can also obscure content, disrupt mobile users and consume resources. Measure whether they produce qualified enquiries rather than assuming they do because the dashboard reports interactions.
Forms deserve separate attention. A complicated form with live validation, address lookup and multiple integrations may be technically impressive but frustrating on a mobile device. Keep the initial enquiry form short. You can collect additional detail after the prospect has made contact.
Stop layout shifts before they cost clicks
Layout shift is one of the most avoidable Core Web Vitals problems. It usually happens when the browser does not know how much space an image, advert, embedded form or banner will need until it loads.
Set clear dimensions or aspect ratios for images and embedded elements so the page reserves the correct space. Make cookie notices and promotional banners behave predictably. Avoid injecting new content above the section the visitor is already reading.
Font loading can also cause movement. If a custom font arrives late and changes the size of headings or buttons, the layout shifts. Use fewer font files and weights, and make sure fallback fonts are chosen with similar proportions where possible.
A small layout shift may sound minor. On a quote page, it can make someone tap the wrong item or lose their place in a form. The commercial effect is not always visible in a monthly SEO report, but it is real.
Do not let a redesign recreate the same problems
A new website is the easiest point to build performance in properly. It is also where teams often add the most unnecessary weight: autoplay video, oversized imagery, elaborate animation and a stack of marketing integrations added late in the project.
Set performance requirements before design and development begin. Agree which pages matter most, what functionality is genuinely needed and which third-party tools must be retained. Test on real mobile devices, not only high-spec office computers. A site that feels fast on a designer’s machine may still be poor for the customers you want to reach.
If your current website is already live, make changes carefully. Work on a staging version, test key forms and tracking, then monitor organic traffic and conversions after release. Removing a script that slows the page is useful. Accidentally removing enquiry tracking means you cannot prove the improvement delivered value.
Measure success beyond the score
Core Web Vitals should sit within a wider performance view. Track whether priority pages load faster for real users, but also watch engagement, form completion, phone calls, qualified enquiries and conversion rate.
The relationship will not always be perfectly linear. Search rankings depend on relevance, content quality, authority and competition as well as page experience. Conversion depends on the offer, messaging and trust signals. But when a technically slow site is making visitors wait, fixing that friction gives your marketing a fairer chance to work.
A website should not need visitors to be patient, persistent or technically forgiving. Make the important pages fast enough to use, stable enough to trust and clear enough to generate the enquiry.