Website slow everywhere or only on mobile data: which fix applies

Part of our guide on learn seo beginners

Two free comparisons tell you whether your slow site needs new hosting or just smaller images – most owners guess wrong and pay for it.

Why is my small business website loading slowly

A slow site has exactly two halves: the time your server takes to answer, and the time the browser takes to build the page afterwards. Almost every slow-website complaint is one of those two, and they have completely different fixes.

The other useful split is where you test from. If the site feels fine on your office Wi-Fi but crawls on a phone using mobile data, the problem is page weight, not the server. If it is slow everywhere, including on a fast connection, suspect the response time itself.

Run both comparisons before you buy anything. People routinely pay for better hosting when their images are the problem, or spend a weekend compressing images when the host is the bottleneck.

Why it happens: the four usual causes

In order of how often we see them, these are the causes behind a small business site that has suddenly or gradually got slow. The other half of this decision is google search console overview.

• Oversized images – a photo straight off a phone camera can be 5MB when it needs to be 150KB.
• Crowded shared hosting – your site shares a server with hundreds of others, and response time drifts up as neighbours get busy.
• Render-blocking scripts – chat widgets, analytics, ad tags and font loaders that all run before anything appears.
• No caching – every visitor forces the server to rebuild the page from scratch instead of serving a stored copy.
• Too many plugins (WordPress) – each one adds database queries and scripts to every page load.

Run two tests before spending anything

Open your site in Chrome or Edge, press F12, and click the Network tab. Reload the page with the cache disabled (tick 'Disable cache' in the tab). The first request in the list is your HTML document – click it and look at 'Waiting for server response'. That figure is your time to first byte, or TTFB.

As a rough rule, under about 600ms is fine; 200ms or less is good. If it sits above 800ms on repeat loads at low traffic, a shared host has stopped keeping up. Note that TTFB measures server response, not the full loading experience Core Web Vitals tracks with metrics like LCP and INP. If TTFB is fast but the blue bar at the bottom of the Network tab keeps climbing for seconds, the page itself is heavy.

Second test: open dev tools on your phone's browser is fiddly, so use the throttle instead. In dev tools, click the Network 'Throttling' dropdown and pick 'Slow 4G'. That simulates a typical mobile data connection. Aim for a total page weight under 1.5MB on mobile – you'll see the total at the bottom of the Network tab once the page finishes loading. If the site becomes painful only under throttling, page weight is your problem. People in this spot often ask about fix slow website loading as well.

1. Press F12, open the Network tab, tick 'Disable cache'.
2. Reload the page and click the first request; note 'Waiting for server response' (TTFB).
3. Watch the total load finish; note the full load time and the largest files listed.
4. Set throttling to 'Slow 4G' and reload; note how the experience changes.
5. Compare: slow TTFB = server; slow full load only = page weight.

If the first byte is slow: what to change first

Cheapest fix first: install caching. On WordPress, a plugin such as LiteSpeed Cache or WP Super Cache stores finished pages so the server stops rebuilding them for every visitor. If your TTFB drops from seconds to a few hundred milliseconds, you are done and have spent nothing.

If caching is already on and TTFB still tops 800ms consistently at low traffic, the shared hosting plan has hit its ceiling. That is the threshold where the response time is the host's fault, not your page's: your HTML document should not take a second to arrive when only a handful of people are visiting.

This is the point where moving to a better-value host makes sense. Check whether your shortlisted host includes free migration, NVMe storage and a CDN – many budget plans advertise these, but confirm the details on the current plan page before you commit. NVMe storage and a built-in CDN directly target the slow first-byte symptom. What they will not do is rescue a page that is still five megabytes of uncompressed images; fix those regardless of host. If your current host bills annually, wait until renewal unless the site is losing you customers today. The other half of this decision is fix lcp issues with hero image.

Before paying for anything, contact your current host's support and ask them to review your site's response time. Many hosts can spot database issues, plugin conflicts or configuration problems their dashboard does not surface, and the advice costs you nothing.

Fast first byte but slow on mobile data: fix the page

