CentriWebCore Web Vitals are three measurements Google uses to judge how a page feels to a visitor: how fast the main content appears, how quickly the page reacts to a tap, and whether things jump around while it loads. A page is rated good when it loads its main content within 2.5 seconds, responds to taps in 200 milliseconds or less, and shifts by 0.1 or less, measured for at least three in four visits. The fixes are mostly the same on any platform.
What the three core web vitals measure
Each metric has a “good” line set by Google’s web.dev team. All three are assessed at the 75th percentile of real visits, split by mobile and desktop. In practice that means three out of four visitors on phones need to have the good experience including the ones on a weak mobile signal.
| Metric | What it measures | Good | What the visitor notices |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading | 2.5 seconds or less | How long until the main image or heading appears |
| Interaction to Next Paint (INP) | Responsiveness | 200 milliseconds or less | Whether a tap on a menu or button reacts straight away |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less | Whether text and buttons jump while the page loads |
Interaction to Next Paint replaced an older measure called First Input Delay. web.dev rates an INP above 500 milliseconds as poor, with the range between 200 and 500 milliseconds marked as needing improvement. You can read the thresholds on web.dev’s Core Web Vitals page and the detail on INP.
Do core web vitals affect your Google ranking?
A little, and alongside many other things. Google’s own page on the subject says Core Web Vitals line up with what its core ranking systems seek to reward, and that it highly recommends site owners achieve good Core Web Vitals. It does not say they decide ranking on their own, and it says nothing that puts them above content that answers the search.
So treat speed as two jobs. One is a small, steady contribution to search. The other, which matters more to your phone ringing, is that a slow or jumpy page loses people who were ready to enquire. Google sets out its position on its Search Central page on Core Web Vitals.
If your pages are not appearing for the right searches at all, speed is rarely the first cause. Our guide on why a website gets visitors but no enquiries covers what to check before you spend on speed.
How to check your own website speed
Do this once on your phone and once on a computer, for your three most important pages: the homepage, your main service page and your contact page.
- Open Google’s free PageSpeed Insights test, paste the page address and run it.
- Look first at the section built from real visits, if it appears. That is the data that counts. A small site may not have enough visits to show it.
- Look at the three numbers against the table above, and ignore the single overall score for now.
- Open the page on your own phone on mobile data, not wifi. Notice where you wait and where things jump.
- Write down the worst page and the metric that fails. Fix that one first.
Run the test twice on different days. Results move around, and one bad run is not a verdict.
Fixing a slow main image or heading (LCP)
On many business sites the largest item on screen is the large photo or banner at the top of the homepage. web.dev splits LCP into four parts: the wait for the server to respond, the delay before the browser starts fetching the image, the time to download it, and the time to put it on screen. Its guide suggests roughly 40 percent of the total goes on the server wait, about 40 percent on the download, and under 10 percent on each of the other two. Treat those as a rough guide, as web.dev does, and see its guide to optimising LCP.
The fixes, in the order most owners can act on them:
- Shrink the top image. A photo straight off a phone or camera is often several megabytes. Resize it to the width it actually displays and save it in a modern format.
- Do not delay the top image. web.dev says to set high fetch priority on the likely LCP image and never lazy-load it. Lazy loading is for images lower down the page.
- Check the server response. Cheap shared hosting with no caching is a common cause of a slow first byte. web.dev lists caching, a content delivery network and fewer redirects as the fixes.
- Cut fonts. If the main item is a heading, a slow custom font can hold it back. Use fewer font files.
Fixing a page that jumps around (CLS)
Layout shift is the most irritating of the three, because it makes people tap the wrong thing. web.dev’s guide names the usual causes and they are easy to find on a small business site:
- Images with no size set. Each image needs its width and height, or an aspect ratio, so the browser reserves the space before the photo arrives.
- Embeds and iframes. A map, video or booking widget needs space held for it.
- Banners and cookie notices that push content down. Reserve the space, or make the banner overlay the page instead.
- Web fonts that swap in. Choose a close fallback font so the text does not reflow when the real one loads.
- Content injected near the top. A late-loading announcement bar above the logo moves everything below it.
The full list is in web.dev’s guide to optimising CLS.
Fixing a slow response to taps (INP)
A page can look finished and still ignore your first tap because the browser is busy running scripts. On a typical WordPress site those scripts come from add-ons: a chat widget, a booking plugin, a social feed, three analytics tags and a slider. Each one adds work.
- List every script and plugin the page loads. Your web person can pull this from the speed test report.
- Remove what you do not use. An old tracking tag for a campaign that ended is the usual one.
- Load the rest only on the pages that need them. A booking widget belongs on the booking page and nowhere else.
- Replace heavy sliders and animations with a single still image.
- Test the menu, the call button and the enquiry form on a real phone afterwards.
What to do on a WordPress site
WordPress is fast enough when it is set up with care, and slow when it carries unused plugins, oversized images and no caching. A sensible order of work:
- Fix the images first. This usually changes the numbers more than anything else.
- Remove plugins you do not use and replace two or three overlapping ones with one.
- Turn on page caching and check that your host supports it.
- Move off hosting that is slow to respond. Compare the first-byte time before and after.
- Re-test the same three pages and compare against your notes.
A theme built for speed matters as much as any of these steps, which is part of the choice between a template and custom work. Our guide to WordPress against a custom website sets out the trade-offs, and what website maintenance costs covers keeping it fast after launch.
When to stop
A perfect score is not the goal. Once your key pages pass the three lines on a phone, further work has little payoff, and the time is better spent on what the page says and how easy it is to enquire. A fast page with a vague headline and no clear phone number still loses the job.
Two cases do deserve more effort. If your pages fail on real-visit data after the fixes above, the cause is often hosting or a theme, and patching will not help. And if you are planning a new site, ask for the three numbers to be part of the handover, which a good website redesign brief should include.
CentriWeb builds websites on WordPress and looks after them on managed hosting, so speed work and upkeep sit with one team. If you can do the image and plugin clean-up yourself, you may not need us for it.
More on this topic is collected in our websites guides.