A 95+ Lighthouse performance score comes from roughly a dozen specific, repeatable decisions on fonts, images, JavaScript, and third-party scripts, made the same way on every build. It is not a one-time fix: Google's own scoring model weights two metrics, Total Blocking Time and Largest Contentful Paint, at 55% of the total, so most of the work is keeping those two under control.
What actually decides a Lighthouse score
Lighthouse does not grade a page on one number. It runs a simulated mobile load (throttled CPU, throttled network) and scores five timing metrics, then weights them into the single score you see. As of Lighthouse 10, the weighting is Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10%, and Speed Index 10% (Chrome Developers, Lighthouse performance scoring).
That weighting is the reason most "speed fixes" do not move the number much. Minifying a stylesheet touches First Contentful Paint, worth 10% of the score. A render-blocking third-party script that delays interactivity hits Total Blocking Time, worth 30%. Fix the big-weight metrics first, or the score barely moves no matter how much you optimize everything else.
What counts as a good score, and why we stop at 95, not 100
Chrome's own documentation puts 0 to 49 as poor, 50 to 89 as needs improvement, and 90 to 100 as good. Inside that top band, the returns flatten fast: pushing a page from 90 to 94 takes roughly the same engineering effort as pushing it from 99 to 100, according to the same Lighthouse scoring guidance. We stop building past 95 because the last five points are usually spent trimming kilobytes nobody will notice, time better spent on the page's actual content or conversion path.
Fonts
We bundle fonts with next/font (Geist, Geist Mono, Instrument Serif) instead of pulling them from a third-party CSS import. next/font self-hosts the font files and inlines the @font-face CSS at build time, so there is no extra round trip to a font CDN before text can render. display: swap is the default, and it is the right default for a marketing site: text shows in a fallback font immediately and swaps in the real one once it loads, rather than leaving a blank space. Two custom fonts maximum per site. The 2025 Web Almanac found 87% of mobile pages load at least one web font (HTTP Archive, 2025 Web Almanac: Performance), which means most sites are already paying this cost. The difference is whether that font is self-hosted and swapped in cleanly, or loaded from an external domain that adds its own DNS lookup and connection before a single word paints.
Images
WebP or AVIF, with a srcset and explicit width and height attributes to lock Cumulative Layout Shift at zero. Above-the-fold images get the priority flag so the browser fetches them immediately instead of waiting its turn. Everything else lazy-loads. We do not ship hero JPGs over 200 KB unless the design genuinely requires it.
This matters more than it looks. The same Web Almanac chapter found 62% of mobile pages and 65% of desktop pages ship at least one image without explicit width and height (HTTP Archive, 2025 Web Almanac: Performance), which is the single most common cause of layout shift: the page jumps as the image finally loads and claims its space. It also found JPG is still the most common format for a page's largest image at 57%, against 26% for PNG and only 11% for WebP, meaning most sites have not made the format switch that cuts file size roughly in half for the same visual quality.
JavaScript
App Router server components by default. Client islands only for the pieces that need interactivity: a theme toggle, scroll progress, an FAQ accordion, a contact form. The home page ships under 100 KB of JavaScript, gzipped, on most builds.
The industry trend is moving the opposite direction. Median mobile Total Blocking Time across the web rose to 1,916 milliseconds in 2025, up 58% from 1,209 milliseconds the year before (HTTP Archive, 2025 Web Almanac: Performance), a chapter that ties the jump directly to heavier JavaScript execution on the main thread. Since Total Blocking Time carries the single largest weight in the Lighthouse score, 30%, that one trend line explains a lot of why average scores are not improving even as hosting and connections get faster.
CSS
One stylesheet, design tokens defined at the top, no utility-class soup unless the team maintaining the site is comfortable with it. Critical, above-the-fold styles get inlined. Everything else loads deferred.
Third-party scripts
Cloudflare Web Analytics runs cookie-less in about 4 KB. We do not add Google Tag Manager unless a client specifically needs it for an existing marketing stack, and when we do, we load it after the main content paints, not before.
What we skip entirely
Autoplaying hero video. Web fonts loaded from a third-party CDN instead of self-hosted. Megabyte-sized SVG illustrations exported straight out of a design tool without cleanup. Client-side hydration for static content that never needed a JavaScript framework running on top of it in the first place.
Where the Lighthouse score weight actually goes
| Metric | Score weight | What it measures |
|---|---|---|
| Total Blocking Time | 30% | Main thread blocked by JavaScript during load |
| Largest Contentful Paint | 25% | Time to render the biggest visible element |
| Cumulative Layout Shift | 25% | How much content jumps around while loading |
| First Contentful Paint | 10% | Time to first pixel painted |
| Speed Index | 10% | How quickly the page fills in visually |
Source: Chrome Developers, Lighthouse performance scoring.
Does a higher score actually make more money, or is this just a vanity number?
It shows up in revenue, not just in a report. Google commissioned a joint study with 55 and Deloitte across 37 brand sites and roughly 30.5 million sessions, and found that a 0.1-second mobile speed improvement raised conversion rates by 8.4% for retail sites and 10.1% for travel sites, with retail shoppers spending 9.2% more on the faster experience (web.dev, Milliseconds make millions). A tenth of a second is smaller than a blink. The study measured that improvement across every page in a full user journey, not a single landing page, which is the same reason we treat Lighthouse as a build-wide standard instead of a one-page trick to pass before launch.
That also lines up with where the web actually sits today. The same 2025 Web Almanac data shows only 48% of mobile pages and 56% of desktop pages pass all three Core Web Vitals, up from 44% and 55% the year before (HTTP Archive, 2025 Web Almanac: Performance). Just over half the web clears the bar on desktop. Under half clears it on mobile, where most traffic actually happens. A site that scores 95+ consistently is not keeping up with an industry standard; it is ahead of most of the web by a wide margin.
What this looks like on a real project
| Project stage | What we check | What it should cost you |
|---|---|---|
| New build | Fonts, image pipeline, server components from day one | Included in the build, not a separate line item |
| Existing site, never audited | Full Lighthouse + CrUX field data pass | A fixed-scope audit before any fix work starts |
| Existing site, partial fixes tried before | Re-audit to find what the last fix missed | Scoped against the specific metric still failing |
If your current site has never had a Lighthouse audit, that is the first step, not a guess at what to fix. Our web development team runs the same scoring model described above against your actual pages, not a synthetic demo page, and the SEO side of the house cares about the same metrics for a different reason: Core Web Vitals factor into how Google ranks a page, so a slow site is losing on two fronts at once. For a broader look at how small business sites perform against this bar industry-wide, see our breakdown of the 2026 website speed data. You can see examples of delivered builds in our case studies, or start a project and we will run the audit first, free, and come back with the specific fixes that move your score the most.
Frequently asked questions
What is considered a good Lighthouse score?
Chrome's own documentation splits the scale into three bands: 0 to 49 is poor, 50 to 89 needs improvement, and 90 to 100 is good. We target 95 and above because the effort to go from 90 to 94 is roughly the same as the effort to go from 99 to 100, so chasing a perfect 100 rarely justifies the time against other priorities on a project.
Why does my Lighthouse score change every time I run it?
Lighthouse simulates a mid-range mobile device and a throttled network connection rather than measuring every real visitor, so results vary slightly between runs depending on server response time and background load at that moment. For a more stable picture, Google's Chrome UX Report (CrUX) captures real visitor data instead of a single simulated run, and the two sources can disagree for that reason.
Does a Lighthouse score directly affect Google search rankings?
Not the composite Lighthouse number itself. Google's ranking systems use the three Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift) measured from real Chrome users, not the lab-simulated Lighthouse score. Lighthouse is still the fastest diagnostic tool for finding and fixing the issues that drag those field metrics down.
What is the single biggest thing that hurts most sites' scores?
Unoptimized JavaScript execution blocking the main thread, measured as Total Blocking Time, which alone carries 30% of the Lighthouse performance score, the largest single weight of any metric. Heavy third-party scripts, oversized client-side frameworks, and render-blocking ad or chat widgets are the usual causes.
How long does it take to fix a slow existing website?
It depends on what is wrong, but a fixed-scope Lighthouse and Core Web Vitals audit typically takes a few days to identify every failing metric and its root cause, with implementation scoped separately based on what the audit finds. A site with a handful of oversized images and no font strategy is a faster fix than one with years of accumulated third-party scripts.
Is a 95+ Lighthouse score worth it for a small local business site?
Yes, for the same reason it matters for any site: speed affects both how long a visitor stays and how Google ranks the page. A five-page brochure site has an advantage here, since it carries less third-party weight than a larger site by default, but that advantage disappears the moment an unoptimized hero image or a bloated page builder theme gets added on top of it.