Why is my website slow on mobile? Causes and fixes for small businesses

Most small-business websites that are slow on mobile have one of four causes: oversized images, slow hosting, a heavy page builder or theme, or too many third-party scripts such as chat widgets, maps and tracking tags. Google's guidance is that the main content of a page should appear within 2.5 seconds, and anything over 4 seconds is poor. In our checks, 21.2% of 32,933 UK small-business websites and 18.7% of 41,368 US ones took 4 seconds or more on mobile.

This guide explains how Google measures speed, how to test your own site in two minutes, and the fixes for each cause, in the order that usually makes the biggest difference.

How common is a slow mobile site?

Slow mobile loading was the second most common fault in both countries, after a missing meta description. A further 2.1% of UK sites and 1.8% of US sites had a slow server response, taking 1.5 seconds or more just to start sending the homepage. Source: SiteVerdict automated checks, 4 October to 3 November 2026, using Google's PageSpeed test for mobile speed. See the UK study and US study for the full method.

How Google measures speed: Core Web Vitals

Google uses three Core Web Vitals to measure the experience of loading and using a page. The thresholds below are from web.dev and PageSpeed Insights, checked on 3 November 2026.

• Measured at the 75th percentile. To pass, at least three in four visits must hit the "good" level, measured separately for mobile and desktop.
• INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.
• Time to First Byte (TTFB) is not a Core Web Vital, but PageSpeed Insights rates 0.8 seconds or less as good and over 1.8 seconds as poor. A slow TTFB delays everything else.

Why it matters

Google says Core Web Vitals are used by its ranking systems, though good scores do not guarantee a top ranking. The bigger cost is visitors who give up. The Milliseconds make millions study by Deloitte and 55, commissioned by Google (2020), found that a 0.1-second improvement in mobile speed was associated with 8.4% more retail conversions and 10.1% more travel conversions, across 37 brands and over 30 million sessions. Those were large brands. The direction applies to small sites too: faster pages lose fewer visitors.

How to test your site in two minutes

1. Go to PageSpeed Insights and enter your homepage address.
2. Make sure the Mobile tab is selected.
3. Look at the top section, "Discover what your real users are experiencing". This is field data from real Chrome users over the previous 28 days. If your site has too few visitors, this section may be empty.
4. Look at the lower section, "Diagnose performance issues". This is lab data from a simulated test run by Lighthouse. It gives a score out of 100 and the LCP, CLS and other timings.
5. Scroll to the diagnostics. Look for items such as "Largest Contentful Paint element", "Properly size images", "Reduce unused JavaScript" and "Reduce initial server response time". These point to the cause.
6. Repeat for your most important page, such as your main service page or contact page.

The four common causes, and how to fix each

1. Oversized images

The most common cause on small-business sites is a hero image or slider at the top of the page that was uploaded straight from a camera or stock site. A photo several thousand pixels wide is far larger than a phone screen needs.

Fixes:

1. Resize before uploading. For a full-width image, around 1,600 to 2,000 pixels wide is plenty for most screens. Smaller images, such as team photos, need far less.
2. Compress and use a modern format. WebP or AVIF images are usually much smaller than JPEG or PNG at similar quality. Many builders convert automatically. On WordPress, an image optimisation plugin can do it.
3. Never lazy-load the main image. web.dev's LCP guide says: "Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay." Use loading="lazy" only for images further down the page.
4. Prioritise the main image. Adding fetchpriority="high" to the main image tells the browser to fetch it first. Use it on one image, not many.
5. Set width and height. web.dev recommends width and height attributes on every image so the browser reserves space. This prevents layout shift (CLS).
6. Replace sliders with one image. A carousel loads several large images and often a script to run it. A single strong image with a clear headline is usually faster.

<img src="/images/hero-1600.webp" width="1600" height="900"
     alt="Electrician fitting a consumer unit" fetchpriority="high">

<img src="/images/team.webp" width="800" height="533"
     alt="Our team outside the office" loading="lazy">

2. Slow hosting

If the server takes a long time to start sending the page, everything else waits. In PageSpeed Insights, look for "Reduce initial server response time" or a high TTFB. Cheap shared hosting, an overloaded server or a host far from your visitors are typical causes.

