Google PageSpeed Insights (PSI) is Google's free tool for checking how fast a URL feels on mobile and desktop. I use it on almost every technical review—not because a single score predicts rankings, but because it shows real-user data when Chrome has enough of it, and a prioritised list of what is slow on the URL you test.
Most confusion I see is not “how do I click Analyse?” It is someone treating the lab Performance score as the whole story while mobile field LCP is still red on the template that drives enquiries.
Why the score misleads people
A client sends a screenshot: lab score 54, panic in the subject line. I open PSI on the same URL. Field Core Web Vitals are green on mobile. Traffic is modest; CrUX has data from real visits. The Opportunities list flags optimisations that would shave lab milliseconds but will not change what customers feel. We note the backlog and move on to content and conversion—no emergency sprint.
The opposite is more common: lab score 78, everyone relaxes, but field LCP is poor on a service page with heavy paid traffic. Mobile bounce is high. Forms drop. PSI was showing a simulation that did not match what visitors hit—uncached HTML, a hero image uploaded at full resolution, a chat widget loading before the main content. The score looked fine. The experience was not.
That is why I read field before lab on money templates. Field data (CrUX) is how Chrome users experienced the URL over the last 28 days—device mix, networks, caching, geography. Lab data is Lighthouse on Google's infrastructure: consistent, useful for debugging, not identical to every session. When PSI says “Not enough data,” the URL may be too quiet for CrUX. That is normal on new or low-traffic paths; I treat lab PSI as diagnostic only and I do not declare the site “fast.”
You run PSI at pagespeed.web.dev: enter the URL, check mobile first, then desktop. The report shows Core Web Vitals when available, Opportunities ranked by estimated impact, and diagnostics underneath. PSI does not replace a full SEO audit—it answers one question: does this page load and respond acceptably for the traffic it gets?
Core Web Vitals (what I look at before the 0–100)
Google groups three metrics under Core Web Vitals. PSI surfaces them at the top when field data exists.
| Metric | What it measures | Good (field) |
|---|---|---|
| LCP | Main content load | ≤ 2.5s |
| INP | Responsiveness | ≤ 200ms |
| CLS | Visual stability | ≤ 0.1 |
Thresholds use the 75th percentile—most visits should be good, not every one. I do not chase a perfect lab score on a blog archive while homepage mobile LCP is still poor.
The 0–100 Performance score is lab-based. Guides that say “90+ is good” miss the split: you can pass CWV in the field with a mediocre lab number, or fail CWV while lab looks acceptable. I use the score to rank lab opportunities, not as a board KPI. “We went from 54 to 78” means little without “mobile LCP moved from poor to good” or “form starts stopped dropping.”
What I actually do with a bad report
I test the template that matters—homepage, top service page, main landing URL—not a random old post unless that post earns serious traffic. Mobile first; that is where most impressions land.
If field CWV is red, that URL gets priority. I read Opportunities but I apply judgment—PSI may push aggressive image compression that harms quality, or flag a booking script we cannot remove without breaking conversions. I fix what moves LCP, INP, or CLS without breaking the page job.
After deploy I run PSI again and spot-check Lighthouse in Chrome DevTools when I need a filmstrip or network waterfall. Caching and CDN changes sometimes need a purge before anything moves. I log whether the fix is theme-wide—one hero in the header slowing every page—or one bad upload.
When field and business signals disagree with the score, I check bounce rate on the same template. Sometimes the page is fast but the promise is wrong, not the milliseconds.
A service page that looked “okay” in lab
Anonymised pattern—numbers rounded.
Mobile field LCP was poor (~4.2s) on a template with solid paid traffic. Lab Performance sat around 48. PSI pointed at an oversized hero, render-blocking CSS, and slow TTFB on uncached HTML. We shipped WebP with explicit dimensions, critical CSS for above-the-fold, and cache rules for HTML. We kept the chat widget but deferred non-critical scripts.
Lab Performance rose to 72. More importantly, over **28 days** as CrUX refreshed, field LCP moved from poor to good. Mobile bounce on that template fell; enquiries ticked up—not from PSI alone, but speed stopped being the obvious blocker.
PSI told us where to look. The fix was template assets and caching, not meta tags.
PSI vs Lighthouse (when I use which)
Lighthouse powers PSI's lab audit. PSI gives me a shareable URL report plus field CrUX when it exists. Lighthouse in DevTools is for tracing a specific script or waterfall while I am in the build. I do not need both on every check—I need the one that answers the question in front of me.
Habits that waste time
Chasing 100 in lab while field CWV fails. Testing the homepage when the paid landing page is slow. Ignoring “no field data” as all-clear. Applying every Opportunity blindly on WordPress stacks with consent banners and plugins PSI does not understand. Optimising images once, then letting editors upload multi-megabyte PNGs again. Running PSI once the morning after a redesign and never looking when CrUX refreshes.
Slow money pages also waste page speed work done elsewhere if the template never gets fixed—I connect PSI to the URLs that actually receive traffic.
When I have limited dev time, I fix mobile LCP on the highest-traffic money template first, then CLS on form-heavy pages, then INP when users say the site freezes. Lab-only nitpicks on URLs with passing field data and healthy conversions wait.
If you're troubleshooting a slow site
Start with which template gets traffic and whether field data exists—not the headline score. Often it is caching, images, or a plugin on a theme used across dozens of URLs. Sometimes PSI is fine and the problem is elsewhere.
When speed sits inside a wider mess—crawl, indexation, measurement—a technical SEO audit covers more than vitals. Ongoing template and content work lives under SEO; rebuild-level bottlenecks need web design scoped with performance, not a last-minute PSI pass.
FAQ
What is a good PageSpeed Insights score? Passing field Core Web Vitals on URLs that matter beats a perfect lab number on a quiet page.
Is PSI accurate? Field data reflects CrUX sampling. Lab data is consistent for debugging—not every user's session.
Does PSI affect SEO? Core Web Vitals are one signal among many. PSI measures; it does not submit URLs to Google.
How often should I test? After meaningful deploys—not daily. CrUX updates on a rolling 28-day window.
Closing point
Google PageSpeed Insights helps when you treat field and lab as different stories, fix money templates first, and judge success with business metrics—not a green circle on a low-traffic URL. The score is a pointer, not the diagnosis.
