Core Web Vitals for South African Websites: A 2026 Performance Guide

Your Site Scores 97 on Your Agency's MacBook. It Scores 34 on a Huawei P40 in Tembisa. Guess Which One Google Measures.

A Johannesburg retailer rebuilt their site with a "premium" development agency in early 2025. The agency delivered beautiful work. Their internal Lighthouse reports showed perfect scores. The retailer's rankings dropped 40% within six weeks of launch.

The agency tested on fibre-connected MacBook Pros in Rosebank. The actual users were on 4G phones in shopping centres, on home WiFi during load shedding, and on older Android hardware that struggled with the 3MB of JavaScript shipped to every page. Google's Core Web Vitals report uses real user data from Chrome. That data told a different story than the agency's dashboard.

This guide covers what Core Web Vitals actually are, how to measure them correctly for SA audiences, and the specific optimisations that matter when your users aren't on gigabit fibre.

What Are Core Web Vitals and Why Are They Ranking Factors?

Core Web Vitals are Google's measurement of user experience on your site. Three metrics, each with a specific threshold. Hit all three thresholds and your page is considered "good" for user experience.

They've been ranking factors since 2021 under the page experience update. In 2026, they're weighted more heavily than ever, especially for mobile search where they matter most.

The three metrics measure different aspects of what users actually experience: how fast content appears, how quickly the page responds to interaction, and how stable the layout is while loading. Miss any one and you're penalised relative to competitors who hit all three.

LCP (Largest Contentful Paint): The Speed Metric

LCP measures how long before the largest visible element renders. Usually this is the hero image, main heading, or primary content block above the fold.

Target: under 2.5 seconds
Needs improvement: 2.5 to 4 seconds
Poor: over 4 seconds

What Affects LCP

Server response time (TTFB, time to first byte)
Render-blocking CSS and JavaScript
Hero image size and format
Web font loading strategy
Client-side rendering delays

How to Fix LCP

Start with the hero image. If it's over 200KB, that's usually the culprit. Convert to WebP (30 to 50% smaller than JPEG with similar quality). Set explicit width and height. Use fetchpriority="high" on the LCP image to signal Chrome to prioritise it.

Next, check server response time. SA-hosted sites have shorter round trips to SA users. Sites hosted in US data centres add 200 to 400ms latency per request. Either move to SA hosting or put your site behind a CDN with SA edge nodes.

Remove render-blocking resources from the critical path. CSS should be minimal and inlined where possible. JavaScript should be deferred or async where it doesn't block initial render. If your hero image waits for JavaScript to load before it appears, LCP is going to suffer.

INP (Interaction to Next Paint): The Responsiveness Metric

INP replaced FID in March 2024 as a Core Web Vital. It measures how quickly your page responds when a user interacts (taps, clicks, types). Specifically, it measures the longest observed interaction delay across the session.

Target: under 200ms
Needs improvement: 200 to 500ms
Poor: over 500ms

What Affects INP

Heavy JavaScript blocking the main thread
Inefficient event handlers
Large DOM trees slowing rendering
Third-party scripts (ads, analytics, chat widgets) running at interaction time

How to Fix INP

Audit your JavaScript bundle. If you're shipping 2MB of JS on a landing page, you have a problem. Code splitting breaks the bundle into smaller pieces loaded on demand. Modern frameworks (React, Astro, Svelte) support this natively.

Defer non-critical JavaScript with defer or async attributes. Move analytics, chat widgets, and ad scripts to load after initial interaction. A chat widget that loads on page load but isn't used until minute 2 of the session is blocking the main thread for no reason.

Use requestIdleCallback for non-critical work. Break long tasks into smaller chunks that yield to the main thread. If a click handler runs 400ms of JavaScript, split it into multiple smaller handlers with setTimeout yields.

CLS (Cumulative Layout Shift): The Stability Metric

CLS measures how much visible content moves during loading. If an ad loads late and pushes your content down just as the user was about to tap a button, that's a layout shift. They hate it. Google hates it too.

Target: under 0.1
Needs improvement: 0.1 to 0.25
Poor: over 0.25

What Causes CLS

Images without width and height attributes
Ads or embeds loading after initial render
Late-injected content blocks appearing mid-page
Web fonts causing text to reflow when they load
CSS loaded after the page renders

How to Fix CLS

Always set width and height on images and videos. Browsers use these to reserve space before the asset loads. Without dimensions, the browser treats the element as 0x0 until the asset arrives, then suddenly makes space by pushing everything else down.

