Your website feels fast in the office because your test conditions are unusually favourable. The laptop may be powerful, the Wi-Fi fast, the cache warm and the route to the server short. A mobile customer may face higher latency, an entry-level phone, a cold cache, limited data and a page competing with other apps for memory and processing time.
Diagnose the difference with real-user field data, repeatable mobile lab tests and checks on physical devices. Then fix the bottleneck that affects customers, not the one that is easiest to see on office Wi-Fi. Strong web design and responsive web design include performance under realistic conditions, not only visual adaptation to a smaller screen.
Google’s web.dev guidance explains that field data includes varied networks, device capabilities and user behaviour, while lab data controls those variables and may not represent what most real visitors experience Source: web.dev. That difference is the starting point for the investigation.
Office Wi-Fi removes the delays your customers feel
Bandwidth is only one part of page speed. Mobile performance is shaped by latency, signal quality, device CPU, available memory, browser state, server location and the work required after files arrive.
An office test often benefits from:
- fast fibre and stable Wi-Fi
- a recent laptop with a powerful processor
- cached fonts, scripts and images
- repeated visits to the same pages
- a nearby company network or DNS resolver
- browser extensions or settings unlike customer devices
Mobile customers may experience the opposite. Even a connection with acceptable download speed can feel slow when latency is high and the page requires many sequential requests. A large JavaScript bundle may arrive quickly but still take too long to parse and execute on a weaker phone.
Start with field data from real users
Field data tells you what visitors actually experienced. Core Web Vitals field reporting commonly evaluates the 75th percentile, which focuses attention on the slower end of typical visits rather than the fastest office test.
Review mobile and desktop separately. Segment further in your own real-user monitoring where privacy and sample size allow:
- page template
- device class
- browser
- geography
- network type
- new versus returning visitor
- campaign or landing-page source
Look at Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, but keep server response and business actions in the same report. A page can pass one metric and still feel unresponsive during an important form or navigation step.
web.dev distinguishes field tools from lab tools and notes that Lighthouse’s simulated conditions represent only one slice of the variety users face Source: web.dev. Our guide to Core Web Vitals explains what each metric measures before you interpret the report.
Use lab tests to reproduce the slow experience
Lab tests are valuable because they are controlled and repeatable. Use them to reproduce a suspected problem, inspect the waterfall and compare changes before release.
Chrome DevTools allows CPU and network throttling. Its guidance recommends simulating mobile conditions and explains that actual DevTools throttling trades a longer test for a more direct constrained run Source: Chrome for Developers. Chrome also provides calibrated CPU presets and custom network profiles Source: Chrome for Developers.
Run at least these cases:
- cold-cache mobile navigation
- repeat navigation with cache available
- low-end or mid-tier CPU slowdown
- higher-latency network profile
- a real affordable Android device where possible
Test the important journeys, not only the homepage. A service landing page, quote form, product category or booking flow may load very different code and third-party scripts.
Check server response and network distance
A slow first response delays everything that follows. Review hosting location, CDN caching, server-side rendering time, database calls, redirects and cache-control headers.
For a South African audience, test from locations that represent the customer base. A server that is quick from the company’s office or an overseas testing region may have a slower route for customers on local mobile networks.
Useful checks include:
- time to first byte by region
- DNS and TLS connection time
- cache hit ratio at the CDN
- redirect chains before the final page
- uncached server rendering under load
- third-party API calls that block the response
Do not move infrastructure based on one synthetic test. Confirm the pattern with field data or tests from several representative regions.
Reduce image and font weight
Large media files consume data and delay the largest visible element. Deliver images close to their displayed dimensions, use efficient formats, provide responsive source variants and lazy-load images that begin below the fold.
Do not lazy-load the main hero image when it is the likely Largest Contentful Paint element. Prioritise it appropriately and avoid downloading a desktop-sized image for a narrow phone.
Fonts can also delay text. Limit unnecessary families and weights, subset where appropriate, preload only critical files and use a sensible fallback. A small visual difference may not justify several additional font downloads on a constrained connection.
The relationship between site speed and conversions matters because performance work should protect the customer journey, not only improve a technical score.
Cut JavaScript and main-thread work
Mobile phones can struggle after all files have downloaded. Hydration, large frameworks, tag managers, chat widgets, heatmaps and ad scripts compete for the main thread.
Use the Performance panel to identify long tasks and interaction delays. Remove unused code, split bundles by route, defer non-critical features and load third-party scripts only when their business value justifies the cost.
Pay special attention to:
- consent and analytics scripts that load multiple vendors
- carousels or animation libraries above the fold
- client-side rendering for content that could arrive as HTML
- validation libraries loaded on pages without forms
- chat or booking widgets loaded before the user needs them
If your website depends on essential tracking, reduce and sequence it rather than deleting measurement blindly. Confirm which tags support actual decisions and retire duplicates.
Test the complete customer journey
A homepage speed score does not tell you whether a customer can submit a lead form on a weak connection. Test navigation, form input, validation, payment or booking steps and confirmation states.
Look for functional failures as well as delay:
- buttons that become active before handlers are ready
- forms that lose data after a network interruption
- spinners with no timeout or recovery path
- address lookups that block manual entry
- images or scripts that consume the customer’s data before the main task works
If your website targets mobile customers, make the essential action resilient. The page should remain understandable and the contact route available even when optional enhancements fail.
My take: choose a customer performance budget
My take is that teams should define a performance budget around a representative customer device and route, not around the fastest device in the company. Choose an affordable handset, realistic latency, a cold cache and the most important landing page.
Set budgets for page weight, JavaScript, request count and key interaction timing. Enforce them in development and verify them against field data after release. The lab budget prevents regressions, while field data tells you whether the chosen conditions were realistic.
If your business serves South African mobile customers, include local test locations and devices in the release process. Generic global averages can hide a commercially important segment.
A practical investigation sequence
Day one: capture mobile field data and identify the slow templates, regions and user segments. Confirm sample size before drawing conclusions.
Day two: reproduce one slow journey in a throttled lab test. Save the trace, network waterfall and screenshots.
Days three to five: rank causes by expected customer impact and effort. Begin with server delay, the largest image, heavy JavaScript and blocking third parties.
Week two: release the smallest safe fixes, repeat the same lab test and watch field data over the appropriate reporting window. Record business outcomes such as form completion, calls and checkout progression.
If this feels familiar, do not approve a redesign solely from an office demonstration. Require performance evidence under representative conditions.
Frequently asked questions
Is mobile speed mainly a network problem?
No. Network latency matters, but device CPU, JavaScript, server response, caching, images, fonts and third-party code can be equally important.
Why does Lighthouse differ from Search Console?
Lighthouse is a lab test under defined conditions. Search Console’s Core Web Vitals report is based on field data from real Chrome users and an aggregation window, so the numbers can differ legitimately.
Should we optimise for a slow 3G preset?
Use it as a diagnostic scenario, not a universal description of every customer. Create profiles that reflect your audience and compare lab findings with field data.
Do Core Web Vitals guarantee more conversions?
No. They measure important aspects of page experience, but relevance, offer quality, usability and trust still influence conversion. Connect performance metrics to actual customer actions.
Make mobile performance part of the build standard
If your site looks fast in the office but customers still struggle, get in touch for a representative performance review. We can improve responsive web design within a wider web design programme and prioritise the delays that affect real journeys.