How to Actually Improve Your Lighthouse Scores (2026 Guide)
Improve Lighthouse scores by fixing the metrics, not the number. Compress and properly size images, cut render-blocking JavaScript, and set explicit width and height on media. Target LCP under 2.5s, INP under 200ms, and CLS under 0.1. Chase those, since 100 is rarely worth it.
Part of the complete web design guide.
On this page
- First, understand what the score actually measures
- The fixes that actually move the needle
- 1. Fix your images before you touch your JavaScript
- 2. Serve modern formats and don’t hand-optimize
- 3. Kill render-blocking CSS and fonts
- 4. Ship less JavaScript
- 5. Set proper caching and compression
- What I don’t do
- FAQ
- Is a Lighthouse score of 100 worth chasing?
- Why does PageSpeed Insights show a different score than my local Lighthouse?
- Do these fixes hurt SEO?
Most Lighthouse reports look worse than the site actually is, and most “fixes” people try make things slower. The score is a symptom, not the disease. Here’s how I approach it on real sites, including the ones I build for clients around Commack and the rest of Long Island.
First, understand what the score actually measures
Lighthouse runs a simulated throttled load and scores five categories: Performance, Accessibility, Best Practices, SEO, and (if you’re on a PWA) installability. The number everyone obsesses over is Performance, and it’s built from weighted metrics:
- LCP (Largest Contentful Paint): when the biggest thing in the viewport finishes rendering. Target under 2.5s.
- INP (Interaction to Next Paint): replaced FID in March 2024. Measures the worst interaction latency. Target under 200ms.
- CLS (Cumulative Layout Shift): how much stuff jumps around. Target under 0.1.
- TBT (Total Blocking Time): lab-only proxy for INP. Target under 200ms.
- FCP and Speed Index: how fast anything shows up.
Two things people get wrong constantly. One, Lighthouse is a lab test on your machine with simulated throttling. It is not field data. Two, the score is non-linear: going from 95 to 100 is hard, going from 40 to 70 is usually easy. If a client’s score is 62 and their real users on 4G are happy, I tell them that. Don’t chase 100. Chase the metrics.
The fixes that actually move the needle
1. Fix your images before you touch your JavaScript
On the vast majority of sites I audit, images are the LCP element and the biggest byte sink. Three things:
<img
src="/hero-800.avif"
srcset="/hero-400.avif 400w,
/hero-800.avif 800w,
/hero-1600.avif 1600w"
sizes="(max-width: 700px) 100vw, 800px"
width="1600" height="900"
fetchpriority="high"
decoding="async"
alt="Storefront on Main Street">Notes: fetchpriority="high" on the LCP image is one of the highest-use single attributes you can add. Explicit width and height prevent CLS. loading="lazy" belongs on everything except the LCP image. Lazy-loading your hero is a classic self-own: the browser defers the one thing you needed immediately.
2. Serve modern formats and don’t hand-optimize
AVIF and WebP are supported everywhere that matters in 2026. If you’re on WordPress, most modern image plugins handle conversion. If you’re on a static site, your build should generate the variants. Don’t convert images by hand in Photoshop. You’ll forget, and six months from now someone uploads a 4MB PNG and your score tanks.
3. Kill render-blocking CSS and fonts
Every stylesheet in your <head> blocks the first paint. For a typical marketing site you have maybe 15KB of critical CSS and 200KB of everything else. Inline the critical stuff, defer the rest:
<style>/* critical above-the-fold CSS here */</style>
<link rel="preload" href="/css/site.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/site.css"></noscript>For fonts, self-host. Google Fonts adds a DNS lookup, a TLS handshake, and a third-party dependency. If you must use it, preconnect. Either way, use font-display: swap and preload the one weight you actually use above the fold:
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var.woff2') format('woff2-variations');
font-weight: 100 900;
font-display: swap;
}4. Ship less JavaScript
This is the one that separates a 60 from a 90 on content sites. A single 300KB framework bundle will blow your TBT budget on a mid-range Android. Options, in order of how much I like them:
- Don’t use a framework for a brochure site. HTML and a little vanilla JS is fine.
- If you need one, use islands or partial hydration (Astro, or React Server Components done right).
- Code-split aggressively and defer everything not needed for first paint.
- Audit third-party scripts. One chat widget, one analytics tag, and one A/B testing tool can easily cost you 20 points.
Third parties are the silent killer. I’ve watched a score drop from 94 to 71 because someone pasted a marketing tag into the header. Move them to defer, load them on interaction, or cut them.
5. Set proper caching and compression
# nginx
location ~* \.(css|js|woff2|avif|webp|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript image/svg+xml;
# or better, brotli
brotli on;
brotli_types text/css application/javascript image/svg+xml;Hashed filenames plus a one-year immutable cache means repeat visitors load almost nothing. If you’re on a CDN (Cloudflare, Fastly, whatever), make sure HTML is cached at the edge too, and invalidated on deploy.
What I don’t do
I don’t install a “Lighthouse score booster” plugin. I don’t inline 400KB of CSS to game FCP. I don’t lazy-load everything and call it performance. And I don’t chase 100 on a phone simulation that doesn’t match your actual traffic. Real user monitoring (CrUX, or a RUM tool) is the number that matters. Lighthouse is a diagnostic, not a grade.
If you’re weighing whether to fix an existing site or rebuild it, that’s usually a budget and timeline question more than a technical one. I’ve written more about how I think about that kind of work as a Long Island web design project, but the short version is: fix the images and JavaScript first, measure, then decide.
FAQ
Is a Lighthouse score of 100 worth chasing?
No. The score is a weighted lab simulation, and the last 10 points usually require cutting features your users want. Get LCP under 2.5s, INP under 200ms, and CLS under 0.1, then stop.
Why does PageSpeed Insights show a different score than my local Lighthouse?
PageSpeed Insights runs Lighthouse against Google’s servers with their own throttling, and it also shows real field data from the Chrome UX Report. Your local run uses your machine and your network. Trust the field data over either lab number.
Do these fixes hurt SEO?
They help it. Core Web Vitals are a ranking signal, and faster pages get crawled more and convert better. The one thing to watch is lazy-loading images above the fold, which can hurt both LCP and how Google indexes them. Don’t do that.