Use font-display: swap carefully. It prevents invisible text during font load but can cause a flash of unstyled text and subsequent reflow. font-display: optional avoids reflow at the cost of occasionally using the fallback font. font-display: block hides text briefly but avoids both issues.

Reserve space for ads and embeds. If an AdSense unit is 300x250, the container should be 300x250 even before the ad loads. Without reserved space, the ad injection causes a layout shift.

The SA Context: Why Global Benchmarks Don't Translate

Google's Core Web Vitals thresholds are based on a global mobile user. The average global mobile user has better connectivity and hardware than the average South African mobile user.

South African mobile realities in 2026:

Roughly 60% of mobile users are on 4G, 30% on 3G, 10% on 5G (growing)
Average smartphone in active use is 3 to 4 years old
Majority of the market runs mid-range Android (Samsung A-series, Huawei mid-tier, Xiaomi)
Load shedding creates network instability even in urban areas
Data costs remain high, making users cautious about heavy pages

Your local Lighthouse score on fibre is almost meaningless as a measure of what real users experience. The Chrome User Experience Report (CrUX) gives you actual field data from real users, which is what Google uses for rankings.

Measurement: Field Data Vs Lab Data

Understanding this distinction prevents most Core Web Vitals mistakes.

Lab Data

Simulated measurements under controlled conditions. Lighthouse runs with a simulated device and network. PageSpeed Insights shows lab data in the "Diagnose performance issues" section.

Lab data is consistent and useful for debugging. It's not what Google uses for ranking.

Field Data

Real measurements from real users running Chrome. Aggregated over 28 days. This is what Google uses for ranking via the CrUX database.

Field data varies with your user base. If your users skew toward urban fibre connections, your field data looks great. If your users skew toward rural mobile, your field data looks worse even with the same site.

Tools:

PageSpeed Insights: shows both field and lab data for any URL
Google Search Console Core Web Vitals report: aggregated field data for your whole site
CrUX dashboard in BigQuery: granular historical field data
Chrome DevTools Lighthouse: lab data for debugging

Image Optimisation: The Biggest Win for Most SA Sites

Most SA sites over 2MB in weight are image-heavy. This is fixable quickly and delivers the largest Core Web Vitals improvements.

Use WebP Format

WebP produces 25 to 35% smaller files than equivalent JPEGs at comparable visual quality. Every major browser supports it in 2026. No reason not to use it.

Serve Responsive Images With Srcset

A desktop user doesn't need the same image as a 375px-wide mobile user. Use the <picture> element or srcset attribute to serve appropriately-sized images to each device.

Lazy-Load Below-the-Fold Images

Native lazy loading with loading="lazy" is supported by all browsers in 2026. Add it to every image below the fold. This alone can cut initial page weight by 60 to 80%.

Set Explicit Dimensions

Width and height attributes on every image. Prevents CLS. This is a free win that too many sites still miss.

Font Optimisation

Web fonts often add 100 to 400KB and cause visible loading delays. Several optimisations help.

Subset your fonts. If you only use Latin characters, don't ship the Cyrillic and Arabic glyph sets. Tools like Google Fonts automatically subset by unicode-range. Custom fonts should be subset manually or with a tool like Glyphhanger.

Preload critical fonts. Use <link rel="preload" as="font"> for fonts used above the fold. This tells the browser to fetch them early.

Use font-display strategically. For body text, font-display: swap prevents invisible text. For headings that affect layout, consider font-display: optional to avoid CLS.

Consider system fonts. Using the user's system font (Segoe UI on Windows, San Francisco on iOS, Roboto on Android) eliminates font loading entirely. Perfectly fast, perfectly stable, often good enough for text-heavy sites.

JavaScript Optimisation

JavaScript is the most common cause of poor INP scores and frequently contributes to LCP.

Audit your bundle. Use Chrome DevTools' Coverage tab to see how much JavaScript is loaded vs how much is actually used. Typical result: 60 to 80% of shipped JavaScript is never executed on the current page.

Code split by route. Each page should only load the JavaScript it needs. Modern frameworks handle this well. Legacy WordPress sites with one giant bundle file rarely do.

Remove unused dependencies. Importing Lodash for a single function adds 70KB. Modern utility libraries let you import only what you use.

Defer third-party scripts. Google Analytics, Facebook Pixel, LinkedIn Insight, chat widgets. These rarely need to load synchronously. Defer them and watch INP improve immediately.

Hosting Matters in South Africa

Geographic distance creates latency. A request from Cape Town to a US data centre adds 200 to 400ms. To Europe, 150 to 200ms. To an SA-hosted server or CDN edge node, 20 to 50ms.

Options for SA hosting and CDN:

