CSS

How to Actually Get a 100 Lighthouse Score (and When Not to Bother)

By Ken Key Aug 1, 2026 4 min read Updated Oct 16, 2026

How to Actually Get a 100 Lighthouse Score (and When Not to Bother)
The short answer

Getting a 100 means fixing the real bottlenecks first: properly sized WebP or AVIF images, fast LCP, near-zero layout shift, and minimal blocking JavaScript. Skip it when third-party scripts you actually need make 100 unrealistic. Chase field data instead, since that is what Google ranks.

Part of the complete web design guide.

On this page

Lighthouse scores are a diagnostic, not a grade. You can hit 100 on a small static site in an afternoon, and you can spend a week chasing the last few points on a site that genuinely needs third-party scripts to function. The trick is knowing which points are real performance wins and which are just the audit tool being picky.

I’ve rebuilt enough sites on Long Island web design projects to know the difference. Here’s what actually moves the needle in 2026, in the order I tackle it.

First, understand what Lighthouse is measuring

Lighthouse runs a synthetic test. It loads your page once, on a simulated device, with simulated throttling, and scores four categories: Performance, Accessibility, Best Practices, and SEO. The Performance score is a weighted average of a handful of metrics, and the weights shift over time, so don’t memorize them. Just know that the two that matter most are Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) replaced First Input Delay in 2024 and is now part of the Core Web Vitals.

One critical thing: the score you get in the Chrome DevTools panel is a lab score. Your real users’ experience (field data, from the Chrome UX Report) is what Google actually uses for ranking. A 100 in the lab means nothing if real phones on LTE are waiting four seconds for your hero image.

The changes that actually get you to 100

1. Serve properly sized, modern images

This is the single biggest win on most sites I audit. A 2400px hero JPEG scaled down to 800px with CSS still downloads the full 2400px file. Fix the source, not the display.

<img
 src="hero-800.avif"
 srcset="hero-480.avif 480w, hero-800.avif 800w, hero-1600.avif 1600w"
 sizes="(max-width: 600px) 480px, 800px"
 width="800" height="450"
 fetchpriority="high"
 alt="Storefront on Main Street"
>

Use AVIF with a WebP fallback if you need it. Set explicit width and height attributes so the browser reserves space and CLS stays at zero. Add fetchpriority="high" to your LCP image and loading="lazy" to everything below the fold. Don’t lazy-load the hero. That’s a common self-inflicted LCP wound.

2. Stop loading fonts you don’t use

Google Fonts is fine, but a full variable font with every weight and every language subset is not. Subset it, self-host it, and preload the one file you actually need.

<link rel="preload" href="/fonts/inter-var.woff2"
 as="font" type="font/woff2" crossorigin>

And use font-display: swap so text renders immediately with a fallback. If you’re feeling ambitious, size-adjust on your fallback font kills the layout shift when the real font swaps in.

3. Trim your JavaScript

Every analytics tag, chat widget, heatmap, and A/B testing script is a tax on your score. I’ve seen sites where the actual application code was 40KB and the third-party tags were 400KB. Audit them with the Coverage panel in DevTools. If a tag hasn’t earned its place, remove it. If it has, load it after interaction.

<script>
 const loadChat = () => {
 const s = document.createElement('script');
 s.src = '/js/chat-widget.js';
 s.defer = true;
 document.head.appendChild(s);
 };
 ['scroll', 'click', 'keydown'].forEach(evt =>
 window.addEventListener(evt, loadChat, { once: true, passive: true })
 );
</script>

That one pattern often recovers 20 or 30 points by itself, because the widget never blocks the initial render.

4. Fix the accessibility and best-practices audits

These are usually free points. Contrast ratios, form labels, button names, landmark regions, a valid <html lang>, a proper meta description, and a real <title> on every page. Lighthouse will tell you exactly what’s wrong. Most of it is a 10-minute fix per issue. The one people ignore most is color contrast, which is also the one that actually affects real users.

When chasing 100 is a waste of your time

  • You have a legitimate business reason for heavy third-party scripts. A booking engine, a payment embed, a compliance tag. They cost points. That’s fine.
  • Your field data is already good. If real users are seeing fast LCP and low CLS, a lab score of 87 is not a crisis.
  • You’re optimizing a page nobody visits. Fix the pages that make money first.
  • You’re gaming the score. Hiding content, faking load order, or blocking the audit is not performance work. It’s just lying to a tool.

Aim for 90+ on the pages that matter, keep your Core Web Vitals green in the field, and spend the rest of your time on content and conversion. That’s the honest version of this whole topic.

FAQ

Does a 100 Lighthouse score help my Google rankings?

Indirectly. Google uses field Core Web Vitals as a tiebreaker, not a primary ranking factor. A fast site helps because users stay and engage, and that engagement does matter. But a perfect score won’t outrank better content.

Why does my score change every time I run it?

The test is synthetic and depends on server response time, network conditions, and which third-party scripts happened to load. Run it three times and look at the median, or use PageSpeed Insights to see field data alongside the lab score.

What’s the fastest single fix for a bad score?

Fix your largest image. Compress it, convert it to AVIF or WebP, serve it at the right size, and add fetchpriority="high". On most sites that alone moves LCP by a second or more and takes about 15 minutes.

Have a project like this?

I do Long Island web design for Long Island businesses. If you need this done right, let’s talk.