Performance ⏱ 10 min read

PageSpeed Insights: Every Score Explained

PageSpeed Insights gives you four scores — Performance, Accessibility, Best Practices, SEO — and a wall of metrics with names like LCP, CLS, FCP, TBT, and INP. Most people stare at the red numbers without knowing which ones actually matter for rankings, which ones are cosmetic, and critically, what to do about each one. This guide breaks down every metric, explains the ranking impact, and gives you actionable fixes.

// Table of Contents
  1. The Four Top-Level Scores
  2. Core Web Vitals — The Ranking Signals
  3. LCP — Largest Contentful Paint
  4. CLS — Cumulative Layout Shift
  5. INP — Interaction to Next Paint
  6. FCP — First Contentful Paint
  7. TBT — Total Blocking Time
  8. TTFB — Time to First Byte
  9. Opportunities vs Diagnostics
  10. Mobile vs Desktop Scores
  11. The Priority Action Plan
  12. FAQ

The Four Top-Level Scores

PageSpeed Insights shows four category scores at the top, each from 0–100:

  • Performance — how fast your page loads and responds. This is the only score that directly affects Google rankings (via Core Web Vitals). Color: red (0–49), orange (50–89), green (90–100).
  • Accessibility — how usable your page is for people with disabilities. Does not directly affect rankings but does affect user reach and can be legally relevant in some countries.
  • Best Practices — security, modern web standards, HTTPS, correct image formats. Indirectly affects trust and rankings.
  • SEO — basic on-page SEO signals: meta description, canonical, robots.txt, structured data, mobile-friendliness. Directly affects crawlability and indexing.
// What Actually Affects Rankings

Only Core Web Vitals (LCP, CLS, INP) feed directly into Google's page experience ranking signal. A perfect 100 in Accessibility and Best Practices will not boost your ranking if your LCP is 8 seconds. Focus on Performance first.

Core Web Vitals — The Ranking Signals

Core Web Vitals are Google's three user-experience metrics that directly influence search ranking. They measure loading performance (LCP), visual stability (CLS), and interactivity (INP). Google uses real-user data from Chrome users (the CrUX dataset) for ranking — the lab data in PageSpeed Insights is a useful proxy but not exactly what Google measures.

MetricGoodNeeds WorkPoorRanking Impact
LCP≤ 2.5s≤ 4.0s> 4.0sHigh
CLS≤ 0.1≤ 0.25> 0.25High
INP≤ 200ms≤ 500ms> 500msHigh

LCP — Largest Contentful Paint

LCP measures how long until the largest visible element on the page is fully rendered. This is typically your hero image, hero video poster, or a large heading. It is the single most important performance metric because it is what users experience as "the page has loaded."

What Counts as the LCP Element?

  • <img> elements
  • <video> poster images
  • Elements with a CSS background-image
  • Block-level text elements (<h1>, <p>, etc.) if they are the largest visible thing

How to Improve LCP

  • Preload the LCP image — add <link rel="preload" as="image" href="hero.jpg" fetchpriority="high"> in your <head>
  • Add fetchpriority="high" to the LCP image element itself
  • Serve from a CDN — reduce round-trip time to the image origin
  • Compress images — convert to WebP or AVIF, reduce file size without visible quality loss
  • Eliminate render-blocking resources — JavaScript and CSS in <head> that block the browser from painting
  • Reduce server response time (TTFB) — a slow server delays everything, including LCP

CLS — Cumulative Layout Shift

CLS measures how much the page layout shifts unexpectedly while loading. If an image loads and pushes text down, that is a layout shift. If an ad loads and displaces your main content, that is a layout shift. CLS is scored from 0 to infinity (0.1 or below is good).

Common CLS Causes

  • Images without dimensions — if you do not specify width and height on <img> tags, the browser does not know how much space to reserve before the image loads, causing a jump
  • Ads injected above content — ads that load after the page content and push everything down
  • Web fonts causing text swap — FOUT (Flash of Unstyled Text) where text reflows when the web font loads
  • Dynamically injected content — anything that inserts content above existing content

How to Fix CLS

  • Always set explicit width and height attributes on all <img> elements
  • Use CSS aspect-ratio on image containers to reserve space before load
  • Use font-display: optional or font-display: swap with a matching system font as fallback
  • Reserve space for ad slots with fixed-height containers before ads load

INP — Interaction to Next Paint

INP (Interaction to Next Paint) replaced FID (First Input Delay) as a Core Web Vital in March 2024. It measures how quickly the page responds to any user interaction — a click, tap, or keyboard input. Specifically, it measures the time from the interaction until the next frame is painted to the screen.

