You open your website on a fast laptop, on good wifi, and it appears instantly. You tell yourself it is fast. Then a customer opens it on a three-year-old phone, on a train, with twenty tabs already running, and waits five seconds for the first thing to appear. They do not tell you. They leave.
This is the most common speed problem we see, and it is not a technical failure. It is a measurement failure.
Your laptop is the best case
Everything about your own setup flatters the site. Your processor is fast, so the JavaScript that runs the page barely registers. Your connection is stable. Your browser already holds a warm copy of most files from the last time you visited.
A first-time visitor has none of that. On a mid-range phone, the same page can take several times longer to become usable, and most of that extra time goes on running code rather than downloading it.
A fast average hides a slow tail. At the 75th percentile, one in four visits is slower than the number you are looking at.
Lab data and field data are different things
Tools like Lighthouse run your page once, in a controlled and simulated environment. That is lab data. It is great for finding problems, because the test is repeatable.
Field data is what real visitors experienced on real devices. Google collects it through the Chrome User Experience Report, averages it over a rolling 28 days and looks at the 75th percentile. That is the number that counts for the Core Web Vitals assessment.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP | How quickly the main content appears | 2.5 s or less | Over 4 s |
| INP | How quickly the page responds to taps | 200 ms or less | Over 500 ms |
| CLS | How much the layout jumps around | 0.1 or less | Over 0.25 |
What slow looks like on a real phone
Most slow pages share the same handful of causes:
- A hero image that is far larger than the screen it is shown on.
- Third-party scripts such as chat widgets, ad tags and tracking pixels, which compete with your own code.
- Web fonts that hide the text until they finish loading.
- Images without set dimensions, which shove the page around as they arrive.
- Large bundles of JavaScript that the phone has to download, parse and run before anything responds.
How to check your real numbers
- Paste your address into PageSpeed Insights and read the field-data section at the top before looking at the lab score.
- Open the Core Web Vitals report in Google Search Console to see which groups of pages are slow.
- In Chrome DevTools, turn on CPU throttling and a slow network preset, then reload. It is crude, but it is much closer to your customers than your laptop is.
- Borrow a mid-range phone and load the site over mobile data. Nothing beats this one.
Smaller sites often have no field data at all, because there is not enough traffic to report on. In that case, lean on the throttled and real-phone tests.
What to fix first
Work in this order, because each step tends to pay for itself:
- Images. Resize them to the size they are displayed at, use a modern format and give them explicit dimensions. Do not lazy-load the main image at the top of the page.
- Third-party scripts. Every one you remove gives the phone time back. Keep only the ones you can point to a result for.
- Layout shift. Reserve space for images, embeds and banners before they load.
- Fonts. Use fewer weights, and let text show while the font loads.
Here is what a well-behaved main image looks like:
<img src="/hero.webp" width="1200" height="675" alt="" fetchpriority="high" />The dimensions stop the page jumping, and the priority hint tells the browser this is the picture that matters.
Where to start
Pick the slowest phone you can find and use your own site on it for five minutes. The things that annoy you there are the same things costing you customers, and they are usually fixable in days rather than months.