Your laptop may have a fast connection and saved copies of your website's files. A first-time visitor on a phone may have neither. Their device also has to process the page's code, so reducing downloads is only part of the job.
Start with your busiest service page, homepage or enquiry page. These seven checks help you gather useful evidence before paying for changes. You do not need to understand every technical warning to explain where customers get stuck.
1. What is actually slow on the customer's phone?
Identify whether the page stays blank, its main content arrives late, or buttons respond slowly. Open the same address on Wi-Fi and mobile data. Try a fresh private browsing session to reduce the effect of previously saved files, and note the device and connection.
Run that address through PageSpeed Insights and choose the mobile report. Its lab test simulates a visit; available real-user data summarises the previous 28 days. Check whether that data covers your exact page or the wider website. These are different views, as Google's PageSpeed documentation explains.
Core Web Vitals describe three parts of the experience. Google's performance thresholds give you useful targets:
- Largest Contentful Paint (LCP): when the largest visible image or text block appears. Good: 2.5 seconds or less.
- Interaction to Next Paint (INP): how quickly the page visually responds to interactions. Good: 200 milliseconds or less.
- Cumulative Layout Shift (CLS): unexpected movement of page content. Good: a score of 0.1 or less.
These targets apply at the 75th percentile: roughly three quarters of recorded visits should meet each target. They are not a promise that every visitor sees the whole page load within 2.5 seconds.
2. Are your photos larger than the page needs?
Oversized photos can make phones download far more data than the visible image needs. Check the main banner and project gallery first. A photo shrunk by the page's layout may still be the original large file.
Ask for compressed images in suitable dimensions, with smaller versions for narrower screens. WebP or AVIF can reduce file sizes; compare the result visually before replacing anything. High-resolution phone screens still need enough detail, so do not simply export every image at its displayed width.
Google's image performance guide explains responsive images: the browser chooses from different sizes. Check that service photos remain clear and any useful detail is readable.
3. Does the main image start loading too late?
A small image can still appear late if the browser does not discover it early. Ask your developer whether the main image waits for scripts or uses lazy loading, which delays an image until it is needed near the visible part of the page.
Lazy loading suits gallery images farther down a page. The main image visible when someone arrives should usually load immediately. Google's LCP guidance specifically warns against lazy-loading the LCP image. Share the affected address and a screenshot of the delay so your developer can identify the right element.
4. Are extra scripts delaying taps and menus?
Scripts can keep a phone busy even after the page looks ready. Test the menu, service buttons and form fields. If taps hesitate, ask someone to inspect the code running during those interactions, including plugins, animations and third-party tools.
Start by reviewing tools you no longer use and duplicate installations. Google's third-party script guidance explains how these additions create network and processing work. The useful question is what each script does and whether that job belongs on this page.
Test changes on a preview copy first. Keep necessary consent controls, enquiry tracking and booking functions working. Then check the complete customer journey before making the change live.
5. Are fonts hiding text or moving the page?
Font loading can delay readable text, and a late font change can move headings or buttons. Ask whether the site needs every font family and weight it downloads. A simpler selection may be enough for your design.
A developer can show a fallback font while the chosen font loads. Google's font guidance explains the trade-off: text appears sooner, but mismatched fonts can still shift the layout. Check both readability and movement.
Images and embedded content also need space reserved before they appear. Setting image dimensions helps prevent sudden jumps, as Google's layout stability guidance explains. A button moving under someone's finger is a usability problem even when downloads are quick.
6. Do videos and maps need to load immediately?
Optional videos, maps and social feeds can load supporting files before a visitor needs them. Review whether each one helps someone choose your service or contact you. Keep the business address and other essential information available as ordinary text.
Consider a video preview that loads the player only after someone presses play, or a directions link where an interactive map is unnecessary. Google's embedded content guidance describes this approach. Make the action clear and usable with a keyboard as well as a finger.
7. Is the server slow before anything appears?
A long initial wait may involve the server, connection setup or redirects before the browser receives the page. Ask your provider to check Time to First Byte, or TTFB, which measures the wait for the first response byte. It does not measure the finished page.
Google's TTFB guidance covers several possible causes. Your provider can check page generation, unnecessary redirects and caching, which reuses suitable saved responses. A content delivery network can serve content from locations closer to visitors. Changing hosting helps only if it addresses the measured delay.
What should a small business fix first?
Fix the clearest measured obstacle on a page that matters to customers. Change one thing, repeat the same checks and record what happened. Ask for a short explanation of the evidence, proposed change and way to confirm it worked.
Fictional example: A garden designer's service page shows its heading quickly, but the project photo arrives much later. The test identifies an oversized photo. Resize and compress it first, then retest the page and enquiry form before considering a hosting change.
For an existing site, Green Kauri's xEO Optimisation review includes slow pages and layouts that break on phones among the issues we assess. If you are planning a new site, our Websites service includes mobile-friendly pages from the start.
How do you check whether the changes helped?
Retest the same addresses and customer actions under similar conditions. Repeat lab runs because individual results vary. Keep a dated record of the change, the loading behaviour and whether menus and forms still work. Then watch real-user data as its collection period moves forward.
Speed alone cannot guarantee rankings or enquiries. Google's page experience guidance cautions against chasing perfect scores just for search performance. If visitors can use the page comfortably but still do not contact you, work through our website enquiry checks too.
What else should you know about mobile website speed?
Why is my mobile score lower than my desktop score?
Mobile and desktop lab tests use different simulated conditions. A page that feels quick on a powerful laptop may struggle on a slower device or connection. Compare each report's specific delays, then check real-user data where available. The two scores are not interchangeable measurements of one visit.
Do I need a PageSpeed score of 100?
No. Use the score to investigate problems, alongside real-user data and checks of customer tasks. A perfect lab score does not guarantee search rankings or sales. Prioritise readable content, responsive controls and a working enquiry process before spending time on changes that offer little practical benefit.
What if PageSpeed shows no real-user data?
Google may not have enough eligible visitor samples for your page or website. Missing data does not prove the site is fast or slow. Use the lab diagnostics, test on real phones and record the problems you can reproduce. Recheck real-user data as more samples become available.
Do I need to rebuild a slow website?
Not necessarily. Image, script or loading changes may address the main problem without a rebuild. Diagnose the delay before choosing the scope of work. A rebuild becomes worth discussing when the existing setup prevents practical fixes or also fails to meet your wider business needs.