When TTFB is healthy but 'Slow 4G' throttling makes the site crawl, sort the Network tab by size. The biggest entries are your targets. Phone photos are the usual offender, followed by web fonts, videos set to autoplay, and chat or analytics scripts.

Images first, because it is free and it is usually half the page weight. Resize images to the width they actually display at – a content column rarely needs more than 1200 pixels – and compress them with Squoosh or TinyPNG before uploading. On WordPress, install an image optimiser plugin so new uploads are handled automatically. Add width and height attributes so the page does not jump while loading. We go through featured snippet stealing clicks step by step elsewhere on the site.

Next, trim scripts. In dev tools, the requests marked 'render-blocking' hold up everything after them. Remove chat widgets you do not use, load analytics with deferred loading, and cut plugins you can live without. Each removal is testable: reload under throttling and watch the full load time fall.

Page builders need extra attention

If you built your WordPress site with Elementor, Divi or a similar page builder, your throttled test will often show slower results than a plain-theme site. Page builders generate more HTML and load their own CSS and JavaScript on every page, which adds weight you cannot remove without switching builders.

Your fix is the same – compress images, cut unused widgets, defer scripts – but your ceiling is higher. Aim to keep the full page under 2MB instead of 1.5MB, and accept that TTFB may run 100-200ms slower because the builder adds database queries. If the site is still painful under 'Slow 4G' after image compression, consider switching to a lighter theme or using the builder only on key pages like the homepage. For the detail, see our notes on get your digital key instantly.

Test a plain page first. Create a test page with no builder blocks, just text, and compare its load time to a builder-heavy page. The difference is the cost of the builder itself, and it tells you whether the builder is a problem or your content is.

What caching and a CDN genuinely fix

Caching stops your server rebuilding the same page for every visitor, which improves first byte and survives traffic spikes. A CDN stores your images, CSS and scripts on servers around the world, so files travel a shorter distance to the visitor. Both are worth having, and both are often included with hosting plans.

What they only hide: page weight. A CDN will happily deliver a 5MB image quickly to a phone on weak signal, and the phone still has to download all 5MB. If your 'Slow 4G' test is painful, no amount of caching or CDN rescues you – the images and scripts have to shrink first. It helps to understand reduce bounces and spam traps before going further.

The honest order is therefore: compress the page, then cache it, then distribute it. Skipping straight to the tools leaves you paying for infrastructure that papers over the real problem.

Other causes of perceived slowness

Sometimes the site itself is fast, but the path to it is not. If visitors complain about slowness but your tests look fine, check for redirect chains – a www to non-www redirect that then redirects to HTTPS, for example, adds two round trips before the page even starts loading. Run a redirect checker and flatten any chain longer than one hop.

Email links can introduce the same delay. If you send visitors a link that redirects through a tracking domain before landing on your site, that tracking hop adds latency the user feels as slowness. Test the exact link you send, not the final destination.

DNS resolution can also cause a slow first visit. If your domain's DNS records are hosted on a slow or distant nameserver, the browser waits for that lookup before making the first request. Subsequent visits are cached, so this only affects new visitors. Check your DNS provider's response time with a tool like DNSPerf, and consider moving to a faster provider if lookups consistently take over 50ms.

How to stop it happening again

Make the two tests a monthly habit. Press F12, check TTFB and total load under 'Slow 4G' throttling, and write the numbers down. A slow creep over months tells you the hosting is filling up; a sudden jump tells you a plugin or upload is to blame.

Set rules for anything that touches the site. Every image gets resized and compressed before upload. Every new plugin or widget has to justify its load time. Run a free PageSpeed Insights check after any change so you have a before-and-after record.

And keep a staging or backup copy before major changes. Pick a host that includes automatic daily backups, or run your own backup plugin, so a bad plugin day is a five-minute rollback instead of an evening of rebuilding. Whatever solution you use, confirm the backup actually exists before you need it.

Questions people still ask

Half the slow sites I look at have sub-second server response and a 6MB hero image – the two tests above would have saved the owners a hosting upgrade they never needed.