What are Core Web Vitals?
Core Web Vitals are a small set of metrics Google defined to measure how a page actually feels to the people using it. Instead of abstract scores, they answer three plain questions: did the main content appear quickly, did the page respond when I tapped, and did things stay where they were?
Crucially, Google assesses them using field data: measurements from real Chrome users visiting your site, on their real phones and networks. A page is judged at the 75th percentile, which means at least three out of four visits need to have a good experience for the page to pass.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the biggest visible element (usually a hero image or headline) has loaded | 2.5 s or less | Over 4 s |
| INP (Interaction to Next Paint) | How quickly the page visibly responds after a tap, click or key press | 200 ms or less | Over 500 ms |
| CLS (Cumulative Layout Shift) | How much content unexpectedly jumps around while the page loads | 0.1 or less | Over 0.25 |
Anything between the good and poor columns is rated “needs improvement”. INP replaced an older metric, First Input Delay, in 2024 because it captures responsiveness across the whole visit rather than only the first tap.
Why is site speed a revenue metric?
Every enquiry, booking or sale on your website happens after the page has loaded and responded. If it does not, the visitor never reaches your contact form or WhatsApp button. Speed problems do not show up as complaints; they show up as quietly missing leads.
- Paid traffic is wasted. You pay for each Google or Meta ad click whether or not the landing page loads. A slow page raises your real cost per lead.
- Mobile visitors are less patient. Most Indian traffic arrives on mid-range Android phones over 4G that can drop to a crawl in a lift, a bus or a rural area. A page that feels fine on office Wi-Fi can be frustrating there.
- Layout shifts cause mis-taps. A banner that loads late and pushes the “Call now” button down means a visitor taps the wrong thing, and many will not try again.
- Slow interactions kill forms and checkouts. If a quantity button or a payment step lags, users assume it is broken and abandon.
Google also uses Core Web Vitals as part of its page experience signals. They will not lift a thin page above a genuinely better answer, but between two similar pages, the faster one has an edge. The article on website speed and SEO covers how much weight to give that.
How do you check your Core Web Vitals?
You do not need paid tools. Three free Google tools cover almost every business website:
- PageSpeed Insights. Enter any URL. The top section shows field data from real users (if your site has enough traffic); the lower section shows a lab test with specific fixes.
- Search Console, Core Web Vitals report. Groups your URLs into good, needs improvement and poor, separately for mobile and desktop. This is the best view of the whole site.
- Lighthouse in Chrome DevTools. Useful for developers testing a change before it goes live.
Small sites with little traffic may show “no data” for field metrics. In that case, test your key pages in the lab on mobile settings and aim to hit the good thresholds there.
What usually causes poor scores?
On business websites in Kerala and across India, the same handful of causes come up again and again. Most of them are design and build decisions, not hosting.
| Metric | Typical cause | Typical fix |
|---|---|---|
| LCP | Huge uncompressed hero images or sliders | Serve WebP or AVIF at the right size; drop the carousel; preload the hero image |
| LCP | Slow server response on cheap shared hosting | Add page caching and a CDN; upgrade hosting if response is still slow |
| LCP | Render-blocking fonts, CSS and scripts | Load only what the page needs; self-host fonts with font-display swap |
| INP | Heavy JavaScript from page builders, chat widgets and trackers | Remove unused scripts; delay non-essential widgets until after load |
| INP | Long tasks when filtering lists or opening menus | Break up work; render less at once; simplify effects |
| CLS | Images and embeds without set dimensions | Always set width and height or an aspect ratio |
| CLS | Late-loading banners, cookie bars and ads | Reserve space for them, or overlay instead of pushing content |
Which fixes give the biggest gains first?
You rarely need a rebuild to pass. Work through these in order and re-test after each step; many sites pass after the first three.
- Compress and resize every image above the fold, and convert to a modern format.
- Audit third-party scripts: chat widgets, multiple analytics tags, heatmaps, social feeds. Remove any nobody uses.
- Set dimensions on all images, videos and iframes to stop layout shifts.
- Turn on caching and a CDN so pages are served quickly from close to the visitor.
- Replace heavy sliders and autoplay video in the hero with a single optimised image.
- If you are on WordPress, cut the plugin list and consider a lighter theme before anything else.
If the site is still failing after this, the problem is usually structural: a page builder that outputs bloated code, or a front end that ships far more JavaScript than it needs. That is when a rebuild on a performance-focused stack becomes worth discussing, and Next.js vs WordPress is a useful starting point.
How long before improvements show up?
Lab scores change the moment you deploy a fix. Field data takes longer, because Google reports a rolling 28-day window of real-user visits. Expect Search Console to reflect the change gradually over about four weeks, and use its “validate fix” option to track progress.
Speed also tends to slip back. New plugins, marketing tags and unoptimised images uploaded by staff all add weight. Put a quarterly check in the calendar and make image compression part of your upload routine.
