The store where the dashboards disagree: rising CPCs, flat conversion rate
A hypothetical mid-market South African retailer spends upwards of R250,000 per month across Google and Meta. CPCs are creeping up, CPA is climbing, and conversion rate has been flat for two quarters. The site looks fine on desktop in Sandton, and a desktop Lighthouse run returns a score in the high 80s. Yet checkouts from mobile users on mid-range Android devices are slow, and the product page takes several seconds before the hero image appears. A store carrying six third-party scripts-a chat widget, consent banner, reviews platform, heatmap tool, tag manager, and currency converter-each injects JavaScript that blocks the main thread. The problem is not design. It is speed, and it is measurable.
Why your Lighthouse score and your revenue disagree
Lighthouse runs a synthetic test on a single page under controlled conditions. It is useful for diagnosing opportunities, but it does not reflect the real-world experience of your visitors. Google's ranking systems use field data from the Chrome User Experience Report (CrUX) and, if you provide it, your own Real User Monitoring (RUM) data. Field data captures the p75 (75th percentile) of visitors, segmented by mobile and desktop. A store can score well in the lab but fail in the field because the lab test excludes third-party scripts that load after the test completes, or it tests on a fast connection your mobile audience does not have. A one-off audit, however detailed, is not enough. You need continuous field measurement.
Lab data vs field data: what Google actually uses, and why CrUX beats a one-off audit
Google uses field data for ranking. Lab data in PageSpeed Insights is diagnostic only. CrUX provides field data for millions of sites, and if your site has enough traffic you can see your own CrUX data in PageSpeed Insights and Search Console. But CrUX is aggregated over a 28-day window and only includes URLs meeting a minimum traffic threshold. For deeper, template-level analysis, you need your own RUM. Tools like Google Analytics 4 or dedicated RUM platforms capture Core Web Vitals from real sessions, and you can segment by template (home, collection, product, cart, checkout), device type, and connection type. That segmentation matters: your product template likely carries the heaviest third-party load, and your checkout template may have the most layout instability.
What Core Web Vitals thresholds mean in practice (LCP, INP, CLS at p75)
Core Web Vitals measure loading, interactivity, and visual stability. Thresholds for a "good" experience are set at the 75th percentile of page loads, segmented by mobile and desktop.
| Metric | Good threshold (p75) | What it measures | Common ecommerce cause |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2.5s | Time until the largest content element is rendered | Unoptimised hero or product images, slow server response |
| INP (Interaction to Next Paint) | ≤ 200ms | Responsiveness to user interactions throughout the page lifecycle | Heavy third-party JavaScript blocking the main thread |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | Visual stability; unexpected layout shifts | Banners, ads, or late-loading fonts shifting content |
INP replaced First Input Delay (FID) in March 2024. FID measured only the delay before the first interaction, while INP measures full interaction latency, including time to render the next frame. Many stores that passed FID now fail INP because third-party scripts-chat widgets, consent banners, tag managers, review widgets-still execute long tasks during interactions.
Google describes page experience and Core Web Vitals as a tie-breaker among similarly relevant pages. It is not a dominant ranking factor, but it can influence user behaviour and conversion rates, which indirectly affect revenue.
Baseline first: segmenting speed data by template, device and network
Before you change anything, establish a baseline. Use RUM to collect field data segmented by template and device. Your product template on mobile may have an LCP of 4.2s at p75 while your homepage sits at 1.8s; your checkout may have a CLS of 0.25 from a late-loading payment widget. Segment by connection type (4G, 5G, Wi-Fi) if your RUM tool supports it. In South Africa, the mix of 3G, 4G, and 5G networks and the prevalence of mid-range Android devices make mobile performance the priority. A site that feels fast on fibre in Sandton can be slow on a congested mobile network elsewhere. Set up a dashboard showing these metrics over time so you can see the impact of changes.
The third-party tax: which scripts are actually slowing your product page
Third-party scripts are the biggest culprit in ecommerce speed degradation: analytics, tag managers, chat widgets, consent management platforms (CMPs), review widgets, heatmap tools, and personalisation engines. Each adds network requests, parsing time, and execution time. On a product page it is common to see 10-20 third-party requests. Use the Coverage tab in Chrome DevTools or WebPageTest to identify which scripts consume the most main-thread time. Often a single chat widget blocks the main thread for hundreds of milliseconds, pushing INP above 200ms.
LCP: the hero and product image decisions that move the needle most
LCP is usually the easiest Core Web Vital to improve because it is often a single element: the hero image on the homepage or the main product image on a product page. Serve images in modern formats (AVIF or WebP), use responsive images with correct sizes, and preload the LCP image. Do not lazy-load the LCP image-it should load eagerly. Ensure server response time (TTFB) is fast; a slow server delays everything. Use a CDN to serve images close to users. For South African audiences, a CDN with points of presence in Johannesburg and Cape Town can reduce latency.
INP: the metric most South African stores broke without noticing
INP measures the latency of all interactions on a page. If a user taps a filter on a collection page and the page takes 500ms to respond, that is a poor INP. The main cause is long JavaScript tasks blocking the main thread, often from third-party scripts. To improve INP, break up long tasks, defer non-critical scripts, and reduce third-party tags. Chrome DevTools' Performance panel helps identify long tasks. A common fix is loading chat and review widgets only after user interaction or after the page has loaded.
CLS: layout shifts caused by banners, fonts and late-loading widgets
CLS occurs when elements shift unexpectedly. Common ecommerce causes: images without width and height attributes, ads or banners injected above content, late-loading fonts causing a flash of unstyled text, and dynamic content like personalised recommendations. To fix CLS, always include width and height attributes on images and videos, reserve space for ads and dynamic content, and use font-display: swap or preload fonts.
Shopify vs WooCommerce: where the speed constraints actually sit
On Shopify you have less control over the server and core platform, but you control your theme, apps, and third-party scripts. Each app can inject scripts on every page, so an app audit is critical. On WooCommerce you control hosting, plugins, and theme; constraints often come from poorly coded plugins, unoptimised hosting, and lack of caching. In both cases the fix order is similar: images and fonts, then critical CSS, then defer scripts, then reduce third-party tags. If you need expert help, explore our conversion rate optimisation services or learn about our web development and design capabilities.
The fix order: ranking speed work by effort-to-impact
Not all speed fixes are equal. Some are quick wins with high impact; others require development resources and yield smaller gains.
| Fix | Effort | Impact | Owner |
|---|---|---|---|
| Image optimisation (AVIF/WebP, sizing, lazy-load below fold) | Low | High | Front-end dev / Designer |
| Font loading (font-display, preload, subset) | Low | Medium | Front-end dev |
| Critical CSS and defer non-critical CSS/JS | Medium | High | Front-end dev |
| Reduce third-party tags (audit and remove) | Medium | High | Marketing / Dev |
| Server-side tagging to offload tags | High | High | Analytics / Dev |
| CDN and caching configuration | Medium | Medium-High | DevOps |
| Shopify app audit / WooCommerce plugin audit | Low-Medium | High | Marketing / Dev |
Start with the highest impact, lowest effort items to build momentum, then tackle higher-effort items like server-side tagging and CDN configuration.
Consent, POPIA and GDPR: the tension between compliance and render speed
A consent management platform (CMP) is necessary for compliance with POPIA (South Africa) and GDPR (UK/EU), but it can hurt speed if implemented poorly. A CMP that blocks rendering until the user makes a choice delays LCP. A CMP that loads late may still allow tracking scripts to fire before consent, which is a compliance risk. The technical goal: load the CMP asynchronously without blocking rendering, and conditionally load tracking scripts only after consent is given. This requires coordination between the CMP, your tag manager, and your consent signals. Always consult legal counsel for compliance advice.
Server-side tagging: moving tag weight off the client without losing attribution
Server-side tagging (server-side GTM) moves tag execution from the user's browser to a server you control. This reduces requests and JavaScript execution on the client, improving INP and LCP, and gives you more control over data quality, cookie lifetime, and attribution. It adds infrastructure and maintenance overhead, so it suits stores with a mature analytics setup and the resources to manage a server container. For more on our measurement approach, see our custom reporting approach.
How speed shows up in Google Ads and Meta costs
Landing page experience is a component of Google Ads Quality Score. A faster, higher-converting landing page can contribute to a better landing page experience rating, which can lower cost per click and improve Ad Rank. This is a correlation and a mechanism, not a guarantee. On Meta, fast-loading landing pages can reduce bounce rates and improve ad performance because users are more likely to engage. Speed is one of many factors, but it is one you control.
Setting a performance budget your team can defend
A performance budget sets limits on metrics like page weight, JavaScript size, and number of third-party requests. For example: 200KB of JavaScript per template and no more than three third-party scripts. Enforce it with automated checks in your build process. Here is a simple example using Lighthouse CI in a lighthouserc.json file:
{
"ci": {
"assert": {
"assertions": {
"resource-summary:script:size": ["warn", {"maxNumericValue": 200000}],
"resource-summary:third-party:count": ["error", {"maxNumericValue": 3}]
}
}
}
}This configuration warns if total script size exceeds 200KB and errors if third-party request count exceeds 3. Integrate it into your CI/CD pipeline to catch regressions before they reach production.
Measuring outcomes: CVR, revenue per session, CPA and landing page experience
The ultimate goal of speed optimisation is to improve business outcomes. Track conversion rate (CVR), revenue per session, average order value (AOV), cost per acquisition (CPA), and Google Ads landing page experience trend. Also monitor bounce rate and engagement in GA4. Use RUM to correlate speed improvements with these metrics over time. If you reduce LCP from 4s to 2.5s on the product template, you might see a conversion lift-but be careful: correlation is not causation.
How to avoid fooling yourself when attributing a lift to speed
Attribution is tricky. If you run a promotion at the same time as a speed fix, you cannot be sure which caused the lift. Use a controlled experiment where possible: roll out the fix to a subset of users and compare against a control group. Segment by device and template. Watch for seasonality and traffic mix shifts. Use RUM data, not lab scores, for the analysis, and consider whether other changes (new creative, bid strategy changes) influenced results. Explore our SEO and AI SEO services to learn how we integrate speed into broader performance programmes.
Be cautious when attributing conversion lifts to speed alone. External factors like promotions, seasonality, or traffic source mix can skew results. Use holdout groups and RUM data to isolate the impact.
Mobile speed in South Africa: network variability, device mix and data cost
In South Africa, mobile users often browse on mid-range Android devices over 3G, 4G, or 5G. Network variability means a site that loads quickly on Wi-Fi in an office may be slow on a congested mobile network. Data cost sensitivity means users may abandon slow-loading pages to save data. Mobile speed is not optional. Optimise for the median device and network, not the best-case scenario. Use a CDN with local points of presence, compress images aggressively, minimise JavaScript, and test on real devices and throttled connections.
Governance: pre-launch speed checks and regression monitoring
Speed optimisation is not a one-off project. Implement pre-launch speed checks in your deployment process: before any code goes live, run automated tests to ensure it meets your performance budget. Monitor field data continuously and set up alerts for regressions. Assign ownership: someone should review speed metrics weekly. This systemised approach prevents the gradual degradation that happens when new features and third-party scripts are added without oversight.
