When the same page scores in the 50s in PageSpeed Insights one day and in the 70s the next, it is easy to assume something broke. Usually nothing did. This guide is for bloggers, marketers and small-business owners running WordPress who want to read a PageSpeed Insights (PSI) report calmly, know which numbers matter, and turn the suggestions into a short, ordered fix list.
Contents
- Two kinds of data in one report
- The three Core Web Vitals and their "good" thresholds
- Why the performance score changes between runs
- Where the Search Console Core Web Vitals report fits
- What Google says about Core Web Vitals and ranking
- Turning the report into a prioritised fix list
- Key takeaways
- FAQ
- Sources
Two kinds of data in one report
According to Google’s PageSpeed Insights documentation, PSI reports on a page’s experience on mobile and desktop and draws on two different sources. Mixing them up is the most common reason people panic.
| Field data | Lab data |
|---|---|
| Source: Chrome User Experience Report (CrUX) | Source: Lighthouse |
| Real visitors, on their own devices and networks | One simulated device on fixed network conditions |
| Covers a trailing 28-day period | A single test run at the moment you click Analyze |
| Fewer metrics, less detail | Detailed, useful for debugging |
Google notes that field data comes from opted-in Chrome users, and that a URL must be public and have enough distinct samples to appear. If your page does not have enough data, PSI falls back to origin-level data, which combines all pages on the site. If the origin lacks data too, no real-user section appears. A new or low-traffic blog often sees this, and it does not mean something is wrong.
On the lab side, the mobile test simulates a mid-tier phone (a Moto G4) on a mobile network.
Enjoying this? Get our best tips by email
Practical SEO, link building and content strategies, straight to your inbox.
The three Core Web Vitals and their “good” thresholds
The current Core Web Vitals, as described on web.dev, are Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). The thresholds below match across the PSI documentation, web.dev and the Search Console help page.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 seconds or less | 2.5 to 4.0 seconds | Over 4.0 seconds |
| INP | 200 ms or less | 200 to 500 ms | Over 500 ms |
| CLS | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
LCP: how fast the main content appears
LCP reports the render time of the largest image, text block or video visible in the viewport, measured from when the user first navigated to the page. Per web.dev, delays such as redirects, connection setup and server response time (TTFB) all count toward it.
INP: how quickly the page reacts
INP observes clicks, taps and keyboard interactions across a visit and reports the longest one, ignoring outliers. The latency runs from the user’s input until the browser paints the next frame. web.dev describes INP as the successor to First Input Delay (FID), which only looked at the first interaction.
CLS: how much the layout jumps
CLS measures the largest burst of unexpected layout shifts during a page’s life. Each shift is scored by how much of the viewport moved and how far. web.dev lists the usual causes: images or videos without dimensions, fonts that render differently from their fallback, ads or widgets that resize themselves, and content inserted above existing content.
What “pass” actually means
Google assesses these at the 75th percentile, which web.dev says means the targets are met for “most of your users.” The PSI documentation spells out the Core Web Vitals assessment: when all three metrics have enough data, the page passes only if all three 75th percentiles are Good. If INP has too little data, it passes when LCP and CLS are both Good.
Why the performance score changes between runs
The big number in the circle is the Lighthouse performance score, a lab result. PSI colour-codes it: 90 to 100 is good, 50 to 89 needs improvement, and 0 to 49 is poor. Google states that variability comes from factors such as local network availability, client hardware availability and client resource contention, and that a changed score does not always mean the page changed. It also warns that a green score does not guarantee a good real-user experience.
So run the test a few times and look at the range, compare before and after on the same device setting, and do not chase 100.
One more detail: web.dev says Lighthouse cannot measure INP, because a lab run has no real user input, and uses Total Blocking Time as a proxy. If field INP is poor, interact with the page yourself in Chrome DevTools to reproduce it.
Where the Search Console Core Web Vitals report fits
PSI checks one URL at a time. The Core Web Vitals report in Google Search Console covers your whole site using the same CrUX field data. Details from the Search Console help page:
- Mobile and desktop are reported separately, so a URL can have different statuses on each.
- Pages with a similar experience are grouped, and a group’s status is its worst-performing metric. The group figure is the value that 75 percent of visits meet.
- The data is a rolling 28-day window, so improvements appear gradually, not overnight.
- After a fix, “Start Tracking” begins a 28-day validation period. It does not trigger a re-crawl.
A sensible workflow is to use Search Console to find which groups of pages are failing, then paste one representative URL from that group into PSI to find the cause. For the rest of the tool, see our guide to the Search Console Performance report.
What Google says about Core Web Vitals and ranking
Be careful with claims here. Google Search Central says it “highly recommend[s] site owners achieve good Core Web Vitals for success with Search,” and describes Core Web Vitals as part of the broader page experience that aligns with what its core ranking systems seek to reward. The page does not state a specific ranking weight, and it does not say that good scores guarantee better positions. A fair reading is that they are worth fixing for visitors, not a switch that moves rankings by itself.
Turning the report into a prioritised fix list
The report lists suggested improvements under the score. Treat them as leads to investigate rather than a to-do list to work through in the order shown. This approach works better:
- Start with field data. Note which of LCP, INP and CLS is outside the Good range at the 75th percentile, on mobile first if that is where your visitors are. A metric that is already Good can wait.
- Match suggestions to the failing metric. Ignore items that do not relate to it, at least for now.
- Rank by effort and reach. Fixes in your theme or a shared template help every page in a group; one-off page fixes help one.
- Change one thing at a time, re-test several times, and record the result.
- Wait for the 28-day window before judging field data.
If LCP is the problem
First identify the LCP element in the lab report; it is often the hero or featured image. web.dev notes that server response time, redirects and delays before the resource renders all add to LCP. On WordPress, that points to checking your hosting and caching (see our hosting plan guide), avoiding redirect chains, and making sure the main image is not held back by other processes.
If INP is the problem
web.dev advises diagnosing in the field first, then reproducing the slow interaction in the lab by using the page while it loads and walking through common flows. Typical fixes are to break up long JavaScript tasks, move work off the main thread, and reduce rendering cost from large layouts. On WordPress, look at plugins and third-party widgets that load scripts on every page; removing one you do not need is often the cheapest fix.
If CLS is the problem
Work through the causes web.dev lists. Give images and videos explicit dimensions, reserve space for ads, embeds and banners before they load, and avoid inserting content above what the reader is already looking at, such as a late-loading notice bar.
For a broader checklist covering caching, images and plugins, see our post on how to speed up your WordPress website.
Key takeaways
- Field data (CrUX, 28 days, real users) tells you how visitors experience the page. Lab data (Lighthouse) helps you debug.
- Good thresholds: LCP 2.5 seconds or less, INP 200 ms or less, CLS 0.1 or less, at the 75th percentile.
- Lab scores move between runs because of network, hardware and resource contention, so test more than once.
- Use Search Console to find failing page groups and PSI to diagnose one example URL.
- Google recommends good Core Web Vitals for Search success but gives no ranking weight, so fix them for users first.
FAQ
Why does PSI show no field data for my page?
Google says the URL must be public and have enough distinct samples in CrUX. If the page does not, PSI falls back to origin-level data, and if that is missing too, only lab data appears. Low-traffic and new pages commonly hit this.
Is a score of 90 or above required?
No. The colour bands describe the lab score, while the Core Web Vitals assessment uses field data at the 75th percentile.
How long until Search Console shows my fix?
The report uses a rolling 28-day window, so expect gradual change.
