A website that feels quick on your office laptop can still keep a phone user waiting. Start with the exact page and task that feel slow, then use a mobile performance report to narrow the cause. Buying faster hosting or adding a speed plugin before identifying the delay is an expensive way to guess.
This guide is for business owners commissioning a fix to an existing site. The workflow below is a practical recommendation, not a diagnosis of your website or a promise of more enquiries.
1. Describe the wait before asking for a fix
Open a published service or product page on a phone. Try the route a customer would take: read the offer, open the menu, view a product and reach the contact option. Record the URL, device, browser, network and whether this was a fresh visit or a repeat visit.
Write down what actually happens. Does the page stay blank? Does the main image arrive late? Can you read the text but not open the menu? Does a button move just as you tap it? Those observations describe different problems. A screenshot of a low score cannot tell your maintainer which customer task is failing.
Compare another representative page using the same conditions. If every page is slow, a shared dependency deserves investigation; if one product page is different, its images, embeds or template may need attention. Treat that as a lead to investigate, not proof of the cause.
For a wider first pass, use the business website self-audit checklist. Here the aim is to turn one performance problem into a bounded repair.
2. Separate the mobile test from real visitor evidence
Run the exact URL in PageSpeed Insights and select Mobile. Save the report link and test date. Check Desktop separately; a good desktop result does not settle the mobile question.
Google's PageSpeed documentation distinguishes controlled Lighthouse tests from historical Chrome User Experience Report data collected from real visits. The controlled test helps investigate a page now; real visitor data describes experiences under a range of actual conditions. A difference between them is a reason to inspect the conditions, not automatically an error.
Check the scope of the real visitor section. Google's CrUX guide explains that it may describe the tested URL or the origin, meaning the website's overall address. A site-wide result is not a measurement of only your product page. If there is insufficient data, record that limitation; an absent field report is not evidence of good performance.
3. Read the symptom behind the number
The Web Vitals guide separates loading, responsiveness and visual stability. Its good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, evaluated at the 75th percentile of visits, separately for mobile and desktop. These are measurement guidelines, not a guarantee for every visitor.
| Signal | What it describes | A useful question for your maintainer |
|---|---|---|
| LCP: Largest Contentful Paint | When the largest visible image or text block is rendered | Which element is measured, and where does its delay occur? |
| INP: Interaction to Next Paint | How promptly the page visually responds to interactions | Which menu, filter or other interaction is slow in visitor evidence? |
| CLS: Cumulative Layout Shift | Unexpected movement of visible page content | What is moving, and can its space be reserved before it loads? |
The overall Lighthouse performance score is a different summary. Do not read it as the percentage of satisfied visitors. Also do not assume a load-only test proves every menu or form responds promptly; try those tasks yourself.
4. Ask for the bottleneck, then the smallest useful change
Ask the maintainer to name the affected page, delayed element or interaction, supporting evidence and proposed change. “Install optimisation” is not a useful scope by itself.
For a late main image, request evidence about when the image is discovered, downloaded and displayed. The official LCP optimisation guide explains that delay can involve server response, resource loading or rendering. A smaller image file alone may leave another delay untouched.
For a slow menu or filter, ask for a reproduction of that interaction. For moving buttons, ask which content changes the layout. A hosting change should follow evidence that the server response contributes to the problem; a score alone does not establish that.
Review chat widgets, video embeds and other optional features with the person responsible for the business. Removing a contact route may improve a test while making the site less useful. Decide which feature can change, then check that its intended function remains available.
5. Compare the repair under comparable conditions
Agree on the pages and customer tasks before work starts. Keep a recoverable copy of the existing site and test the proposed change away from the live site where possible. Our backup and restore checklist explains what to verify before relying on that copy.
Repeat the same mobile report and phone tasks after the repair. Keep the URLs, device mode and test conditions comparable, and inspect more than one run if results vary. Compare the affected metric and visible behaviour, rather than selecting only the best headline score.
Check the menu, product information, images, language switch and contact route. If a form is involved, follow the contact-form troubleshooting guide to distinguish a working interface from a received enquiry. Test submissions only on a form you own or have permission to test.
Historical real visitor data will not become a measurement of only the new version immediately after release. Label immediate evidence as a current test, and revisit visitor evidence when it meaningfully includes the repair.
6. Keep a short acceptance record
A useful handover contains the original symptom, affected URLs, before-and-after reports, changes made, tasks checked and any unresolved limits. Assign who will check again after adding a large video, changing a template or installing a new widget.
Accept the repair when the agreed problem improves with supporting evidence and the customer tasks still work. If only the score improved, ask what changed for a person using the page. If the visible problem remains, keep it open even when a report looks better.
Google's page experience guidance says good report results do not guarantee top search rankings. Record a performance improvement as a performance result. Search visibility and enquiries need their own evidence.
