WordPress speed in South Africa is a different problem to WordPress speed anywhere else, and most of the advice online quietly ignores that. Most WordPress speed advice was written for sites hosted in the US, visited from the US, on US home broadband. It transfers badly to a South African site hosted anywhere, visited from a phone on mobile data in Johannesburg. The bottlenecks are different, and the fixes are different.
These eight fixes are the ones that consistently move the numbers on real SA sites we audit and rebuild. None of them are exotic. All of them are things most agencies leave undone because “the site loads fine on my laptop”, which is not how any of your customers actually see it.
1. Move hosting closer to your visitors
If your host is in the US or Europe, every request travels 400 to 900ms back and forth across the ocean before the browser sees anything. For a homepage that makes 40 to 80 requests, that adds up to a page that starts rendering after 3 seconds regardless of how fast your code is. Options that work in SA:
- A local host with data centres in Johannesburg or Cape Town (many good SA managed WordPress hosts exist).
- A US or European host paired with Cloudflare’s CDN, so at least the static assets serve from a local point of presence.
- For high-traffic sites, a proper edge deployment (Cloudflare Pages or similar) with dynamic content proxied through.
Hosting is the single biggest lever on SA site speed. Nothing else you do afterwards makes up for a slow origin server.
2. Put Cloudflare in front (and turn on Auto Minify and Brotli)
Cloudflare’s Johannesburg and Cape Town points of presence cache your static files (images, CSS, JS) close to the visitor. On a typical SA WordPress site, that alone cuts time-to-first-byte from 700ms to under 150ms. Free-tier settings that matter:
- Auto Minify: HTML, CSS and JS. Free 15% to 25% page-weight cut.
- Brotli compression: on. Better than gzip for the same CPU cost.
- Caching Level: Standard, with Browser Cache TTL set to a month for static assets.
- Speed > Optimization > Rocket Loader: try it, but turn it off if JavaScript-driven features break; it can be aggressive.
3. Serve images as WebP, not JPEG or PNG
WebP is 25% to 35% smaller than JPEG for the same visual quality, and every current browser supports it. The two working paths on WordPress:
- A conversion plugin (Imagify, ShortPixel, Smush, Converter for Media) that auto-converts on upload and serves WebP with a fallback to JPEG for legacy browsers.
- Cloudflare’s Polish (paid feature) or a similar image CDN that converts on the fly.
Images are typically 60% to 80% of a WordPress page’s weight. Cutting them by 30% shifts Largest Contentful Paint by more than any code optimisation.
4. Lazy-load below-the-fold images and iframes
WordPress core has native lazy-loading via the loading=”lazy” attribute, but Elementor and many themes override it. Check your rendered HTML: images below the fold should carry loading=”lazy”. If they do not, either fix the theme or use a plugin that reapplies it. YouTube and Vimeo embeds should also lazy-load, which is a separate plugin (Lazy Load for Videos, or WP Rocket’s equivalent).
5. Get rid of unused JavaScript
WordPress sites accumulate JavaScript. Every plugin adds its own scripts, most of which load on every page whether they are needed or not. A form plugin that only runs on /contact/ should not be loading scripts on /home/. Two working tools:
- Asset CleanUp or Perfmatters to disable plugin scripts on pages that do not use them.
- WP Rocket, FlyingPress or LiteSpeed Cache to defer non-critical JavaScript so it does not block the first paint.
The Chrome Coverage tab in DevTools shows exactly which scripts are unused per page. On most SA WordPress sites we audit, 40% to 70% of loaded JavaScript is not executed on the current page.
6. Cache aggressively (and correctly)
A proper cache plugin turns every page load into serving a pre-built HTML file, which is 20 to 50 times faster than PHP + database on every request. On SA WordPress sites the three that consistently work:
- WP Rocket (paid, easiest, sensible defaults).
- LiteSpeed Cache (free, needs LiteSpeed server; excellent when available).
- FlyingPress (paid, aggressive defaults, better than WP Rocket in some benchmarks).
Free options like W3 Total Cache work but need careful configuration to avoid breaking dynamic features. WooCommerce and any logged-in area needs cache exclusions; the plugins above handle this automatically.
7. Prune plugins ruthlessly
Every plugin loads code and often makes database queries. Twenty plugins is a lot. Forty is a serious problem. The ones we most often uninstall on SA site audits:
- Multiple SEO plugins active simultaneously (only one, ever).
- Full Font Awesome loading for a single icon.
- Old Google Analytics or social-share plugins replaced by native theme or GTM.
- Backup plugins running during business hours (schedule to 2am, or use host-side backups).
- Security plugins that scan on every page load; run scans on a schedule instead.
8. Fix render-blocking CSS and web fonts
Two culprits kill the first paint on SA sites: fonts loaded from Google Fonts without font-display: swap, and CSS files loaded synchronously in the head. Fixes:
- Self-host Google Fonts (OMGF plugin, or manual). Faster because it skips the extra DNS lookup and travels the same connection as the rest of the page.
- Add font-display: swap so the browser shows fallback text while the font loads instead of blocking rendering.
- Move non-critical CSS to load asynchronously with WP Rocket or a similar plugin.
What good WordPress speed South Africa numbers look like
On a well-tuned SA WordPress site with SA-adjacent hosting and Cloudflare in front, we typically see mobile Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200ms, and Cumulative Layout Shift under 0.1. That puts you in the “good” band for all three Core Web Vitals on the 75th-percentile mobile visitor, which is the visitor Google grades your site on.
For the full picture on Core Web Vitals in SA and why sites feel fine on office fibre but crawl on mobile, we covered it in why your SA WordPress site is slow (even on fibre). This piece is the fix side of that same question, so if you have already measured the problem, you can go straight to the eight things that actually shift it.
