Why is a website slow on mobile? Start by identifying what the visitor is waiting for: the main content, a response to a tap or a task to finish. A large image, a slow server response and a demanding script need different fixes. A PageSpeed report can help locate them, but its score alone does not establish which problem to address first.
Open the page on the phone where the problem occurs. Note whether it is slow on arrival, when you tap the menu or while sending a message. That description is more useful for an assessment than knowing the site has an amber score.
What is slow on the phone?
The three Core Web Vitals cover loading, responsiveness and visual stability. LCP tracks when the largest visible content appears, INP measures responsiveness to interactions, and CLS measures unexpected layout shifts. Google's Web Vitals guidance sets good thresholds at LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. The assessment uses the 75th percentile of visits, with mobile and desktop considered separately.
When speaking to the person maintaining your site, describe the action. For example: “The heading appears immediately, but I wait for the product image,” or “The menu only opens after a second tap.” If it happens on one page or after choosing a filter, include that step.
Why does the PageSpeed result differ from using the phone?
A lab test loads a page with set device and network conditions. Visitors have different phones, connections and cached resources. Google's explanation of lab and field data describes these differences. CrUX covers experiences across a 28-day period, so its figures will not immediately reflect a fix published today.
Check the scope of the result too. PageSpeed Insights can show data for the whole site when a particular URL has too few samples. If the site also has insufficient data, no field result appears. That absence does not tell you whether the page is fast.
Keep the report link, date and selected mobile or desktop view. Label comparisons separately when they cover different pages or devices.
How do you find what delays the main content?
Find the element identified as LCP in the report. It may be an image or a text block. Then inspect the loading trace to see whether the delay is in the server response, downloading a resource or displaying it. Google's LCP guide explains this breakdown and warns against deferring the LCP image with loading="lazy".
If the image is the problem, ask for its filename and dimensions. Check its displayed size and the version the browser downloads. Responsive images use srcset and sizes to offer suitable sources; the browser chooses between them. Having smaller files on the server does not yet establish that one is being used.
For the initial repair proposal, ask for a clear finding: which element is late, where the delay appears and what will change. If the recommendation is a complete website build, ask which problems require it and which can be repaired on the existing page.
What if the menu is slow or the layout jumps?
When the page is visible but a button responds slowly, the test needs to include that tap. Long JavaScript tasks can occupy the browser's main thread and delay its response. The INP optimisation guide recommends testing user actions, including interactions during loading.
Test opening the menu, choosing a filter and submitting a form separately. For the form, also record how long the server response takes: the button may promptly show that submission has started while the response takes longer. A fix needs to preserve validation, consent choices and confirmation of successful submission.
If text or a button moves while you are using it, look for content that appeared later. An image without reserved space or an embedded element can push the rest of the page down. Google's CLS recommendations describe reserving space with image dimensions or the appropriate aspect ratio.
Which fix should come first?
Prioritise a problem that interrupts an important action and has reproducible evidence. For a shop, that might be choosing a product or using the basket; for a business website, reading the content and sending an enquiry. Agree what the fix should change and how you will check that the rest of the task still works.
Scroll the table sideways to see all columns.
| Symptom | Evidence to collect | Change if the cause is confirmed | Check after the change |
|---|---|---|---|
| The main image arrives late | A trace shows the source, dimensions and when its download starts. | Correct image selection or the delay in loading that image. | Check the selected file, appearance and timing under the same conditions. |
| The page waits for the initial response | The wait for the initial HTML response has been recorded separately. | Investigate the specific delivery delay and cache behaviour. | Repeat the request and check that the content remains correct. |
| A menu or filter responds slowly | The exact action can be repeated, with a browser performance recording. | Reduce the work blocking that action. | Repeat the task and check all its options. |
| A button changes position | The recording shows which element takes up additional space. | Reserve space for that content. | Check the layout during loading and after interaction. |
An example from our portfolio: a smaller file for the same image
In our portfolio review completed on 18 October 2026, we recorded a Cargo Shark desktop screenshot measuring 1432 × 895 pixels and 162,830 bytes. Its 640 × 400 variant is 46,522 bytes. We kept the original and the image description, and offered the browser several sizes for the same project preview in our website portfolio.
Those figures compare two files. The transfer for a particular visit depends on the selected version and the cache. In the individual mobile comparison at the time, rounded LCP stayed at 2.7 seconds, so we do not use this example as evidence that the site became faster. That conclusion needs a separate comparison under consistent conditions.
How should you compare the site before and after a fix?
Agree the conditions before starting the work so the later comparison is meaningful. Use the same URL and record the site version being tested. Note the tool and its version, device, network conditions, cache state and consent choice. If several parts change together, list all those changes in the report.
For an initial lab comparison, we suggest three runs for each state, keeping every result and reporting the median. This is our suggested comparison method; Google does not require three runs. When results vary widely, investigate why before drawing a conclusion.
After publishing, open the menu again and complete important tasks on a phone. Include those checks in your website maintenance agreement. Follow field data over the next reporting period, separately from lab tests and the number of enquiries received.
Frequently asked questions about mobile website speed
Does a slow website need to be rebuilt?
Not necessarily. An unsuitable image or a particular function can be repaired on the existing site. Decide on larger changes after diagnosing the problem and assessing the scope. If a redesign is needed, include checks to preserve the site's existing SEO signals.
Is WordPress the cause of a slow website?
The platform name does not establish the cause. Check the particular page, plugins and resources involved in the problem. If you are considering a different approach to development, compare WordPress and custom websites alongside your editing and maintenance needs.
What should I send for an assessment?
Send the URL, phone model and browser name. Describe exactly what is slow and include an existing PageSpeed report with its date. If the problem depends on a product or filter selection, write down the steps that lead to it.
Your free project estimate request only needs the public page and a description of the problem. We can assess the investigation required and suggest an order for the repairs. Please keep login credentials out of this form.