How do you pass Core Web Vitals on a business website?
A slow page loses visitors before they read a word. What Google's three Core Web Vitals measure, the targets it publishes, and the fixes that move the numbers on most business sites.
To pass Core Web Vitals, make your main content load within 2.5 seconds, respond to taps and clicks within 200 milliseconds, and stop things jumping around as the page loads. These are Google's published thresholds for three measures: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Most business websites fail because of oversized images, too many third-party scripts and unreserved space.
What are Core Web Vitals?
They are three measurements of how a page feels to a real visitor. Google publishes the targets on web.dev, and a page is rated "good" when it meets all three at the 75th percentile of real visits.
- Largest Contentful Paint (LCP): how long the biggest visible element, usually a hero image or headline, takes to appear. Good is 2.5 seconds or less.
- Interaction to Next Paint (INP): how quickly the page responds after a user taps, clicks or types. Good is 200 milliseconds or less. INP replaced First Input Delay in March 2024.
- Cumulative Layout Shift (CLS): how much content moves unexpectedly while loading. Good is 0.1 or less.
How do you measure them properly?
Use two kinds of data.
Field data comes from real users. The Core Web Vitals report in Google Search Console, and the "Discover what your real users are experiencing" section of PageSpeed Insights, show it. This is what counts.
Lab data comes from a simulated test, such as Lighthouse. It is useful for finding causes and checking fixes, but it will not match field data exactly.
Test on a mid-range Android phone with a mobile connection. Many visitors in India use phones like these, and a fast laptop hides problems. Pick your five most important pages, such as the homepage, a service page and your contact page, and measure those first.
How do you improve LCP?
LCP is usually an image or a large block of text. Fixes, in order of impact:
- Compress and resize the hero image. Serve modern formats such as WebP or AVIF, at the size actually displayed.
- Do not lazy-load the main image. Lazy loading is for images below the fold.
- Preload the hero image and the main font so the browser fetches them early.
- Reduce server response time with better hosting, caching and a content delivery network.
- Remove render-blocking CSS and scripts above the fold.
If your server takes a second to respond, no front-end fix can fully recover the time. Hosting matters. See website care and AMC for how we keep sites healthy after launch.
How do you improve INP?
INP suffers when the browser is busy running JavaScript and cannot react to the user. The usual causes are heavy scripts: chat widgets, tag managers loaded with many tags, sliders, pop-ups and page builders.
Audit every third-party script and ask what it earns. Remove what nobody uses. Load the rest after the page is interactive, or only on the pages that need them. Break up long tasks in your own code, and avoid large client-side frameworks for pages that are mostly text.
How do you improve CLS?
Layout shift happens when elements appear without reserved space.
- Set width and height on every image and video, so the browser leaves room.
- Reserve space for ads, banners and embeds.
- Avoid inserting a cookie banner or promotion at the top that pushes content down.
- Use font-display settings and similar-sized fallback fonts so text does not jump when the web font loads.
This is often the quickest category to fix.
What causes slowness on WordPress and Wix sites?
On WordPress, the usual suspects are a heavy multipurpose theme, many plugins, unoptimised images, and cheap shared hosting. On Wix, Squarespace and similar builders, you have less control, so options narrow to trimming apps, compressing images and simplifying pages.
If you have done the sensible fixes and the site is still slow, the structure may be the limit. That is when a rebuild or a move to a faster stack becomes worth considering.
Does speed matter for sales and enquiries?
Slow, jumpy pages frustrate visitors, and frustrated visitors leave. How much that costs you differs by site, so measure your own. Track bounce rate and conversion by page before and after your fixes, and change one thing at a time so you can tell which fix helped. Our note on GA4 events every service business should track shows how to see the result.
Should you fix mobile or desktop first?
Mobile. Google assesses mobile and desktop separately, and mobile is usually the weaker of the two because of slower processors and variable networks. Fix the mobile numbers first, and desktop often improves as a side effect. Check both in Search Console, because a site can pass on one and fail on the other.
A quick checklist to start with
- Measure the five key pages on a real phone.
- Compress the hero image and set its dimensions.
- Remove unused plugins and third-party scripts.
- Check that fonts are preloaded and have fallbacks.
- Check hosting response time.
- Re-test and then watch Search Console for four weeks.
When is it worth getting help?
If the numbers do not move after these steps, or if the site is built on a theme that fights you, a developer can profile it and show exactly where the time goes. A Digital Health Check gives you a written read on speed, security headers and basic SEO in one report.
You can read how we approach this on Core Web Vitals optimisation and under Web Design & Development. This is the kind of work we do. To talk about your site, Let's Talk.
Questions
What are the Core Web Vitals thresholds?
According to Google's web.dev guidance, a page is good when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less, measured at the 75th percentile of real visits.
Do Core Web Vitals affect rankings?
Google lists page experience, including Core Web Vitals, among the signals it uses, but relevant content matters far more. Treat speed as a way to keep visitors and conversions, with a possible small benefit in search.
Why does PageSpeed Insights show different numbers each time?
The lab score comes from a simulated test and varies. The field data, from real Chrome users over 28 days, is what Google uses for assessment. Look at field data first when it is available.
Can a plugin fix my speed?
Caching and image plugins help, but they cannot fix heavy themes, large scripts or poor hosting. Fixing the cause is more reliable than layering more plugins.
How long do improvements take to show up?
Lab tests change right away. Field data in Search Console updates over a 28-day window, so expect a few weeks before the report reflects your fixes.
Filed under Web Design & Development. The service behind it: Web Design & Development.

