To use PageSpeed Insights, open pagespeed.web.dev, paste your page URL, and hit Analyze. You get a 0–100 performance score, lab and field measurements of your Core Web Vitals, and a prioritized list of improvement opportunities. This pagespeed insights guide walks through every report section — what to read, what to fix, and what to ignore.
The first time I opened a PageSpeed Insights report, I stared at the big number and panicked at the red metrics. Months of wasted effort taught me the truth — the score is the least important part of the report. Here’s the walkthrough I wish someone had given me.
How do you run a PageSpeed Insights test correctly?
Go to pagespeed.web.dev, paste the page URL, and click Analyze. There are no settings to get wrong, which is part of its charm.
One habit matters: test the right page. Most people test their homepage — usually the most optimized and least representative page on the site. Test your most-visited landing page or busiest post instead, then run the test twice more. Scores of 68, 74, and 71 mean your site is “about 71.”
Toggle between Mobile and Desktop at the top. The mobile test simulates a mid-tier phone on throttled 4G and scores lower — but most visitors are on phones, so the mobile report is the one that reflects reality.
What does the 0–100 score actually mean?
The big colored circle is a weighted average of lab measurements — how the test browser experienced your page in a simulated environment, just now. Green is 90+, orange is 50–89, red is below 50.
The first lesson of this pagespeed insights guide: the score is a summary, not a diagnosis. The gap between 94 and 100 is invisible to visitors and earns nothing in rankings. The gap between 55 and 85 usually means a genuinely faster-feeling page. Once you’re green with healthy real-user data, stop — chasing a perfect 100 has eaten countless weekends for zero benefit.
What’s the difference between lab data and field data?
Below the score sit two lookalike sections that mean different things. Getting this right is the single most valuable skill in reading the report.
Lab data is what the simulated test just measured — your page loaded once, in a controlled environment, right now. Perfect for debugging: change something, re-run, and lab data tells you whether it helped.
Field data (“Discover what your real users are experiencing”) is real load times from actual Chrome users over the past 28 days, via Google’s CrUX dataset. It’s the data your visitors felt — and the data Google’s ranking systems can see.
When the two disagree, trust the field data. Your test ran once in a datacenter; field data is thousands of real visits on real devices. New pages show no field data at all (“The Chrome UX Report does not have sufficient real-world speed data for this page”) — normal, not an error.
How do you read the Core Web Vitals metrics?
Three of them — the Core Web Vitals — are the ones that matter:
LCP — Largest Contentful Paint. When the largest visible element (usually a hero image or headline block) finishes rendering. Under 2.5 seconds is good. This is the metric most reports fail on, and the one visitors feel most directly — the moment the page looks present. If only one metric is red, fix LCP first.
INP — Interaction to Next Paint. How quickly the page responds visually to a tap or click. Under 200ms is good. INP is the sneaky one: the page looks loaded but ignores clicks because JavaScript is hogging the main thread.
CLS — Cumulative Layout Shift. How much the page jumps around while loading; 0.1 or less is good. A button that jumps under your finger while you tap it — that’s CLS, usually caused by images and embeds without reserved dimensions.
Two supporting metrics: FCP (when anything first appears, under 1.8s is good) and TTFB (server responsiveness, under 800ms; TTFB measures your hosting, not your page).
Beginner trap: a metric can be red in lab data and green in field data, or vice versa. Red lab + green field means a bad test run — don’t tear the site apart over it. Green lab + red field means real visitors are suffering while the test flatters you — that one deserves action.
Core Web Vitals at a Glance
| Metric | What it measures | Good score |
|---|---|---|
| Largest Contentful Paint (LCP) | When the largest visible element, usually a hero image or headline block, finishes rendering | Under 2.5 seconds — fix this first if it is the only red metric. |
| Interaction to Next Paint (INP) | How quickly the page responds visually to a tap or click | Under 200 milliseconds. |
| Cumulative Layout Shift (CLS) | How much the page jumps around while loading | 0.1 or less. |
What should you do with the Opportunities and Diagnostics sections?
Every suggestion looks equally urgent. They’re not.
Opportunities carry estimated savings — “doing this could save X seconds.” Work them top-down, with judgment: “serve images in next-gen formats” saving 2.1s is a real win; the same item saving 0.1s is noise. For most sites the biggest wins are image compression, removing unused JavaScript, and enabling text compression.
Diagnostics are informational flags, not action items. They describe symptoms, not fixes — read them to understand why an opportunity exists, not as tasks.
Passed audits deserve one glance: they confirm what’s already fine and tell you where not to spend effort.
Pro move: click each opportunity’s dropdown arrow. PageSpeed Insights names the specific files — “reduce unused JavaScript: /wp-content/plugins/chat-widget.js could save 1.4s.” Fix the named file, not the category.
What can you safely ignore in a PageSpeed Insights report?
More than beginners think. “Avoid serving legacy JavaScript” terrifies new site owners, but the fix means build-tool surgery for a fraction of a second. Third-party code warnings often point at embeds you deliberately chose — analytics, a booking widget, chat. Removing business tools to please a test is backwards.
Ignore single-run anomalies: one test showing a 4-second TTFB while the next two show 0.4s is a network hiccup — exactly why you run three tests. Never redesign around a metric that’s red only in lab data while your field data is green.
A real walkthrough: this site’s own tool page
For this pagespeed insights guide, I walked a real page through the full report: this site’s responsive preview tool page, mobile first. Scores came in at 71, 74, 68 — orange, low-70s. The instinct is to chase the score up; the report said otherwise.
No field data yet (new page), so lab data carried the read. LCP was the red metric, above the 2.5-second threshold. The top opportunity’s dropdown named the culprit precisely: an oversized hero PNG, several times larger than its display dimensions. Resizing, compressing, and converting it to WebP pulled LCP under the threshold and the score into the high 80s. No theme change, no plugin surgery — one file, named by the report itself.
That’s the workflow: run it three times, read field data first when you have it, fix the biggest named culprit, re-run. Repeat until the vitals that matter are green — then stop and go build something.
Speed is only half the pre-launch story, though. A fast page that renders broken at phone widths still loses the visitor. Run your site through our responsive preview tool and check desktop, tablet, and mobile side by side. Fast and correct at every width is the goal.
Related guides: how to test your website’s speed, how to test your site on different screen sizes, and mobile-friendly test.
Frequently asked questions
How is PageSpeed Insights different from Chrome DevTools?
DevTools measures your page on your machine and your connection — fast hardware flatters the results. PageSpeed Insights uses standardized throttled lab conditions plus real-user field data, so its numbers are comparable across sites and closer to what visitors experience.
Why does my PageSpeed score change every time I run it?
The web is a live system, not a lab bench: cold versus warm caches, test-server load, ads serving different content each run, time of day. Run three times and compare the range, not a single number.
Do I need a perfect 100 score?
No. Get the Core Web Vitals green — LCP under 2.5s, INP under 200ms, CLS under 0.1 — with healthy field data, then stop. The gap between 92 and 100 is invisible to visitors and earns nothing in rankings.
Does my PageSpeed Insights score directly affect Google rankings?
Not the score itself — it’s a lab summary Google doesn’t rank on. But the underlying Core Web Vitals field data is a confirmed ranking signal, and faster pages bounce less and convert more regardless.