How to Improve INP

  • Break up long JavaScript tasks — any JS that runs for more than 50ms blocks the main thread and makes interactions feel sluggish. Use setTimeout(fn, 0) or scheduler.yield() to yield to the browser between tasks
  • Defer non-critical JavaScript — use defer or async on script tags, or load scripts after the page is interactive
  • Avoid synchronous layout — reading layout properties (offsetTop, getBoundingClientRect) immediately after DOM changes causes forced reflow, which is expensive
  • Use requestAnimationFrame for visual updates and event throttling

FCP — First Contentful Paint

FCP measures how long until the first pixel of content is painted — any text, image, or canvas element. This is what users experience as "something is happening." It is a diagnostic metric (not a Core Web Vital), but a high FCP usually means LCP will also be high.

Good FCP: under 1.8 seconds. Poor: over 3 seconds. Main causes of slow FCP: render-blocking CSS or JavaScript, slow server TTFB, no server-side rendering on JS-heavy pages.

TBT — Total Blocking Time

TBT measures how long the main thread is blocked by long JavaScript tasks between FCP and Time to Interactive. Any JS task over 50ms is considered "long" — TBT sums up the excess time above 50ms for all such tasks. High TBT means your page looks loaded but does not respond to clicks.

Good TBT: under 200ms. Poor: over 600ms. Main culprit: large JavaScript bundles executing synchronously on page load.

// TBT vs INP

TBT is a lab metric measured by Lighthouse. INP is a field metric measured from real Chrome users. Both measure JavaScript impact on interactivity, but from different angles. Improving TBT almost always improves INP.

TTFB — Time to First Byte

TTFB measures how long until the browser receives the first byte of the HTML response from the server. It includes DNS lookup, TCP connection, TLS handshake, and server processing time. TTFB is not a Core Web Vital but it is the foundation everything else builds on — a slow TTFB adds directly to LCP and FCP.

Good TTFB: under 800ms. The biggest improvements come from: using a CDN (moves the server closer to the user), caching HTML responses at the edge, and reducing server-side processing time.

Opportunities vs Diagnostics

PageSpeed Insights divides its findings into two types:

  • Opportunities (shown with an estimated time saving) — actionable improvements with a measurable impact. These are ranked by potential LCP/FCP improvement. Always address the top opportunities first.
  • Diagnostics — best practice issues that may not directly improve your scores but indicate problems (e.g. "avoid an excessive DOM size," "uses deprecated APIs"). Fix these after opportunities.

Mobile vs Desktop Scores

PageSpeed Insights tests both mobile and desktop. Mobile scores are almost always lower — and they are what Google primarily uses for ranking (mobile-first indexing). The mobile simulation uses a throttled CPU (4x slowdown) and throttled network (slow 4G), which is why even a fast site can score poorly on mobile.

Your target: green (90+) on mobile. Desktop 90+ is easy for most sites; mobile 90+ requires deliberate performance work.

The Priority Action Plan

When you first run PageSpeed Insights, address issues in this order:

  1. Preload your LCP image — quick win, often saves 1–3 seconds of LCP
  2. Eliminate render-blocking resources — defer JavaScript, load CSS non-blocking
  3. Compress and modernise images — convert to WebP/AVIF, add explicit dimensions
  4. Add a CDN — reduces TTFB for users far from your server
  5. Fix CLS issues — add image dimensions, reserve ad slots
  6. Reduce JavaScript bundle size — code splitting, tree shaking, lazy loading
  7. Address INP — break up long tasks, defer non-critical scripts

Frequently Asked Questions

Does a perfect PageSpeed score guarantee a Google ranking boost?
No. Core Web Vitals are one ranking factor among hundreds. Google has confirmed that passing Core Web Vitals thresholds (Good on LCP, CLS, INP) is the goal — going from 90 to 100 has no additional ranking benefit. Content quality, backlinks, and relevance matter far more than whether your score is 95 vs 100.
Why is my mobile score so much lower than desktop?
Lighthouse simulates a mid-range Android phone with a 4x CPU slowdown and slow 4G network for mobile testing. Desktop uses no throttling. This simulation is intentional — a large portion of your real users are on slower devices. Closing the gap requires specifically optimising for low-end mobile: smaller images, less JavaScript, minimal render-blocking resources.
My PSI score changes every time I run it — why?
Lab-based Performance scores have natural variance because they depend on available CPU, network conditions at test time, and which resources are cached. Variation of 5–10 points between runs is normal. Run the test 3 times and average the scores, or use the field data section (which shows real CrUX data) for a more stable picture.
Should I optimise for PageSpeed Insights or real user experience?
Real user experience — always. PageSpeed Insights is a proxy measurement. Some high-scoring pages feel slow to real users because of interactivity issues not captured by the score. The field data section (CrUX data for real Chrome users) is more trustworthy than the lab score for understanding actual user experience.

Related Articles

SEO
Technical SEO for Static Sites
Image Formats
PNG vs WebP vs AVIF
AI Basics
Prompt Engineering Guide
Comparisons
GLB vs FBX
← Back to Knowledge Hub