The tap-back nobody reports as feedback
Nobody consciously thinks "this page took four seconds, I am leaving now." They just run out of patience and tap back before the content they wanted even finishes appearing. You will never see this in a support ticket or a complaint email, it just quietly reduces the number of people who ever reach your offer.
It matters most on the pages where you already paid for the attention, a clicked ad, a search result, a link shared on WhatsApp. A slow page on exactly those pages is spending your acquisition budget on a visitor who never actually saw what you were selling.
A slower-than-expected observation from client audits: speed problems rarely announce themselves as one obvious cause. They accumulate (a hero image here, a marketing script there, a font loading strategy nobody revisited since launch) until the page just feels heavy without any single smoking gun.
What visitors actually infer from a slow page
A slow page does not just cost seconds. It quietly signals something about the business behind it. Fairly or not, visitors extend the sluggishness of a page into an assumption about the service: if the website feels neglected, will the actual work feel neglected too?
That inference happens almost instantly, and it rarely gets a second chance to be corrected, a visitor who already half-decided you feel unreliable is unlikely to stick around long enough for your proof section to change their mind.
A scenario: the ad that paid for someone else’s bounce
A plumbing business runs a Google Ads campaign, pays R45 for a click from someone with a burst geyser searching urgently on their phone. The landing page takes just over six seconds to show anything useful, a large unoptimised hero photo is still loading, a booking widget script is still initialising, and a chat plugin is fighting for the same bandwidth. The visitor, mid-emergency and on patchy mobile data, taps back and calls the second plumber on the search results page instead, whose site loaded in under two seconds.
The R45 was not wasted on a bad ad or the wrong keyword. It was wasted on a page that could not open its own front door fast enough for someone who genuinely needed the service right now. Multiply that one click across a month of campaign spend, and a slow landing page quietly taxes every single rand of paid traffic before a single word of the offer even gets read.
Core Web Vitals, translated into commercial questions
| Metric | Plain-language question | What usually breaks it |
|---|---|---|
| Largest Contentful Paint (LCP) | How long until the main useful content appears? | A heavy, unoptimised hero image or video |
| Cumulative Layout Shift (CLS) | Does the page jump around while it loads? | Ads or images loading without reserved space |
| Interaction responsiveness | Does the page feel stuck when someone tries to use it? | Too many third-party scripts running at once |
Check Google’s current published thresholds for "good," "needs improvement" and "poor" directly, since guidance is refined over time, treat any fixed number you read elsewhere as a snapshot, not a permanent rule.
Lab scores vs field data, and why the gap matters here specifically
| Type | What it measures | Limitation |
|---|---|---|
| Lab data (e.g. Lighthouse) | A simulated test run under controlled conditions | May not reflect your real visitors’ actual devices and networks |
| Field data (e.g. Chrome UX Report, GA4) | Real visits from real users, on their real devices and networks | Needs enough traffic volume to be statistically meaningful |
Why this is a bigger deal in South Africa than the global playbooks assume
A meaningful share of South African web traffic still arrives on mid-range Android devices over cellular data, not premium phones on office fibre. Designing and testing only on the latter systematically overestimates how fast your site actually feels to the customer who matters most.
Network conditions here vary by carrier, location and time of day in ways a lab test in a fast, controlled environment simply will not surface, tower congestion and uneven coverage both do real, measurable damage to load times that never show up on a designer's laptop.
This is not a case against rich design. It is a case for being deliberate about where the visual weight goes, prioritise fast, clear delivery of whatever helps someone decide to contact you, and treat decorative extras as strictly secondary.
Diagnosing "slow", is it the network, the device or the page?
| Symptom | Likely cause | How to confirm |
|---|---|---|
| Fast on Wi-Fi, painfully slow on mobile data | Network variability, or a page too heavy for a typical cellular connection | Test the same page on a throttled connection in browser dev tools |
| Slow on both networks, on a modern phone | The page itself, heavy images, excess scripts, poor hosting | Run a lab test (e.g. Lighthouse) and inspect the resource waterfall |
| Fast on a new phone, slow on an older mid-range one | Device processing power, often combined with heavy JavaScript | Test on an actual mid-range Android device, not just newer hardware |
| Fine most days, unpredictable at certain times | Hosting capacity struggling under traffic spikes, or local network congestion | Check hosting metrics during known peak periods |
Practical fixes that usually move the needle
- Compress and properly size images, serve the size actually needed, not a huge original
- Remove unused or redundant scripts and plugins, especially on money pages
- Lazy-load below-the-fold media so the first screen loads faster
- Prioritise (and do not delay) the largest visible content element on each template
- Reserve space for images and ads so the layout does not jump while loading
- Choose hosting appropriate to your traffic and template complexity
- Test on a mid-range Android phone over real mobile data, not just office Wi-Fi
Four mistakes we find on almost every slow site we audit
A camera-resolution photo dropped straight into a hero banner without resizing, one of the most common, most fixable mistakes we see. A properly compressed version often looks visually identical to a visitor while loading dramatically faster.
Marketing, chat and analytics scripts stacked on top of each other without anyone ever auditing whether all of them are still needed. Each one adds its own loading and execution cost, and those costs compound rather than stay flat.
Budget hosting chosen for a site that now carries real traffic or a genuinely heavy template. Hosting needs to match your actual traffic and complexity today, not the cheapest plan available when the site first launched three years ago.
Web fonts loaded inefficiently, too many weights and styles, or a font that blocks text from displaying until it fully downloads. Visitors experience this as a blank flash before text appears, and it feels slower than the raw millisecond number suggests.
Where to start: prioritise by commercial weight
- Identify your money pagesThe homepage, top service/product pages and any paid landing pages that carry the most traffic and intent.
- Profile those pages firstRun both a lab test and check available field data for exactly these pages before auditing the entire site.
- Fix the biggest, cheapest winsOversized images and unnecessary scripts are almost always the fastest fixes with the largest visible impact.
- Re-test on a real deviceConfirm the fix actually feels faster on a mid-range phone over mobile data, not just in a lab score improving.
- Set a recurring checkRe-audit whenever you add a new plugin, tracking script or major content update, performance regresses quietly over time.
Traffic is expensive. A slow page is a silent tax on every rand you spend to earn that visit.
Nexus conversion principle
Load-shedding and backup power add a layer most speed guides ignore
A site hosted on a server behind unreliable local power, or reliant on a business’s own on-site infrastructure during an outage, faces availability problems that no amount of image compression will fix. This is a strong argument for hosting with reputable providers carrying their own backup power and redundancy, rather than infrastructure exposed to the same load-shedding schedule as the business itself.
Even with solid hosting, visitors browsing during an outage window are more likely doing so on mobile data with a low or non-existent Wi-Fi fallback, and possibly on a phone running low on battery from an extended outage. This is one more reason mobile-first, lightweight design is not a nice-to-have for South African businesses, it is a direct response to real, common browsing conditions your customers actually face.
Explaining a "performance budget" to people who do not care about milliseconds
Frame it the way you would a financial budget: every image, script and font is a line-item expense against a limited allowance of milliseconds before visitors start leaving. A new tracking pixel or embedded widget is a withdrawal from that budget, and it needs to earn its place before it gets approved.
This framing tends to land with sales and leadership stakeholders who would otherwise wave through "just add one more script" without realising it is not actually free. Every addition costs patience, and eventually costs enquiries.
Give whoever manages the site day to day informal ownership of that budget, along with explicit permission to push back on additions that threaten load time on money pages without a strong justification behind them.
How speed connects to SEO and paid media, without overselling it
Search engines treat page experience signals, including Core Web Vitals, as one ranking factor among many, meaningful, but not a magic switch that alone determines rankings. Treat speed as a direct conversion lever first, and a supporting SEO factor second.
For paid traffic specifically, a slow landing page directly undermines the return on every click you already paid for. If you run paid campaigns, audit landing page speed with the same seriousness you audit ad copy and targeting, the ad did its job; do not let the page waste it.
Speed work pairs naturally with broader conversion rate optimisation, see our CRO guide for how to sequence speed fixes alongside message and trust improvements rather than treating them as separate projects.
What to do next
This week: run your homepage and top landing page through a real-device test on mobile data, not a lab tool on office Wi-Fi, and note the two or three heaviest elements.
Fix images and unnecessary scripts on those specific pages first, usually the fastest, most visible win available to you right now.
Build the habit of re-checking performance whenever you add new scripts, plugins or major content. Speed regresses quietly, one small addition at a time, rather than all at once.
.png)
