Website Speed South Africa: Core Web Vitals Guide

By Next Level Web Solutions · · 6 min read · Compliance and trust

Website speed in South Africa matters because many visitors browse on mobile data, on variable networks, and will leave a page that takes too long to appear. The quickest wins are almost always the same: shrink your images, remove scripts you do not need, load fonts sensibly and put the site on decent hosting with caching.

Google measures this with Core Web Vitals, a small set of user experience metrics. This guide explains them in plain language, shows how to measure them for free, and gives you a fix-in-order checklist.

Website speed in South Africa: why speed matters on mobile networks

Many South African visitors reach small business sites from a phone. Data is not cheap, signal strength changes between suburb, highway and rural area, and loadshedding can knock out towers and Wi-Fi. A page that is light and quick holds up in those conditions. A page with a 4 MB hero image and eight tracking scripts does not.

Speed affects three things you care about:

  • Enquiries: a slow page loses people before they read your offer or see your phone number.
  • Search visibility: page experience is one of many signals Google considers, and a fast site is easier to crawl. It will not rescue weak content, but a very slow site can hold back a good one. For the bigger picture, see how to rank on Google in South Africa.
  • Costs to visitors: heavy pages burn data, which is a real consideration for people on prepaid bundles.

Core Web Vitals in plain language

Core Web Vitals are three measurements of how a page feels to use:

  1. Largest Contentful Paint (LCP): how long until the biggest visible element, usually a hero image or main heading, has loaded. Google's web.dev guidance treats 2.5 seconds or less as good.
  2. Interaction to Next Paint (INP): how quickly the page responds when someone taps or clicks. Good is 200 milliseconds or less. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.
  3. Cumulative Layout Shift (CLS): how much the layout jumps around while loading, such as a button moving just as you tap it. Good is 0.1 or less. Google assesses each metric at the 75th percentile of real visits.

Google can update these metrics and thresholds, so verify the current values on Google's web.dev documentation before you set targets. The principle stays the same: show the main content fast, respond immediately to taps, and keep things from jumping.

Measuring with free tools

Measure before you change anything so you know what actually helps.

  • PageSpeed Insights tests a web address (URL) and shows lab results and, where enough data exists, real-user field data. Run it for mobile first.
  • Lighthouse in Chrome developer tools gives a detailed breakdown and a list of opportunities.
  • Google Search Console has a Core Web Vitals report showing groups of URLs that need attention, based on real visitors. If you have not set it up, see our Google Search Console setup service.
  • Throttled testing: in developer tools, simulate a slower mobile connection to see what your visitors might experience.

Test your homepage and your most important service or contact page, not just one URL. Note the scores, and repeat after each fix. Lab scores fluctuate a little between runs, so look for patterns and consistent improvements, not a single number.

Image sizing and modern formats

Images are the most common cause of slow small business sites, so start here.

  1. Resize to the display size. A photo shown 800 pixels wide does not need to be uploaded at 4000 pixels. Resize before uploading.
  2. Use modern formats. WebP and AVIF are generally much smaller than JPEG or PNG at similar quality, and all current major browsers support WebP.
  3. Compress. Aim for the smallest file that still looks good. A hero image of a few hundred kilobytes is a reasonable aim, though it depends on the design.
  4. Serve responsive sizes. Use the srcset attribute so phones download smaller versions than desktops.
  5. Lazy load below the fold. Add loading="lazy" to images further down the page, but do not lazy load the main hero image, because that delays LCP.
  6. Set width and height on every image so the browser reserves space and avoids layout shift.
  7. Replace video backgrounds with a still image or a short, compressed clip if they are not essential.

Scripts, fonts and third party tags

After images, look at what code runs on every page.

  • Audit third party tags. Chat widgets, social feeds, heatmaps, extra analytics and advertising pixels each add network requests and JavaScript work. Remove anything nobody looks at. Anything non-essential should also be consent-gated, which our guide to a cookie consent banner under POPIA explains.
  • Defer non-critical JavaScript so it does not block the page from showing.
  • Cut plugins. On WordPress and similar systems, each plugin can add scripts and styles to every page. Keep only what you use.
  • Limit font files. Use one or two families and only the weights you need. Self-hosting fonts and using font-display: swap helps text appear quickly. System fonts are the fastest option of all.
  • Embed videos on click so a YouTube player does not load its full payload until needed.
  • Fix layout shift caused by late-loading banners, ads and fonts by reserving space for them.

Hosting and caching

Even a lean site feels slow if the server is. Check these:

  • Server response time. If your time to first byte is consistently high, the host may be overloaded or the site may be doing heavy work on every request.
  • Location. Hosting closer to your visitors reduces latency, but a content delivery network (CDN) can matter more than the data centre's location. The trade-offs are discussed in our guide to local versus international web hosting.
  • Caching. Browser caching and server or page caching let repeat visits and common pages load without rebuilding them each time.
  • Compression. Make sure text files are served compressed with Gzip or Brotli.
  • Current software. Use a supported PHP version if you are on WordPress, and keep software updated.

A fix-in-order checklist

Work through this sequence and re-measure after each step:

  1. Run PageSpeed Insights on mobile for your key pages and record the results.
  2. Resize and compress every large image, convert to WebP, and set dimensions.
  3. Make sure the hero image is not lazy loaded and loads with priority.
  4. Remove unused plugins, scripts and tracking tags.
  5. Defer or delay non-critical JavaScript.
  6. Trim fonts to what you actually use.
  7. Turn on caching and compression, and check your hosting response time.
  8. Fix layout shifts by reserving space for images, embeds and banners.
  9. Re-test on a real phone on mobile data, not just on office Wi-Fi.

If you want this done for you as part of a new build or a tune-up, see our web design and development services or get in touch.

This article is general information, not legal advice.

Frequently asked questions

What is a good load time?

There is no single magic number, but aim to meet Google's published Core Web Vitals thresholds: LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. Verify the current values on Google's documentation, since they can change. Test on mobile, because that is where most of your visitors are.

Do images slow my site?

Very often they are the biggest cause. Oversized, uncompressed photos can make a page many times heavier than it needs to be. Resize them to the size they are shown at, convert to a modern format like WebP, and compress them before upload.

Want this done for your business?

Book a free call →