Why your website is slow for real visitors, and which fix pays off first

Why does your site feel fast to you and slow to them?

You probably test on a good computer, on office Wi-Fi, with everything already in your browser's cache. On our demo marketplace, 79% of website visitors are on phones.

That's why a lab score and real data disagree. Google's PageSpeed Insights page describes field data as capturing the real-world experience over the previous 28 days, and lab data as a controlled test useful for debugging, which may not capture real-world bottlenecks. It states that the values may differ. Use field data to decide what to fix, and lab data to work out how.

Which numbers should you look at?

Google's Web Vitals are three measures (LCP, INP and CLS), judged at the 75th percentile, which means three visits in four are at least that good. Split them between phones and computers.

Two more help you find the cause. TTFB, time to first byte, is how long your server takes to start answering. FCP, first contentful paint, is when anything at all appears.

How do you find out which pages are slow?

Don't start with your home page, and don't average across the site. Split by page type: all product pages together, all listings together, the checkout. Pages built the same way are slow for the same reason, so one fix covers all of them.

To do this for free, enter your main page types in PageSpeed Insights and read the field data block if it shows one. Then open Chrome's Performance panel, which shows your own local LCP and CLS at once and INP once you interact. It has CPU and network throttling settings. Turn them on, to feel something closer to a phone.

What do the patterns tell you?

Read across a table like this and you can usually tell what kind of fix you need before opening any code. Here's our rule, and what it says about the demo.

Which fix pays off first?

We can't give you a figure for what each one will earn. Nobody honest can before you try it. But we can give you an order. This one is our judgement, not a study. Use it as a default:

1. Fix poor before amber. Poor means many visitors are having a bad time now. On the demo, that's item pages' LCP at 4.21 s.
2. Then weigh by visits and closeness to a sale. Item pages have 1,086 samples, fewer than the home page's 3,605. But they're where the "Voir le numéro" and contact buttons are. They come first.
3. Then pick shared causes, since one fix moves every page. INP is amber on every page type.
4. Then the quick wins, such as listings' CLS at 0.17, where the fix can be as small as adding sizes to images.

What fixes each one?

Slow LCP. web.dev's guide to optimizing LCP splits it into four parts: server time, delay before the main resource starts loading, its download time, and delay before it's drawn. It suggests server time and download each take about 40%, and the two delays under 10% each. Its advice includes making the image discoverable in the first HTML, never lazy-loading it, and using fetchpriority="high" where it fits. Images in modern formats at the right size come next.

Slow INP. web.dev's INP guide divides a slow response into input delay, processing and presentation delay. Its fixes: fewer long tasks during startup, shorter event handlers, and a smaller page. Before you touch anything else, check what every page loads in common. Each extra tag you've added, including analytics, is a candidate.

High CLS. web.dev's CLS guide names four usual causes: images without dimensions, ads and embeds without reserved space, content inserted without a user action, and web fonts. For the first, add width and height to images, or reserve space with CSS.

Then check it worked, with real visits, not a lab test. Field numbers take days to weeks to move, and that delay is normal. The PageSpeed field block covers 28 days, so it changes slowly.

How MetricMind shortens this

The script collects these from real visits, as part of its roughly 12 KB, and adds them to the same record as traffic and errors.

• Page types by themselves. Item pages are grouped automatically, and you can name page templates. Click a row to filter the whole page by it.
• A real experience score, 0 to 100, based on a Lighthouse-style curve: 90 at Google's good limit and 50 at its poor limit. It's our summary and not a Google metric, so Google's verdict appears next to it.
• Any percentile, from p50 to p99, and splits by country, device and browser.
• Slower page load gets flagged. A 20% rise of at least 300 ms week over week, with 50 samples each week, shows as a detected change.
• Ask the analyst which page type to fix first, with the query shown. Questions come with every plan, with a monthly allowance.

It measures what's slow, not why at the code level. For that, use the lab tools above. It can't tell you what speed is worth in contacts on your site either, though you can compare contacts before and after and judge your fix. See Web Vitals for more.