The short answer
Run your page through PageSpeed Insights and look at the real-user section first. A page is considered good when its largest content shows within 2.5 seconds, it responds to taps within 200 milliseconds and its layout stays steady (a shift score of 0.1 or less), measured for 75 percent of visits. Heavy images, scripts and weak hosting are the usual causes.
What slow actually means
A page can feel slow in three different ways, and each has a different cause. It can take long to show anything useful. It can show quickly but ignore your taps for a moment. Or it can jump around while loading, so you tap the wrong button. Google measures these as Core Web Vitals.
The three measures are LCP, the time until the biggest visible element appears, INP, how quickly the page reacts when someone clicks, taps or types, and CLS, how much the layout moves around. Google's thresholds for good are 2.5 seconds or less for LCP, 200 milliseconds or less for INP and 0.1 or less for CLS. Each is judged at the 75th percentile of visits, meaning three out of four visitors need to get that experience, separately for mobile and desktop.
How to measure it
- 1Open PageSpeed Insights (pagespeed.web.dev) and paste the full address of a page that matters, such as the homepage or your main service page. Run it for a service page, not only the homepage.
- 2Look at the mobile result first. Most visitors use phones, and the mobile test is the stricter one.
- 3Read the top section, 'Discover what your real users are experiencing'. This is field data from real Chrome visitors over the previous 28 days.
- 4Then read the performance score and the list of opportunities lower down. This is lab data: a simulated load on a mid-tier phone over a mobile network.
- 5Save a screenshot or copy the page address with the date. Run it three times and note the range, because lab scores move a few points from run to run.
Field data versus lab data
This is the part most people miss. The two sections can disagree, and neither is wrong. Field data is what real visitors experienced. It is the closest to the truth, but it needs enough traffic to exist, and a small or new site may show 'no data'. Lab data is a controlled test, very useful for finding what to fix, but it may miss real-world slowness.
The performance score is a lab number: 90 to 100 is good, 50 to 89 needs improvement and 0 to 49 is poor. A good lab score does not guarantee real visitors are happy, and a mediocre one does not mean your visitors suffer. Judge by the real-user Core Web Vitals when they are available, and use the lab opportunities as the to-do list.
| Result you see | What it usually means | Where to look |
|---|---|---|
| LCP over 2.5 seconds | The main image or heading arrives late | Image size, slow server, render-blocking scripts |
| INP over 200 ms | The page is busy and slow to react | Too much JavaScript, chat widgets, tracking tags |
| CLS over 0.1 | Things shift while loading | Images without set sizes, late banners, cookie bars |
| Good field data, poor lab score | Real visitors are fine | Treat as a to-do list, not an emergency |
| No field data | Not enough Chrome traffic yet | Rely on lab data and watch again later |
What usually makes a site slow
Google's guidance breaks LCP into four parts: the time to get the first byte from the server, the delay before the main image starts loading, how long it takes to download, and the delay before it is drawn. Most of the real causes fall into those four.
- Heavy images. A photo straight from a phone can be several megabytes. It should be resized to the size it is shown and saved in a modern format such as WebP or AVIF.
- The main image set to load lazily. Lazy loading is good for pictures further down the page and bad for the biggest one at the top. Google's advice is never to lazy-load the LCP image.
- Too many scripts. Chat widgets, heatmaps, social feeds and several tracking tags each add work for the visitor's device. Remove the ones nobody uses.
- Slow hosting. If the first byte takes a long time to arrive, no amount of image work will rescue it. This is a hosting or caching question.
- Large page builder output and unused plugins. Every active plugin can add files to every page.
- Fonts and sliders. Several font weights and an auto-playing hero slider load a lot before anyone sees the page.
Who can fix what
| Cause | You can | Our team does |
|---|---|---|
| Oversized images you upload | Resize before uploading, aim for the displayed size | Compress and convert existing images, set correct sizes |
| Too many tracking tags | Tell us which tools you no longer use | Remove or delay the unused tags |
| Caching and plugin set-up | Nothing to change yourself | Configure caching, remove conflicting plugins |
| Slow server response | Ask us to review hosting | Diagnose, and recommend a change with you and your project manager |
| Layout shifting | Report where it happens | Fix image sizes, reserve space for banners |
Avoid installing a second speed plugin on top of the first. Two caching or optimization plugins often fight each other and can break layouts, which is slower to repair than the original problem.
Be realistic about scores
Chasing a perfect 100 is rarely worth it. A page that scores 85 in the lab and passes Core Web Vitals for real visitors is in good shape, and the last ten points can cost more effort than they return. Speed also trades against features: a video background, a booking widget and a live chat all cost something. The useful question is not 'how do we hit 100' but 'what is the slowest thing visitors actually feel, and is it worth keeping'.
Speed also matters for the business beyond rankings. Slow pages tend to lose people before they see your offer. Core Web Vitals are one of many signals, so do not expect speed alone to move you up search results. For the reporting view of these numbers, see core web vitals.
A worked example
Example: The homepage that took ages on phones
A dental clinic's PageSpeed run shows a mobile performance score of 41 and a field LCP of 4.8 seconds. The opportunities list points to a 3.2 MB hero photo, a chat widget loading on every page and the hero image being lazy-loaded. After the photo is resized and converted, lazy loading is removed from the hero, and the chat widget is delayed until the visitor scrolls, a re-run shows an LCP in the lab of about 2.1 seconds. The real-user number takes about four weeks to catch up, because field data covers the previous 28 days. The owner's first reaction is that nothing improved, which is exactly the trap: the lab moves at once, and the field moves slowly.
When to ask us
Ask when your real-user Core Web Vitals fail on the pages that bring you business, when the site feels slower than it used to, or when the slowness is on certain pages only.
Send the page address, a screenshot of the PageSpeed Insights result for mobile showing both the real-user section and the performance score, the date and time you ran it, and what feels slow: loading, tapping or jumping. Say whether it started after a change. Send everything in one request through the support form. If the site is not loading at all, use my website is down instead.
