If your site feels fine on desktop but crawls on phones, you’re not alone. Here’s how to diagnose the problem quickly, the most likely causes (ranked), and the fixes that improve mobile Core Web Vitals first.
WebHouz
When someone says "your site is slow", they almost always mean: it feels slow on my phone. That is where the majority of local searches happen in Australia, and it is where your potential customers are deciding whether to stay or bounce.
The good news is that mobile slowness is diagnosable. Most Australian business websites are slow for one of six reasons — and those reasons have clear fixes. This guide helps you identify which one (or which combination) applies to your site.
Desktop browsers have more CPU power, faster memory, and often a wired or strong Wi-Fi connection. Mobile devices run on ARM chips with thermal throttling, connect over 4G (or worse in regional areas), and compete with background apps for processing time.
When Lighthouse runs its mobile simulation, it throttles the CPU to 4x slower than a typical mid-range desktop — which is a realistic representation of a common Android phone. Your site may load in 1.5 seconds on a MacBook and 4.2 seconds on the same network from a mid-range phone.
The Core Web Vitals metrics — LCP, INP, and CLS — were specifically designed to capture this experience. They measure what users feel, not what servers deliver.
Running a quick test first saves you from fixing the wrong thing.
If you need the metric definitions explained: What are Core Web Vitals?
For a full step-by-step audit process: How to audit your website speed (Lighthouse + CrUX)
Signs: LCP is 4+ seconds and the LCP element is an image or background image.
This is the most common cause of slow mobile performance for Australian business websites. A full-width hero image uploaded at original resolution — often 4–8 MB from a photographer or stock photo site — can single-handedly push LCP to 5–8 seconds.
Fixes in order:
srcset attribute — do not send a 2,400px image to a 390px phone screenbackground-image for your LCP element — browsers cannot preload these as efficiently as <img> tagsSigns: INP is over 200ms, interactions feel sticky or laggy, "Reduce unused JavaScript" appears in Lighthouse.
Every third-party script — analytics, pixel, chat widget, booking embed, heatmap, A/B testing tool — runs on the main thread and competes with user interactions. When someone taps a button on a phone with 10+ scripts loaded, the browser is already juggling too much work to respond immediately.
Common culprits:
Fixes in order:
async or defer attributes, or load via Google Tag Manager with appropriate triggersSigns: You are running WordPress with Elementor, Divi, WPBakery, or similar. Multiple CSS and JavaScript files load on every page. Mobile performance is consistently poor despite other fixes.
Page builders are designed for visual convenience, not performance. They output more HTML, CSS, and JavaScript than a custom-built equivalent. Each plugin adds its own assets. After years of adding plugins for forms, sliders, caching, SEO, and booking functionality, a WordPress site can easily load 30–50 separate files on every page request.
Fixes in order:
Relevant comparison: Next.js vs WordPress vs Webflow: speed and SEO compared
Signs: Text appears late, loads as invisible, or snaps into place when fonts load (sometimes called Flash of Invisible Text).
Loading Google Fonts or other web fonts can add 300–600ms to mobile page load if not handled correctly. By default, the browser will not display text until the font file downloads — which is particularly painful on slow 4G connections.
Fixes:
font-display: swap in your @font-face declarations — this tells the browser to show a fallback font immediately while the real font loads<link rel="preconnect"> hint to your HTML <head> to start the DNS lookup earlySigns: Content jumps while loading. Buttons move before you can tap them. CLS score is above 0.1.
Cumulative Layout Shift measures visual instability — how much content moves around after the initial render. The most common causes are images without dimensions, dynamically injected content (cookie banners, chat widgets), and iframes or embeds without reserved space.
Fixes:
width and height attributes on images so the browser reserves space before the image loadsaspect-ratio CSS property on iframes and video embedsSigns: Time to First Byte is over 600ms. "Reduce initial server response time" appears in Lighthouse. Even cached pages feel slow to start loading.
TTFB measures how long the browser waits before receiving the first byte of your HTML. If this is high, everything downstream is delayed — the browser cannot start parsing HTML, downloading CSS, or discovering images until it receives that first response.
Fixes:
The combination of page builders, plugins, and shared hosting creates a perfect storm for slow mobile performance. Caching plugins help, but they do not fix fundamentally bloated templates. If you are regularly implementing "performance fixes" every few months and still not hitting your targets, it may be worth evaluating the rebuild cost against the ongoing maintenance burden.
For cost estimates: Website speed optimisation cost in Australia (2026)
Shopify's hosting infrastructure is generally fast, but the theme layer and app ecosystem can add significant weight. Some popular marketplace themes include animations, sliders, and scripts that activate site-wide. Shopify apps often inject scripts onto every page even when they are only needed on specific ones. The fix: audit your active apps and theme code, and consider switching to a leaner theme if the current one is heavily bloated.
Webflow generates clean code but its interaction library and animation scripts add meaningful JavaScript weight. Avoid complex scroll animations and interaction triggers on mobile — they are often the INP culprits. Use conditional loading where Webflow's features allow.
Sites built with Next.js, Astro, or similar modern frameworks are typically already performant at the framework level. If they are slow, it is almost always third-party scripts or large images — the same causes as any other site. See: Why we build with Next.js
If you have done the diagnosis and know what is failing, prioritise in this order:
For a structured checklist: Website performance audit checklist + report template
If you have addressed images, scripts, fonts, and layout, and your mobile score is still below 50, your platform stack is probably the bottleneck. Page builders, bloated themes, and shared hosting have performance ceilings that cannot be overcome by optimisation alone.
A performance-first rebuild on a modern framework (Next.js, Astro) typically delivers 3–5x improvements in LCP compared to an optimised page builder site — not because of magic, but because the output is structurally leaner from the start.
If you are at this decision point:
Mobile devices have significantly less CPU power and often slower, more variable network connections. Google's Lighthouse uses a 4x CPU throttle for mobile simulation, which reflects the performance profile of common Android devices. Your site that loads in 1.5s on desktop might genuinely take 4s on a mid-range phone.
Test your page in PageSpeed Insights, identify your LCP element, and optimise that first. If it is an image, compress it to WebP and reduce its file size. This single change often cuts LCP by 1–3 seconds.
Open Chrome DevTools, go to the Network tab, filter by "JS", and count the external script files loading. More than 15–20 external scripts is a sign of accumulation. Check your Google Tag Manager container for unused tags — most sites have 5–15 that are no longer needed.
If your site generates leads or sales, almost always yes. A 1-second improvement in LCP correlates with measurable conversion rate improvements for most types of websites. The question is whether optimisation or a rebuild gives better return on your specific situation. Website speed optimisation cost in Australia (2026) breaks down typical investment ranges.
If you are spending money on repeated performance fixes and seeing diminishing returns, if your developer tells you the platform limits what is possible, or if your Lighthouse score consistently stays below 40 despite targeted fixes — those are signals that a rebuild will deliver better long-term value than continued patching.
Run the 60-minute audit: How to audit your website speed (Lighthouse + CrUX). Then follow the full performance playbook: Website Performance & Core Web Vitals: the Australian business guide. If you would like professional help diagnosing and fixing mobile performance issues, start with our Website Performance service.
Let's talk about your project and how we can help you build a website that actually performs.