Cloudflare: free tier available. SA edge nodes in Johannesburg and Cape Town. Cloudflare's SA presence makes them the default choice for most SA sites.
AWS Cape Town region: launched 2020, mature now. Ideal for apps with SA-primary users.
Afrihost, Hetzner SA, RSAWEB: local hosting options. Good for smaller sites that don't need global distribution.

If you're on international shared hosting, moving to SA hosting or putting Cloudflare in front of your site can improve LCP by 300 to 800ms for SA users with no other changes.

WordPress-Specific Tips

Most SA sites run on WordPress. These plugins and configurations move the needle.

Caching Plugins

WP Rocket: paid, excellent. Handles caching, lazy loading, minification, database cleanup. Best overall for non-technical users.
LiteSpeed Cache: free if your host uses LiteSpeed Server (many SA hosts do). Powerful and well-integrated.
W3 Total Cache: free, capable but complex. For those comfortable with configuration.

Image Plugins

ShortPixel: compresses and converts to WebP automatically. Reasonable pricing.
Imagify: similar functionality, from the WP Rocket team. Good integration with WP Rocket.
Smush: free tier available, paid for WebP and bulk optimisation.

Theme and Plugin Audit

Every WordPress plugin adds JavaScript, CSS, or database queries. Audit your active plugins quarterly. Deactivate anything you don't use. Many SA WordPress sites run 40+ plugins, half of which are forgotten.

Load Shedding Resilience

One uniquely South African consideration: your site should work during load shedding. If your hosting provider loses power, your site goes down. If your users' fibre routers lose power, they browse from their phones on 4G. Either way, resilience matters.

Static site generation (SSG) is one answer. Astro, Next.js, Hugo, and Jekyll generate pure HTML at build time. No database queries on page load. No server-side rendering. Just files served from a CDN, which stays up regardless of what's happening at your origin server.

This marketing site runs on Astro for exactly this reason. Every page is a pre-rendered static file served from Cloudflare's global network. Load shedding at our origin has zero impact because there isn't really an origin serving the pages.

If you're on WordPress, caching with Cloudflare's full page cache can achieve similar resilience. Requests get served from Cloudflare's edge, only hitting your origin when cache expires.

What Are Good Core Web Vitals Scores?

Google's thresholds for "good":

LCP under 2.5 seconds at the 75th percentile
INP under 200ms at the 75th percentile
CLS under 0.1 at the 75th percentile

The 75th percentile matters. Google measures the experience of the 75th-worst user, not the average. Your median user might hit all thresholds while your 75th percentile fails. Only the 75th percentile affects your ranking.

You can check your actual CrUX scores in Google Search Console under the Core Web Vitals report. For mobile specifically, this is what Google ranks you on.

Our technical SEO guide for SA businesses covers how Core Web Vitals fit into the broader technical audit alongside crawlability, indexability, and schema markup.

How Do I Test Core Web Vitals on My South African Website?

Quick practical workflow:

Run PageSpeed Insights on your top 5 pages. Review both field data and lab data. Field data is what Google uses for ranking.
Check Search Console Core Web Vitals report. Shows aggregate performance across your site. Identifies pages that need work.
Use Chrome DevTools Lighthouse with mobile throttling. Set network to "Slow 3G" and CPU throttling to 4x. Now you're approximating what your average SA mobile user experiences.
Test on real hardware. Borrow a Samsung A13 or equivalent mid-range Android device. Connect it to 4G (not your office WiFi). Load your site. Notice what you notice.
Monitor field data over time. Core Web Vitals fluctuate. A single test tells you one day's experience. Tracking over 90 days tells you the trend.

What to Do With All of This

Start with images. Convert to WebP. Add lazy loading. Set dimensions. This usually delivers the biggest Core Web Vitals improvements for the least work.

Then JavaScript. Defer third-party scripts. Split your bundle. Remove unused code. Most sites have 50 to 70% waste here.

Then hosting. If you're on international shared hosting, moving behind Cloudflare is often a 10-minute change with massive downstream benefits.

Get your field data into the green on all three metrics and your rankings should reflect it within 6 to 12 weeks. Worth noting that Core Web Vitals alone won't rank you. Content quality and backlinks still dominate. But poor Core Web Vitals can drag down otherwise well-optimised content, and fixing them lifts that ceiling.

If you'd rather have this audited and fixed by people who do it daily, our AI-powered SEO service includes Core Web Vitals optimisation as part of the technical foundation work. We can also help you choose the right platform for your next rebuild (our website builders guide for SA breaks down the options). Create a Raimond account and we'll run a full audit on your current site, no lock-in required.