Why is your business website slow on mobile?

TL;DR: A business website slow on mobile usually asks the phone to download too much, run too much code, or wait too long before showing useful content. First identify whether the problem is a blank screen, a late main image, an unresponsive button or moving content. Test an important customer journey, then fix the delay you can actually measure.

By Max Mendes, freelance web developer based in Częstochowa, Poland. Published 10 October 2026.

Your homepage opens quickly on the office laptop. On a phone, the service heading appears late and the menu ignores the first tap. Those are different problems. Compressing a photograph may fix one while leaving the other untouched.

This guide helps you work out what to check before paying for faster hosting, adding an optimisation plugin or commissioning a rebuild. You do not need to read every line of code. You need evidence that connects the delay to something a customer is trying to do.

Why is the website fast on desktop but slow on mobile?

A phone can have less spare processing power and a less consistent connection than the computer used to build the site. The same page can therefore take longer to download, process and display. A layout that fits the screen is not necessarily a fast layout.

JavaScript adds work after downloading: the browser must parse, compile and execute it. Images need downloading and decoding. Fonts, maps, booking widgets and tracking tools add their own requests. Several individually small features can make the first visit feel heavy.

Start by separating the symptoms:

These are starting points, not diagnoses. A late image can be caused by slow hosting, a large file, late discovery or code preventing it from appearing.

How do you test mobile website speed properly?

Pick three pages: the homepage, an important service page and the page where a visitor contacts you or books. Testing only the homepage can miss a heavy form, gallery or booking integration.

Open each URL in PageSpeed Insights. Select mobile. First check whether the real-user report describes that exact URL or the whole website's origin. Origin data is useful background, but it cannot isolate the page you just tested.

Then look at the lab diagnostics. They show one controlled test, useful for finding bottlenecks. Repeat the test a few times if the results vary. Keep the conditions and URL the same so you can compare changes fairly.

Google's real-user report covers a rolling 28-day period. A new or lightly visited page may lack enough samples. That is not a failure: use lab tests and real-device checks while gathering better evidence.

Make a simple record:

On a real phone, turn off Wi-Fi for one test. Open the menu, scroll, accept or decline cookies, complete the form and check its confirmation. A score cannot tell you whether the customer journey still works.

What do LCP, INP and CLS actually tell you?

Google's Web Vitals guidance separates loading, responsiveness and stability. The three measurements help you name the problem instead of calling everything “slow”.

These targets apply at the 75th percentile of real-user measurements. Think of that as checking whether at least three quarters of the measured experiences meet the target, rather than relying on the fastest visit.

LCP does not mean the entire page has finished loading. CLS has no unit: it is not a time in seconds. A normal Lighthouse page-load test cannot measure INP because it does not perform a visitor's interactions. Total Blocking Time is a useful lab clue, but it is not the same measurement.

Google recommends good Core Web Vitals as part of page experience. Treat them as useful targets, not a promise of rankings or indexing. A faster page still needs relevant content and a clear purpose.

Why does the main image take so long to appear?

The main image may be too large, but first check when its download starts. A small image discovered late can still produce a poor LCP result.

Google's LCP optimisation guide breaks the wait into server response, resource discovery, resource download and the delay before rendering. That distinction prevents a common mistake: repeatedly compressing an image while another part of the page holds it back.

Ask your developer to identify the actual LCP element. If it is an image, check that phones receive a suitable size and that the browser discovers it early. The first screen should not depend on an unnecessary script to create its main content.

Do not lazy-load the LCP image. Lazy loading postpones downloading until the browser determines where the image is. Google's image-loading guidance recommends it for images outside the initial viewport instead.

A large gallery below the service description is a good candidate. The photograph that introduces the business usually needs different treatment. Changing every image to the same loading setting ignores their different jobs.

Why do the menu and enquiry form respond slowly?

A visible page can still be busy. Downloaded scripts may be running while the customer tries to open the menu or type into a field.

The INP optimisation guide explains that interaction delays can happen before a handler starts, while it runs, or before the resulting frame appears. Long JavaScript tasks are one possible cause. The fix should follow the part of the interaction that is actually slow.

Test during the initial load, not only after waiting ten seconds. Try opening the menu as soon as you can see it. Then test the contact form, validation messages and submit button. These are more useful checks than clicking a decorative animation.

Possible improvements include removing unused code, loading optional features later and splitting lengthy work into smaller tasks. If a plain service page ships an entire application to display mostly text, review whether that work is necessary. My article on HTML-first websites explains that architectural choice in more detail.

Do not disable scripts in bulk. A faster page with a broken form is a worse business website.

Can maps, cookie tools and tracking make a difference?

Yes. Third-party features can add network requests and processing work, sometimes across every page even when the feature is used on only one.

List each external tool and its purpose. Check whether a map needs to load before anyone asks for directions, whether a booking embed belongs on every service page, and whether two analytics tools duplicate the same job. Replace an immediate embed with a useful link or click-to-load interaction where that fits the visitor's task.

Consent changes what loads, so test before choosing, after accepting and after declining. Do not improve a score by removing required consent behaviour or delaying scripts in a way that breaks tracking rules. Check the implementation with the person responsible for it.

Change one feature at a time and compare results. Otherwise you may know the page improved without knowing which change helped, or which feature stopped working.

Why does the page move while someone tries to tap?

Unexpected movement often happens because an image, embed or other element arrives without space reserved for it. Fonts can also change the size of text after it appears.

Google's CLS guide recommends image dimensions or an appropriate aspect ratio so the browser can reserve space. Apply the same thinking to booking forms, videos and maps. Avoid inserting a late banner above the button a customer is about to use.

Scroll through the page after it loads. A standard page-load test can miss later shifts, including those caused by content further down the page. On mobile, a small movement near a contact button can be particularly noticeable because there is less room around the target.

Should you change hosting or rebuild the website?

Change hosting when measurements show the server response is a meaningful bottleneck. Faster hosting cannot remove unnecessary browser work or fix an image that the page discovers late.

Start with the smallest change supported by the evidence. Resize the image, reserve the missing space, remove a redundant integration or fix the slow interaction. Then retest. Consider a rebuild when the existing structure repeatedly prevents useful improvements, not because one report contains a red number.

A focused SEO and performance review can separate those choices. If the underlying structure needs changing, web development should preserve the pages, content and customer actions that already work.

How do you know the improvements worked?

Compare the same pages under comparable conditions. Keep a record of the changes and check that enquiries, booking, navigation, accessibility and consent still work. Lab results can show an immediate improvement; the rolling real-user report takes time to reflect new visits.

The practical finish line is a page that shows the useful content promptly, responds to taps and stays stable while someone completes their task. Keep monitoring after adding new tools or changing the design, because performance can regress.

If you want help, send me the slow page and the task that fails. Include the phone, connection and what you notice. That gives us a concrete starting point for deciding whether you need a small fix, a performance review or a larger change.