Lighthouse performance score

What this check does

Calls the PageSpeed Insights API for the page URL and reports the overall performance score (0–100). The score is a weighted average of five lab metrics: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, and Speed Index.

Why it matters

Performance is a confirmed ranking factor through Core Web Vitals and a confirmed conversion factor through every conversion study ever published. The Lighthouse score is the easiest single number to track — Google itself groups it into three bands:

• 90–100 (green) — fast. Target this.
• 50–89 (orange) — needs work.
• 0–49 (red) — slow. Likely losing rankings and conversions.

A page at 30 isn’t slightly worse than one at 80; it’s losing visitors before they see anything.

How to fix it

Performance work is a layered effort. Tackle the biggest contributors first:

1. Optimize the largest images (LCP).

Most slow pages are slow because of one hero image weighing 2–5 MB. Compress it, serve in AVIF/WebP, set explicit width and height:

<img
  src="/hero.avif"
  width="1200"
  height="630"
  alt="…"
  fetchpriority="high"
  loading="eager">

fetchpriority="high" tells the browser to download this image before non-critical assets — directly improves LCP.

2. Defer non-critical JavaScript (TBT and INP).

Every analytics, chat widget, and A/B testing script runs on the main thread before users can interact. Defer or async them:

<script src="/analytics.js" defer></script>
<script src="https://plausible.io/js/plausible.js" defer></script>

For React/Next.js: code-split heavy components, use dynamic(() => import(...), { ssr: false }) for below-the-fold widgets, and audit third-party scripts in DevTools’ Performance tab.

3. Inline critical CSS, defer the rest.

<style>/* critical CSS — visible above the fold */</style>
<link rel="preload" href="/main.css" as="style" onload="this.rel='stylesheet'">

Critical CSS extractors (Critters, Beasties for Next.js, astro:assets for Astro) automate this.

4. Reserve space for dynamic content (CLS).

Every image needs width and height. Every embed needs an explicit container. Every web font needs font-display: swap and a fallback that matches metrics.

5. Cache, compress, CDN.

Serve static assets from a CDN (Cloudflare, Bunny, Fastly). Enable Brotli compression on HTML/CSS/JS. Set Cache-Control: public, max-age=31536000, immutable on fingerprinted assets.

Tools to use:

• PageSpeed Insights — same engine MetricSpot calls. Shows specific audit failures.
• Chrome DevTools → Performance panel — find the actual slow frame.
• npx unlighthouse https://yourdomain.com — Lighthouse against every page, not just the homepage.
• WebPageTest — for testing from specific geographies and connection types.

Related checks: LCP, INP, CLS.

Frequently asked questions

Why does my local Lighthouse score differ from PSI?

Local Lighthouse uses your CPU and network; PSI uses a throttled mid-tier Android device on a 4G connection. PSI is what Google uses for the real signal — always tune against that, not your M3 MacBook’s score.

Does the score affect ranking directly?

Indirectly. Google ranks on the three Core Web Vitals (LCP, INP, CLS) — not on the composite score. But a low Lighthouse score almost always means the underlying CWV metrics are also bad. Fix the metrics; the score follows.

My score swings between visits — why?

Field data (what PSI shows when the URL has enough Chrome user traffic) is stable. Lab data (single Lighthouse run) is variable — server warm/cold, ad networks loading different creatives, third-party scripts. Run PSI three times and take the median, or rely on the 28-day field data when available.