Every few years, Google updates its search ranking algorithms, and the internet fills with SEO buzzwords. But Core Web Vitals are different from arbitrary algorithm tweaks. They are Google's attempt to measure what a human visitor actually feels when browsing your website: how long it takes before something useful appears, whether the page hesitates when they tap a button, and whether text jumps around on screen while they are trying to read.
If your website fails Google's Core Web Vitals thresholds on mobile, you pay twice: first in lost search engine rankings across Kenya, and second in bounced visitors who abandon your page before reading your value proposition. Here is what the three vitals mean for your business, why Kenyan sites fail them, and how to pass them cleanly.
The three metrics that determine your score
Google scores every webpage against three distinct user experience benchmarks. A passing score requires hitting the “Good” threshold on at least 75% of real mobile visits over a rolling 28-day window:
| Metric | What it Measures | Good (Passing) | Needs Work | Poor (Failing) |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How fast the primary visual content (hero image, video banner, or H1 heading) renders on screen | ≤ 2.5 seconds | 2.5s – 4.0s | > 4.0 seconds |
| INP (Interaction to Next Paint) | How quickly the page gives visual feedback after a user taps a menu, expands a dropdown, or clicks a button | ≤ 200 milliseconds | 200ms – 500ms | > 500 milliseconds |
| CLS (Cumulative Layout Shift) | How much the layout shifts unexpectedly as images, banners, or fonts load asynchronously | ≤ 0.1 score | 0.1 – 0.25 score | > 0.25 score |
Core Web Vitals are a small ranking factor and a massive conversion factor. A slow site loses customers before Google ever has the chance to penalize it.
LCP: Largest Contentful Paint (The load experience)
Largest Contentful Paint marks the moment when the main piece of content in the user's viewport has fully rendered. On most Kenyan business sites, this is the large hero banner image on the homepage or the primary title block.
When LCP fails in Kenya, the cause is almost always one of two culprits: slow server response time (high TTFB from distant shared hosting in the US or Europe) or uncompressed 5MB camera exports delivered straight from Photoshop. To fix LCP:
- Host at the edge: Use global edge caching (Cloudflare, Vercel Edge) so the initial HTML response arrives in under 150ms instead of 1,200ms.
- Preload the hero asset: Tag your main banner image with
priorityorfetchpriority="high"and eliminate lazy-loading on elements visible above the fold. - Convert to AVIF or WebP: Compress banners down to under 150KB without sacrificing visual sharpness on Retina and OLED phone screens.
INP: Interaction to Next Paint (The responsiveness experience)
In March 2024, Google permanently replaced First Input Delay (FID) with INP (Interaction to Next Paint). While FID only measured the very first tap on a page, INP measures every interaction throughout the entire session — menu toggles, modal popups, filter selections, and accordion clicks.
INP is where heavy WordPress and poorly architected React sites collapse on Kenyan mobile networks. When a page bundles dozens of JavaScript plugins (Elementor widgets, tracking pixels, animation libraries), the phone's CPU gets choked executing “long tasks”. When the user taps the navigation drawer, the phone's processor is too busy crunching background script to respond, creating a noticeable, sluggish lag.
Why INP is Brutal on Budget Smartphones
A high-end laptop with an M-series chip will blaze through heavy JavaScript in 30ms. An entry-level smartphone popular in Kenya (running an Helio G35 or Unisoc T606 processor) takes 400ms to 800ms for the exact same script. Passing INP requires shipping minimal client-side JavaScript.
CLS: Cumulative Layout Shift (The visual stability)
You have almost certainly experienced CLS: you land on an online store, reach out your thumb to tap “Read More”, and right before your screen makes contact, an unformatted image pops in, pushing the content down, causing you to accidentally tap an advertisement or the wrong button. That frustrating jump is Cumulative Layout Shift.
CLS ruins customer trust and creates accidental mis-clicks. The fixes are straightforward engineering discipline:
- Always specify image dimensions: Include explicit
widthandheightattributes (or CSSaspect-ratio) on all images and video containers so the browser reserves the exact space before the image finishes downloading. - Reserve space for dynamic widgets: If you inject promotional banners, announcement bars, or newsletter popups dynamically, reserve an empty placeholder container to prevent the rest of the layout from collapsing and expanding.
- Match fallback font metrics: Use
size-adjust,ascent-override, anddescent-overridein your CSS so that your fallback system font occupies the exact line height of your custom web font, eliminating layout jumps when the custom font swaps in.
How to inspect your site today
Do not rely on Lighthouse scores run on your local computer. Lighthouse runs in a synthetic lab environment with high-speed internet and desktop processors. What Google's ranking algorithms evaluate is Field Data from the Chrome User Experience Report (CrUX).
Open Google Search Console, navigate to the Core Web Vitals tab under Experience, and review the breakdown for Mobile. If you have URLs categorized under “Needs Improvement” or “Poor”, address them immediately. Read our guide on why your site is slow on mobile data or let us inspect your codebase through our free 12-point technical audit.