Fixes:

• Turn on page caching. On WordPress, use your host's caching or a caching plugin so pages are served ready-made rather than built on every visit.
• Use a CDN. A content delivery network serves your files from a location near the visitor. Many hosts include one.
• Update PHP and plugins (WordPress). Newer versions are generally faster. Remove plugins you do not use.
• Cut redirects. Each redirect, such as http to https to www, adds a round trip. Link directly to the final address.
• Consider a better host. If TTFB is still poor after caching, the hosting plan may be the limit.

Hosted builders such as Wix, Squarespace, Shopify and Webflow manage their own servers, so on those platforms this cause is usually out of your hands. Focus on images and scripts instead.

3. Heavy page builders and themes

Drag-and-drop page builders and multi-purpose themes can load a lot of CSS and JavaScript on every page, including code for features you do not use. In PageSpeed Insights this shows up as "Reduce unused JavaScript", "Reduce unused CSS" or "Eliminate render-blocking resources".

Fixes:

• Turn off features you do not use in the builder or theme settings, such as animations, icon libraries and extra fonts.
• Limit web fonts to one or two families and the weights you need.
• Remove animations above the fold. Fade-in effects on the hero section delay the main content appearing.
• Use a lighter theme when you next redesign. For a simple small-business site, a lightweight theme or the platform's built-in blocks are often enough.

4. Third-party scripts

Chat widgets, booking widgets, embedded Google Maps, video embeds, social feeds, review widgets and tracking tags each load code from another company's servers. Each one adds download time and processing on the phone, which also hurts INP.

Fixes:

• Audit what you load. List every widget and tag. Remove any you no longer use or look at.
• Load scripts after the main content. web.dev's third-party JavaScript guide recommends async or defer so scripts do not block the page.
• Replace live embeds with a link or image. A static map image linking to Google Maps, or a video thumbnail that loads the player when tapped, is much lighter than a live embed on page load.
• Lazy-load embeds below the fold. Iframes support loading="lazy".
• Keep the tag manager tidy. Old tags from past campaigns often keep firing for years.

Fix plan: the order to work in

Lab results change straight away. Field data in PageSpeed Insights and Search Console's Core Web Vitals report covers a rolling 28 days, so it takes up to four weeks to fully reflect a fix.

Fixing INP and CLS

If INP is poor (slow to respond to taps)

• Too much JavaScript is the usual cause. Remove or defer third-party scripts first.
• Menus, accordions and sliders built with heavy scripts can be slow to respond. Simpler versions, or the platform's built-in components, are often lighter.
• Pop-ups and cookie banners that run a lot of code when tapped can also cause poor INP. Choose a lightweight consent tool.

If CLS is poor (the page jumps)

• Add width and height to every image and video.
• Reserve space for anything that loads late, such as cookie banners, review widgets and adverts.
• Avoid inserting banners above existing content after the page has loaded.
• Fonts that swap late can shift text. Limit font families and weights.

When to call in a developer

Most image and widget fixes can be done by the owner in the site editor. Get help if:

• PageSpeed Insights still shows a poor LCP after you have resized and compressed the main image and removed unused widgets.
• Time to First Byte stays above 1.8 seconds after caching is turned on.
• Diagnostics point to "render-blocking resources" or "unused JavaScript" in theme files you cannot change from the dashboard.
• Your site is a custom build with no editor settings for images or scripts.

Ask for specific targets: LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less on mobile, as measured in PageSpeed Insights. Ask for before-and-after reports so you can see what changed.

Platform notes

• WordPress: you control the most, so you can fix the most. Caching, image optimisation and removing unused plugins usually help most.
• Wix, Squarespace, Webflow, Shopify: hosting is managed for you. Focus on image sizes, the number of apps and widgets, sliders and embedded content. On Shopify, every app you add may load scripts on the storefront.
• Any platform: the main image and third-party scripts are usually where the time goes.

For a view across platforms, see our website builder fault rates. SiteVerdict checks mobile speed alongside other common faults, such as a missing meta description and an untappable phone number, on any site. Use the Chrome extension, the WordPress plugin or the Shopify app.