A homepage can look quick on office Wi-Fi while a customer waits for a menu, product photograph or payment button on mobile data. Test the pages people use to do business with you, on a connection that resembles theirs.
The aim is to find a specific delay and remove it. A single performance score is useful evidence, but it is not a substitute for completing a real task on a phone.
Choose three tasks to test
Pick the most important journeys: finding a service and contacting you, opening a product and adding it to a basket, or signing in and retrieving a record. Include a page reached directly from search, rather than assuming everyone starts at the homepage.
Run each task on a phone over mobile data. Note when the main content becomes readable, when buttons respond and whether the layout moves as images arrive. Repeat the test so a temporary network delay does not determine the whole diagnosis.
Keep a short record of the device, network, page and result. It will make the comparison after a fix much more useful.
Understand the measurements
Google’s Core Web Vitals guidance measures loading with Largest Contentful Paint, responsiveness with Interaction to Next Paint and visual stability with Cumulative Layout Shift. Its good-experience thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, assessed at the 75th percentile of visits.
A laboratory test helps diagnose a page under controlled conditions. Field measurements reflect actual visits. Use both where available, and keep mobile and desktop results separate. A new or low-traffic site may not have enough field data yet.
Investigate the largest transfers first
Check whether a phone is downloading an image far larger than it displays. Serve appropriately sized images, compress them and reserve their dimensions so the page does not jump while they load.
Load important first-screen content promptly. Delay below-the-fold images where appropriate, but avoid making the main image wait behind unnecessary scripts. Inspect the actual request sequence before changing loading settings.
Also check videos, font files, chat widgets and review embeds. Each may have a business purpose; measure the cost and decide whether it needs to load immediately. Remove scripts that no longer serve a current need.
Look beyond the homepage
A slow product search may be waiting on a database query. A sluggish menu may be blocked by JavaScript. A payment page may rely on an external service. These need different fixes, so avoid assuming every delay is a hosting problem.
Use the browser’s performance and network tools to connect the visible delay to a request or task. Give the developer the page, action and observed behaviour. “The product filter stops responding after a selection” is an actionable report.
Retest the same customer task
After a change, repeat the original test under comparable conditions. Confirm that photographs still look clear, forms still submit and the checkout still records orders correctly. Record the result alongside the earlier measurement.
If you need help prioritising, contact webrack with the slow page and the task your customer is trying to complete. That gives us a concrete place to start.