A low score in PageSpeed Insights doesn’t automatically mean your site is “slow” for every user. Before changing anything, you need to tell apart real-user data, lab tests and what people actually perceive while browsing.
The useful question isn’t “what does the site score on PageSpeed?”, but what problem are users experiencing, and what is causing it.
PageSpeed Insights shows two kinds of data
When available, PageSpeed Insights shows real data collected by the Chrome User Experience Report (CrUX). This is field data: it tells you how real users experienced that page or site.
Next to it you’ll find lab data, produced by a Lighthouse simulation. It is very useful for diagnosing technical problems, but it represents a single run under controlled conditions.
That’s why the Lighthouse test can be red while real-user data is good, or the other way round.
The metrics to watch today
The current Core Web Vitals are:
- LCP: how quickly the main content appears;
- INP: how quickly the page responds to interactions;
- CLS: how stable the layout stays while loading.
FID is no longer a Core Web Vital: in 2024 it was replaced by INP. I’ve collected metrics, thresholds and fixes in the updated guide to Core Web Vitals.
When is a site really slow?
Rather than fixating on a single number, look for concrete signs:
- the main content appears late;
- buttons and menus react with a delay;
- the layout moves while the user is reading or clicking;
- the server takes too long to start responding;
- browsing gets noticeably worse on mobile;
- some pages are much slower than others.
Don’t optimize everything the same way
Different problems need different fixes.
- High LCP: check the hero image, TTFB, render-blocking CSS, fonts and critical resources.
- High INP: look at JavaScript, heavy widgets, third-party scripts and long tasks.
- High CLS: check image dimensions, fonts, banners and content injected after loading.
- High TTFB: analyze hosting, database, PHP, server cache and slow queries.
Useful tools
- PageSpeed Insights for field data and Lighthouse;
- WebPageTest for waterfalls and comparisons;
- GTmetrix for a second technical analysis;
- Chrome DevTools for Performance, Network and layout shifts;
- Query Monitor on WordPress for slow queries, hooks and requests on the application side.
Beware of “errors” that aren’t necessarily the priority
An automated audit can flag dozens of opportunities. They don’t all have the same real impact.
Before installing a plugin, removing a feature or rewriting the frontend, ask how much that item affects the problematic metric and the real experience. Optimizing means reducing the main bottleneck, not chasing every warning.
Where to start on WordPress
On WordPress I would check, in this order:
- hosting and server response time;
- the main images;
- the plugins and add-ons actually in use;
- CSS and JavaScript loaded on the page;
- fonts and third-party scripts;
- cache and CDN;
- database and slow queries.
Conclusion
Performance isn’t a score to chase, it’s a problem to diagnose. Start from real-user data when it exists, use lab tests to find the cause, and work on the metric that is actually hurting the experience.
If you’d like a technical analysis of your site, see my WordPress performance and optimization service or get in touch.