Google PageSpeed Insights Guide — Scores, Metrics Explained

Most developers check PageSpeed Insights once, see a score they don't like, and immediately start cargo-culting fixes from Stack Overflow. The problem isn't effort — it's that the report itself isn't always read correctly. Field data and lab data mean different things. "Opportunities" and "Diagnostics" have different score impacts. And the mobile score you're optimizing may not even be the signal Google uses for your site's ranking.

Understanding how PSI actually works — what it measures, where the numbers come from, and which metrics move the needle — makes every optimization hour more productive. This guide covers the full picture.

Core Web Vitals Explained

Core Web Vitals are the subset of PSI metrics that Google uses directly as ranking signals. There are three of them. Understanding what each measures — and why the thresholds are set where they are — clarifies why certain fixes matter more than others.

LCP — Largest Contentful Paint

LCP measures when the largest visible element on the page finishes loading. The LCP element is typically a hero image, a large heading rendered in a web font, or a video thumbnail. PSI identifies the specific element it used as the LCP candidate.

Thresholds: ≤2.5 s — Good. 2.5–4 s — Needs Improvement. >4 s — Poor.

LCP accounts for 25% of the lab score but is often the single metric most worth fixing because it is highly visible to users and the most common cause of poor field data. The most common LCP issues:

• Slow server TTFB — the browser cannot start rendering at all until the first byte arrives
• Render-blocking resources delaying the LCP element — JS or CSS that blocks parsing before the LCP image can be requested
• Unoptimized LCP image — large file size, wrong format, no CDN
• Missing <link rel="preload"> on the LCP image — the browser discovers the image late in the waterfall

CLS — Cumulative Layout Shift

CLS measures unexpected visual instability as the page loads — elements jumping around as images load, ads inject, or fonts swap. The score is a unitless number calculated from the impact fraction (how much of the viewport shifted) multiplied by the distance fraction (how far elements moved).

Thresholds: ≤0.1 — Good. 0.1–0.25 — Needs Improvement. >0.25 — Poor.

CLS accounts for 25% of the lab score. The most common causes:

• Images without explicit width and height attributes — the browser reserves no space until the image loads
• Ads or embeds loading without reserved space — the container collapses to zero height until the iframe fills it
• Web fonts causing FOUT (flash of unstyled text) — text reflows when the custom font swaps in; fix with font-display: optional or size-adjust
• Dynamically injected banners or consent bars that push content down

FID / INP — Interaction to Next Paint

FID (First Input Delay) measured responsiveness to the first user interaction. It was replaced by INP (Interaction to Next Paint) as a Core Web Vital in March 2024. INP measures the worst-case responsiveness across all interactions during a page session, not just the first one.

Thresholds: ≤200 ms — Good. 200–500 ms — Needs Improvement. >500 ms — Poor.

PSI lab data does not directly measure INP (it requires real user interaction) — instead, TBT is used as the lab proxy. High TBT strongly correlates with poor INP. The primary cause of both: long JavaScript tasks that block the main thread.

FCP — First Contentful Paint

FCP measures when the first text or image element appears. It is not a Core Web Vital but influences LCP — a slow FCP means the LCP element starts loading later. Threshold: ≤1.8 s — Good.

TBT — Total Blocking Time

TBT is the sum of all time spent on long tasks (tasks taking >50 ms) on the main thread between FCP and Time to Interactive. It is the strongest lab proxy for INP and accounts for 30% of the PSI lab score — more than any other single metric. High TBT (>200 ms) almost always indicates large JavaScript bundles or third-party scripts running on the main thread.

Reading the PSI Report

Field Data Section

Shows 28-day aggregated CrUX values for LCP, FID/INP, FCP, and CLS for real Chrome users who visited this URL or origin. This is the data Google uses for ranking signals — not the lab score below it.

Two important caveats:

• If the page has insufficient traffic (common for low-volume pages), this section shows "Not enough data." In that case, PSI shows origin-level field data instead of URL-level data, if available.
• The Core Web Vitals assessment (Pass/Fail badge at the top of PSI) uses field data, not lab scores. A page can score 95 in the lab and still fail the CWV assessment if real users experience poor LCP on mobile.

Lab Data Section

Lighthouse metrics run at report time using a simulated environment. These fluctuate 5–15% between runs due to server variability and network simulation. To get a reliable baseline: run 3 consecutive tests and average the scores. Do not chase single-run score differences of less than 5 points — they are within normal variance.

