Source: https://www.envy-creative.com/articles/core-web-vitals-explained # Core Web Vitals Explained: What They Mean for Your Business Website A plain-English guide to Google's Core Web Vitals: what LCP, INP and CLS measure, how much they matter for rankings, and the fixes that make the biggest difference. By [Steve Davis](https://www.envy-creative.com/about) · 2 November 2026 · 12 min read [Web Design & Development](https://www.envy-creative.com/articles/category/web-design-development) [All Articles](https://www.envy-creative.com/articles) If you’ve ever run your website through Google’s PageSpeed Insights, you’ll have seen a set of scores labelled LCP, INP and CLS, often coloured an alarming shade of red or orange. These are Google’s Core Web Vitals, and they measure how your website feels to real visitors: how quickly it loads, how quickly it responds, and whether the page jumps around while it does. As a developer, a lot of my work involves making slow websites faster, from WordPress sites weighed down by plugins to Magento shops struggling on underpowered hosting. This guide explains what each metric means in plain English, how much they really matter for your Google rankings, and which fixes tend to make the biggest difference. ## What are Core Web Vitals? Core Web Vitals are three measurements Google uses to judge real-world user experience. Google describes them as covering loading performance, interactivity and visual stability, and recommends site owners achieve good scores both for success in Search and for a better experience generally. Core Web Vitals and their thresholds | Metric | What it measures | Good | Poor | | --- | --- | --- | --- | | Largest Contentful Paint (LCP) | How long the main content, often a hero image or headline, takes to appear | 2.5 seconds or less | Over 4 seconds | | Interaction to Next Paint (INP) | How quickly the page responds when someone taps, clicks or types | 200 milliseconds or less | Over 500 milliseconds | | Cumulative Layout Shift (CLS) | How much the layout moves around unexpectedly while loading | 0.1 or less | Over 0.25 | Anything between “good” and “poor” is rated as needing improvement. INP replaced an older metric, First Input Delay, as a Core Web Vital in March 2024, so if you’re reading older advice that mentions FID, it’s out of date. One detail that often gets missed: Google assesses these scores using data from real visitors, and a page passes when at least 75% of visits meet the “good” threshold. In other words, it’s not enough for the site to be fast on your office broadband. It has to be fast for the customer on an older phone with a patchy 4G signal. ## How much do Core Web Vitals affect Google rankings? Honestly, less than some SEO tools would have you believe, but more than nothing. Google says good Core Web Vitals align with what its core ranking systems seek to reward, as part of a wider picture of page experience. They don’t override relevance: a slow page that answers the search perfectly will usually still outrank a fast page that doesn’t. Where speed really earns its keep is with your visitors. A slow, jumpy page loses people before they’ve read a word, and on an online shop every extra second between tapping “add to basket” and seeing a response costs sales. I’d treat Core Web Vitals as a business issue first and an SEO issue second, and in my experience fixing them for visitors tends to look after the SEO side too. ## How to check your own scores - **PageSpeed Insights** (pagespeed.web.dev): enter any URL to see real-visitor data at the top, if Google has enough of it, and a lab test underneath with suggestions. - **Google Search Console**: the Core Web Vitals report groups your pages by status on mobile and desktop, so you can see which templates are causing problems. - **Chrome’s developer tools**: useful for testing changes as you make them. The difference between the two kinds of data matters. **Field data** comes from real Chrome users and is what Google uses. **Lab data** is a single simulated test, useful for diagnosing problems but not what you’re judged on. Smaller sites often don’t have enough traffic for field data, in which case the lab score is your best guide, and a lab score that varies a bit from test to test is normal. ## Fixing a slow Largest Contentful Paint LCP is the metric I see failing most often, and the causes are usually some combination of these: - **A slow server.** If the server takes a second or more just to start sending the page, everything after it is late too. Cheap shared hosting, no page caching and an overloaded database are the usual culprits. - **A huge hero image.** A 3MB photo straight off a camera is common. Resizing it, serving modern formats such as WebP or AVIF, and using responsive image sizes can transform LCP on its own. - **Lazy-loading the main image.** Lazy loading is great for images further down the page, but applying it to the hero image delays exactly the thing LCP measures. The main image should load straight away, ideally with a high fetch priority. - **Render-blocking CSS, JavaScript and fonts.** Large stylesheets and scripts in the page head make the browser wait before it shows anything. ## Fixing a poor Interaction to Next Paint INP is almost always about too much JavaScript. When the browser is busy running scripts, it can’t respond to a tap or click, so the page feels sluggish or frozen. Common causes include: - Third-party scripts: chat widgets, review badges, tracking pixels, heatmaps and social embeds, each adding work to every page. - Heavy page builders and themes that load large amounts of code on every page, whether it’s used or not. - Complex menus, filters and sliders built with inefficient scripts. The most effective fix is often simply removing things. I regularly find tracking scripts for tools nobody has logged into for years. After that, loading non-essential scripts later, and only on the pages that need them, makes a real difference. ## Fixing Cumulative Layout Shift Layout shift is the page jumping as you try to read or tap something. It’s irritating, and on a shop it can cause people to tap the wrong button. The usual causes are easy to fix once identified: - **Images and videos without set dimensions**, so the browser doesn’t reserve space for them until they load. - **Banners and notices injected at the top of the page** after it has loaded, including some cookie bars and promotional strips. - **Web fonts swapping in** and changing the size of text blocks. - **Embeds and adverts** that expand once their content arrives. ## Platform-specific things I see - **WordPress and WooCommerce:** plugin bloat and heavy page builders are the main issues. Good hosting, proper page caching, an object cache and a lean theme usually matter more than any “speed” plugin. See my [WordPress development](https://www.envy-creative.com/wordpress-development) page for how I approach this. - **Shopify:** hosting is fast, so problems usually come from apps adding scripts to every page, including apps that were uninstalled but left code behind in the theme. A theme audit often finds easy wins. - **Magento 2:** needs properly configured hosting, with full-page caching (ideally Varnish), Redis and a correctly tuned server. The Hyvä frontend theme, now free, can dramatically reduce the amount of JavaScript on the page. - **Bespoke Laravel applications:** the framework itself is fast; speed depends on efficient database queries, caching and how the frontend is built. One issue that doesn’t show up in PageSpeed Insights is aggressive bot traffic. Scrapers and badly behaved crawlers can hammer a server so hard that real visitors get slow pages. If your site is slow at random times, it’s worth checking your server logs as well as your scores. ## Fix it or rebuild it? Most sites can be improved significantly without starting again: better hosting, caching, image optimisation and removing unused scripts often move scores from red to green. A rebuild starts to make sense when the slowness is baked into the foundations, such as an outdated theme stacked with page-builder code or a platform the business has outgrown. If you’re weighing that up, my guide to [what a website costs in the UK](https://www.envy-creative.com/articles/how-much-does-a-website-cost-uk) covers the budgeting side, and if you do rebuild, [this guide to redesigning without losing rankings](https://www.envy-creative.com/articles/redesign-website-without-losing-seo) explains how to protect your search traffic. ## Core Web Vitals FAQs ### What is a good Core Web Vitals score? Google’s “good” thresholds are a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, met by at least 75% of real visits. ### Why is my PageSpeed score different every time I test? The lab test runs a single simulated visit, so network conditions and server response times vary slightly each time. Look at trends rather than one result, and give more weight to the real-visitor field data at the top of the report when it’s available. ### Do I need a perfect 100 score? No. The headline performance score is a lab measure and isn’t what Google uses for ranking. Passing the three Core Web Vitals for real visitors is a far more useful target than chasing 100. ### Will a faster website rank higher in Google? Speed helps, but relevance and content quality come first. Good Core Web Vitals support your rankings and, just as importantly, keep visitors on the page long enough to enquire or buy. ### Will a speed plugin fix my WordPress site? Caching and optimisation plugins can help, but they can’t fully make up for slow hosting, a bloated theme or dozens of third-party scripts. The biggest gains usually come from fixing those underlying causes. ### Sources - [Google Search Central: Understanding Core Web Vitals and Google search results](https://developers.google.com/search/docs/appearance/core-web-vitals) - [Google Search Central: Understanding page experience](https://developers.google.com/search/docs/appearance/page-experience) - [web.dev: Web Vitals](https://web.dev/articles/vitals) - [web.dev: Interaction to Next Paint (INP)](https://web.dev/articles/inp) - [PageSpeed Insights](https://pagespeed.web.dev/) About the author ## Steve Davis Freelance designer and developer Steve Davis is the freelance designer and developer behind Envy Creative in Clitheroe, Ribble Valley. With over 20 years’ experience across agencies, retail and education, he builds business websites, ecommerce stores and custom Laravel applications. He also helps clients with WordPress, Shopify, Magento, SEO, branding and graphic design, working directly with them from planning through to launch. [More about Steve](https://www.envy-creative.com/about) ## Want help putting this into practice? If you’re planning a website or trying to improve one, tell me what you’re working on. I’ll reply personally and help you find a useful next step. [Discuss your project](https://www.envy-creative.com/contact)