Few things lose a customer faster than a slow website. A visitor taps your link from Google, stares at a blank screen, watches the layout jump as an advert loads, taps a button that does not respond, and goes back to the search results. You never see them, but they were a potential enquiry or sale.
Google’s Core Web Vitals put numbers on exactly these frustrations. They measure how quickly the main content appears, how fast the page responds when someone interacts, and how stable the layout is while loading. They form part of Google’s page experience signals, and more importantly, they are a good proxy for whether real people enjoy using your site.
This guide explains each metric in plain language, shows you how to measure your site’s performance, and walks through the practical fixes that make the biggest difference, especially for WordPress and WooCommerce websites.
Key takeaways
- Core Web Vitals are three metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).
- Google’s “good” thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of real visits.
- INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and it is harder to pass.
- Field data from real users (what Google uses) can differ from lab tests; check both.
- The biggest wins usually come from better hosting and caching, optimised images, less JavaScript and reserved space for media.
- Speed is not a one-off fix: new plugins, images and scripts can undo good work, so monitor regularly.
What are Core Web Vitals?
Core Web Vitals are a set of user-centred performance metrics defined by Google and documented on web.dev. Each focuses on a different part of the experience: loading, responsiveness and visual stability.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Time until the largest visible element (often a hero image or heading) is rendered | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s |
| Interaction to Next Paint (INP) | How quickly the page visually responds to clicks, taps and key presses throughout the visit | ≤ 200 ms | 200–500 ms | > 500 ms |
| Cumulative Layout Shift (CLS) | How much visible content unexpectedly moves around while the page is in use | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Google assesses each metric at the 75th percentile of page visits, separately for mobile and desktop. In other words, at least three out of four visits need to hit the “good” threshold for a page to pass. That matters: your own fast office Wi-Fi experience is not what counts, the experience of a customer on a mid-range phone and a busy mobile network is.
Largest Contentful Paint (LCP): loading
LCP answers the visitor’s first question: “Is this page actually loading?” It marks the moment the largest image, video poster or block of text in the viewport finishes rendering. On most business sites, the LCP element is the hero image or banner on the home page and the main product image on shop pages.
Interaction to Next Paint (INP): responsiveness
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the browser began processing the first interaction. INP observes interactions throughout the whole visit, such as opening a menu, adding to cart or selecting a filter, and reports a value close to the slowest one. Heavy JavaScript is the usual culprit when INP is poor.
Cumulative Layout Shift (CLS): visual stability
CLS captures the irritation of content jumping around: you go to tap “Read more” and an image loads above it, so you tap an advert instead. It is calculated from how much of the screen shifts and how far. Images without dimensions, late-loading ads and banners, and web fonts that swap in are common causes.
Why Core Web Vitals matter for your business
- User experience and conversions. Faster, more stable pages are easier to use. People browse more pages, abandon fewer carts and complete more forms when a site feels responsive.
- Search visibility. Google has said that Core Web Vitals are used by its ranking systems as part of page experience. Relevance and content quality still matter most, but when competing pages are similar, a better experience can help.
- Mobile reality in India. Many customers browse on budget and mid-range Android phones over mobile data. A site that feels fine on a new laptop can struggle badly on these devices.
- Advertising efficiency. If you pay for clicks, a slow landing page wastes part of that budget on people who leave before it loads.
How to measure Core Web Vitals
There are two kinds of performance data, and understanding the difference avoids a lot of confusion.
| Type | Source | Best for | Tools |
|---|---|---|---|
| Field data (real-user data) | Anonymous data from real Chrome users, gathered over a rolling 28-day period | Knowing what Google sees and how real visitors experience your site | PageSpeed Insights (top section), Search Console Core Web Vitals report |
| Lab data (synthetic tests) | A simulated page load on a set device and network | Diagnosing problems and testing fixes immediately | Lighthouse, PageSpeed Insights (diagnostics section), Chrome DevTools |
A simple measurement routine
- Start with Search Console. The Core Web Vitals report groups similar URLs and shows which are “Good”, “Need improvement” or “Poor” on mobile and desktop.
- Test key templates in PageSpeed Insights. Check your home page, a service or category page, a product page and a blog post. Each template usually shares the same issues.
- Read the diagnostics. PageSpeed Insights identifies the LCP element, the elements causing layout shifts and the scripts blocking the main thread.
- Fix, deploy, then re-test in the lab. Field data takes up to 28 days to fully reflect improvements, so use lab results for immediate feedback.
- Use Search Console’s “Validate fix” once you have resolved issues for a group of pages.
Do not chase a perfect 100. The Lighthouse performance score is a lab summary and swings from test to test. What matters is passing the three Core Web Vitals in field data for real visitors. A page scoring 80 that passes all three is in better shape than one scoring 95 in the lab that fails INP for real users.
How to improve LCP
LCP is the sum of several stages: server response, downloading the resource, and rendering it. Work through them in order.
Speed up the server response
- Use good hosting. Overcrowded shared servers produce slow and inconsistent responses. A host with servers in or near India, current PHP and server-level caching makes a visible difference. Our guide to choosing a domain name and web hosting explains what to look for.
- Enable page caching so WordPress does not rebuild each page from the database for every visitor.
- Use a CDN to serve images, CSS and scripts from locations closer to your visitors.
- Watch Time to First Byte (TTFB). It is not a Core Web Vital, but a slow TTFB (Google suggests aiming for around 0.8 seconds or less) makes a good LCP very difficult.
Optimise the LCP element
- Compress and correctly size hero images, and use modern formats such as WebP or AVIF.
- Never lazy-load the LCP image. Lazy-loading is great for images further down the page but delays the most important one. Many themes get this wrong.
- Add
fetchpriority="high"to the hero image, or preload it, so the browser fetches it early. - Replace heavy image sliders with a single, well-optimised hero. Sliders often load several large images and delay rendering.
Remove render-blocking resources
- Inline critical CSS and defer the rest where your setup supports it.
- Defer non-essential JavaScript so it does not hold up the first render.
- Limit web fonts to the weights you actually use, host them locally if practical and use
font-display: swap.
How to improve INP
INP problems happen when the browser’s main thread is busy running JavaScript, so it cannot respond to the user promptly.
- Audit plugins and third-party scripts. Chat widgets, multiple analytics and tracking tags, social feeds, heatmaps and popup builders all add JavaScript. Remove what you do not need and load the rest after the page becomes interactive.
- Choose lightweight themes and builders. Some page builders output large amounts of code. A lean, well-built theme is one of the best long-term investments for INP.
- Break up long tasks. For custom code, split heavy work into smaller chunks so the browser can respond between them, and avoid doing expensive work directly inside click handlers.
- Give instant visual feedback. Show a loading state immediately when someone taps “Add to cart” or applies a filter, then complete the work.
- Reduce DOM size. Very large pages with thousands of elements, such as mega-menus and long product grids, make every update slower.
- Use Google Tag Manager carefully. It is convenient, but it makes it easy to accumulate dozens of tags. Review them every quarter.
How to improve CLS
- Always set width and height (or a CSS aspect ratio) on images, videos and iframes, so the browser reserves the right space before they load.
- Reserve space for ads, embeds and banners. Cookie notices, announcement bars and promotional strips that push content down are frequent offenders. Overlay them or allocate space in advance.
- Avoid inserting content above existing content unless it is in response to a user action.
- Manage font loading. Choose fallback fonts with similar proportions, or use font metric overrides, so the swap to your web font causes minimal movement.
- Use CSS transforms for animations rather than animating properties that change layout, such as height or top.
WordPress and WooCommerce speed checklist
Most of our clients run WordPress, so here is a focused checklist:
- Hosting with server-level caching, current PHP and a data centre close to your audience.
- A single, well-configured caching plugin (multiple caching plugins conflict).
- Images compressed on upload, served in WebP/AVIF, with responsive sizes.
- Lazy-loading enabled for below-the-fold images, but disabled for the hero image.
- Unused plugins deleted; heavy plugins replaced with lighter alternatives.
- Scripts from plugins only loaded on pages where they are needed (for example, a contact form script only on the contact page).
- Database cleaned of old revisions, transients and spam regularly.
- WooCommerce cart fragments and other dynamic features reviewed for performance impact.
- CDN in front of static assets.
- Performance tested after every major update or new plugin.
Prioritising fixes: where to start
| Fix | Main metric helped | Typical impact | Effort |
|---|---|---|---|
| Better hosting and page caching | LCP | High | Low to medium |
| Optimise and prioritise hero image | LCP | High | Low |
| Set image and embed dimensions | CLS | High | Low |
| Remove unused plugins and third-party tags | INP, LCP | Medium to high | Low |
| Defer non-critical JavaScript | INP, LCP | Medium to high | Medium |
| Replace a heavy theme or page builder | All three | High | High |
Start with the low-effort, high-impact fixes. In many cases they are enough to move pages from “Poor” or “Needs improvement” into “Good”.
Keeping your site fast over time
Performance tends to erode. A marketing team adds a new tracking pixel, a large unoptimised banner is uploaded for a festive sale, or a new plugin loads scripts on every page. To keep gains:
- Set a performance budget, for example a maximum page weight and number of third-party scripts, and check new additions against it.
- Review the Search Console Core Web Vitals report monthly.
- Re-test key templates after every significant update. Our website maintenance checklist builds this into a monthly routine.
- Train content editors to compress images before uploading and to avoid embedding heavy widgets casually.
Speed is also tightly linked to layout and design choices. If you are planning a redesign, read our guide to mobile-first responsive web design, which covers how to design pages that are fast on phones from the start.
How Ciphercup can help
Our development team in Bangalore and Kochi has been building and tuning websites since 2014. We can audit your Core Web Vitals, identify the specific causes of slow loading, sluggish interactions and layout shifts, and fix them without compromising design or functionality. For new projects, our web development service treats performance as a requirement from day one, and our maintenance plans keep sites fast after launch.
Want to know why your site feels slow? Get in touch for a performance review, or compare packages on our pricing page.
Frequently asked questions
The three Core Web Vitals are Largest Contentful Paint, which measures how quickly the main content loads; Interaction to Next Paint, which measures how quickly a page responds to clicks, taps and key presses; and Cumulative Layout Shift, which measures how much the layout unexpectedly moves. Google considers a page good when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less.
Interaction to Next Paint, or INP, officially replaced First Input Delay as a Core Web Vital in March 2024. FID only measured the delay before the browser started handling the very first interaction. INP looks at responsiveness across the whole visit and reports a value close to the slowest interaction, giving a much more realistic picture of how responsive a page feels to users.
Google has confirmed that Core Web Vitals are used by its ranking systems as part of page experience signals. However, relevance and helpful content remain far more important, so a fast page with weak content will not outrank a genuinely better answer. Where competing pages are similar in quality, a better experience can help, and faster pages also tend to convert more of the visitors you already get.
The performance score in the lab section comes from a single simulated page load, which varies with server response, network conditions and third-party scripts at that moment. Field data at the top of the report comes from real Chrome users over a rolling 28-day period and is much more stable. Focus on passing the three Core Web Vitals in field data rather than chasing a perfect lab score.
Lab tools such as Lighthouse show the effect of a fix immediately, which is useful for confirming changes work. Field data used by Google is based on a rolling 28-day window of real visits, so improvements appear gradually and can take up to about four weeks to be fully reflected. Pages with little traffic may not have enough field data to be reported at all.