Opportunities Section

Actionable fixes with estimated time savings shown in milliseconds or seconds. These directly affect the lab score. Examples: "Eliminate render-blocking resources" (defer or async JS/CSS), "Properly size images" (compress and resize to display dimensions), "Use efficient cache policy" (set Cache-Control headers with long max-age).

The estimated savings are Lighthouse's best guess based on the current state of the page — they are not guarantees. Treat them as a relative priority ranking, not precise predictions.

Diagnostics Section

Best-practice checks without direct score impact. Examples: "Avoid an excessive DOM size" (>1,400 nodes), "Minimize critical request depth," "Keep request counts low." These matter for overall page health but fixing them will not move your PSI score. Address Opportunities first, then revisit Diagnostics.

Highest-Impact Fixes

In order of typical score improvement on a mid-range content or marketing site:

1. Optimize the LCP image. Preload it with <link rel="preload" as="image" href="..."> in the <head>. Serve in WebP or AVIF format. Compress to the lowest acceptable quality (typically 75–80 for WebP). Add explicit width and height attributes. Host on a CDN close to your users. This is the single most impactful fix for most sites scoring below 80.

2. Defer non-critical JavaScript. Add defer to all non-critical <script> tags. Use dynamic import() for third-party scripts (analytics, chat widgets, A/B testing tools) not needed on initial load. Each render-blocking script delays FCP and LCP by its full download + parse + execute time.

3. Eliminate render-blocking CSS. Inline critical above-the-fold CSS directly in the <head>. Load the full stylesheet asynchronously using the media="print" onload="this.media='all'" pattern or a preload link. This is more complex than JS deferral but delivers significant FCP improvement on CSS-heavy sites.

4. Compress and right-size images. Serve WebP (saves approximately 30% vs JPEG at equivalent quality). Never serve a 2000 px image in a 400 px container — resize to actual display dimensions plus 2× for retina. Use <picture> with srcset to serve responsive sizes.

5. Improve server TTFB. Enable server-side caching (Redis, full-page cache, CDN edge caching). Use a CDN for static assets and, if possible, HTML. Upgrade hosting if TTFB is consistently above 800 ms from multiple locations. TTFB is the floor for LCP — you cannot have a fast LCP with a slow TTFB.

6. Add explicit image dimensions. Every <img> needs width and height HTML attributes so the browser can reserve the correct space before the image loads. This is the fastest fix for CLS and takes minutes to implement across most sites.

Mobile vs. Desktop Score Gap

PSI tests mobile performance by simulating a mid-range Android device (equivalent to a Moto G Power) on a 4G connection with CPU throttling applied. Desktop tests use a fast connection with no CPU throttling. The result: most sites score 15–30 points higher on Desktop than Mobile.

Google's Core Web Vitals ranking signal uses Mobile CrUX field data — the real experience of users on mobile devices visiting your site. The PSI mobile lab score is a diagnostic proxy for that signal, not the signal itself. Do not ignore mobile optimization because your desktop score is green.

The most common driver of the mobile/desktop gap: JavaScript bundle size. A 300 KB JavaScript bundle that parses in 80 ms on a fast laptop takes 400–600 ms on a mid-range mobile CPU. Code splitting, tree-shaking, and removing unused dependencies improve mobile TBT far more than desktop TBT.

Common PSI Misreads

Treating score as a ranking factor directly. Google uses Core Web Vitals field data (CrUX) as a ranking signal, not the PSI lab score. A site with good field data can rank well despite a mediocre lab score. Focus on moving CrUX metrics into the Good threshold, not chasing a specific PSI number.

Fixing Diagnostics before Opportunities. "Avoid an excessive DOM size" and "Minimize critical request depth" are Diagnostics — they don't carry estimated savings and won't move your score. If you have Opportunities with measurable time savings listed, fix those first.

Running a single test and trusting it. PSI lab scores vary 5–15% between runs. Server load, network conditions during the test, and Lighthouse version differences all contribute. Always average 3 runs, and test from a consistent state (no other tabs open, consistent network conditions).

Ignoring the LCP element identified by PSI. PSI tells you which specific element it used as the LCP candidate. If it's a text node instead of your hero image, that means the image is loading too late for Lighthouse to consider it. Fix the image discovery order before optimizing the image itself.

Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.