How To Hack Your Google Lighthouse Scores In 2024 — Smashing Magazine

Lighthouse Scores Are Not the Whole Story

Google Lighthouse has become a popular way to benchmark web page performance, accessibility, SEO, and best practices with a single click. Teams use it to compare front-end frameworks or to verify that refactoring efforts paid off, and a perfect score has become a badge of honor. That enthusiasm for performance is a good thing, but the metric is far more nuanced than a single number suggests.

The most important limitation is the data itself. Lab-based Lighthouse tests run on a controlled, high-spec machine with a limited sample size. Real-world conditions — varied devices, connection speeds, browsers, and screen sizes — can produce very different results. Field data from real users, collected through an application performance monitoring tool, provides a more accurate picture. A 2021 analysis by Philip Walton found that nearly half of all pages scoring 100 on Lighthouse in the HTTP Archive did not meet recommended Core Web Vitals thresholds.

Performance Is About Experience, Not Just Speed

Speed is often conflated with load time, but page load is not a single moment. As Google puts it, a page load is “an experience that no single metric can fully capture.” Users perceive speed at multiple points during loading, and focusing on one metric can hide bad experiences elsewhere. The emphasis should be on usability and how the page feels to interact with, rather than purely on raw numbers.

Lighthouse's performance score reflects this philosophy. It combines Core Web Vitals — First Contentful Paint (FCP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS) — with other speed metrics, including Speed Index (SI) and Total Blocking Time (TBT), weighted to prioritize a usable experience over mere quickness.

The weighting reveals what Google considers most important:

Responsiveness to User Input

Total Blocking Time carries the highest weight. It measures the total time after FCP during which the main thread is blocked by JavaScript tasks running longer than 50ms, preventing the page from reacting to user actions like clicks or key presses.

Useful Content and Visual Stability

LCP marks when the main content has likely loaded, targeting under 2.5 seconds. CLS ensures the page does not shift unexpectedly during load, which would disrupt the user. These two metrics hold nearly equal weight.

Initial Content Display

FCP tracks when the user first sees anything at all on the screen, while SI measures how quickly content visually populates over time. Both are important, but a fast FCP with a slow LCP or bad CLS will hurt the score more than a slightly slower initial paint with no visual instability.

Usability and responsiveness are favored over raw speed. A page that responds to input and loads useful content without shifting earns a better score than one that paints quickly but is unresponsive or unstable.

How Scores Are Calculated

Each metric is converted to a score from 0 to 100 based on a log-normal distribution derived from real website performance data in the HTTP Archive. This means the final score is relative to actual sites on the web, not isolated. Because the distribution is non-linear, improving a low score is relatively easy, while pushing a high score much higher requires disproportionate effort.

The Lighthouse Scoring Calculator allows you to see how adjusting individual metric weightings affects the overall performance score.

Can Lighthouse Be Tricked?

Given the focus on usability over speed, the question arises: can a page that is genuinely poor in usability and usefulness be made to look great to Lighthouse? To test this, experiments were run using the Chromium Lighthouse plugin in an incognito Arc browser window, with default navigation and mobile settings. These controlled lab conditions contradict the earlier advice about field data, but the exercise is still revealing — it shows that Lighthouse scores are only one small piece of a complex performance puzzle.

The LCP Element: Know It, Then Decide What to Do With It

Lighthouse only considers certain elements when determining LCP: <img> elements, <image> inside <svg>, <video>, elements with a url() background image (CSS gradients don't count), and block-level elements containing text. Excluded from consideration are elements with zero opacity, elements that cover the full viewport, and low-information placeholder images.

The subjective part is whether an element actually constitutes useful page content. A demo page containing only an <h1>, where JavaScript inserts more descriptive text after 10 seconds and hides the heading, still earns a perfect Lighthouse score—even when the heading is replaced by a single full stop. Lighthouse assumes the page is useful within the test window, regardless of what the page actually contains.

This suggests a practical (if questionable) approach for pages that genuinely need client-side rendering: rather than showing a skeleton loader, display a minimal splash screen containing one valid LCP element. This gives Lighthouse the impression the page is useful sooner. This is not recommended for production sites—serving static HTML from a CDN is almost always better—and it won't help with search engine indexing since crawlers won't see the real content in the DOM. Attempts to fake it with tiny, heavily compressed images tend to backfire: Lighthouse disqualifies them as low-entropy placeholders.

This approach also doesn't hold up in more complex applications. Discord's splash screen on hard refresh yields a performance score of 29 because the actual LCP element is content behind the splash screen—large images in the open text channel—rather than anything in the splash itself. For authenticated apps, though, Lighthouse scores arguably matter less since they don't need SEO.

There's a flip side to this sensitivity. In 2021, developers at RentPath raised their Lighthouse performance score by 17 points by increasing image thumbnail sizes, which shifted the LCP calculation from a slow-loading Google Map tile to a larger thumbnail. The lesson: if you know your LCP element and control it, you can influence your score—sometimes dramatically—whether through legitimate optimization or gaming the metric.

Deferred Layout Shifts and CLS

CLS is scored on a decimal scale where under 0.1 is good and over 0.25 is poor. Lighthouse measures the largest burst of unexpected shifts during the page load timeline. One-off shifts may not matter, but consecutive ones add up quickly.

If your page has layout shifts on load, deferring them past the test window is straightforward. A demo page where JavaScript immediately injects new text elements—shifting existing content—earns a CLS score of 0.143. The same page with the injection paused five seconds via setTimeout() scores 100 on performance, even though the delayed content popping in is arguably worse for usability. The trick fails for field data and time-span tests, however; Lighthouse correctly reports a non-green CLS of around 0.186 when the deferred shifts fall within the measured window.

CSS animations with transform are another route to avoid CLS penalties. Scaling text elements from 0 to 1 and moving them around the page doesn't trigger CLS, provided the nodes are already in the DOM at page load. If you add text nodes programmatically after load and then animate them with transforms, Lighthouse will detect the shifts.

What You Can't Game: Speed Index and TBT

Speed Index measures visual progress during load, so there's no way to make it appear faster than it is. The only path to a better score is optimization: static HTML from a CDN, minimal or no images, trimmed CSS, and no JavaScript or external dependencies. These measures are draconian for real-world 2024 pages, but they define the ceiling.

TBT—the total time after FCP where main-thread tasks block user input— is also hard to fake convincingly. Deferring all JavaScript past the test window would technically work, but you'd still need placeholder content for FCP and LCP, plus a mechanism to load your actual application afterward (without loading a separate React app into a placeholder page). The more viable strategy is to rely on modern frameworks and hosting that render pages server-side, reducing client-side computation and therefore main-thread blocking.

A Rough Guide, Not a Verdict

Lighthouse cannot detect everything wrong with a site. In 2019, Manuel Matuzović built a deliberately inaccessible page that earned a perfect Lighthouse score. Repeating the experiment five years later doesn't yield different results. A demo page where CSS and JavaScript disable all input events—making the page technically unresponsive—scores 100 on both performance and accessibility once JavaScript re-enables the button after five seconds.

Lighthouse remains what it has always been: a useful signal that cannot substitute for usability testing and judgment.

Hacks That Inflate Scores

Beyond the code-level tweaks, a handful of environment and methodology tricks can push Lighthouse numbers up without changing a single line of application logic. These are deliberately contrarian to real performance work:

• Always run Lighthouse on the fastest, highest-spec hardware you can access.
• Test only over the fastest possible internet connection — relocate physically if that's what it takes.
• Rely exclusively on lab data measured with that ideal hardware and connection, never field data.
• Repeat lab runs under varied conditions, applying the code-level hacks from earlier in this guide, until you land on scores you're happy to show off.

The correct way to improve web performance, of course, is the inverse: use real-world conditions, production traffic, and instrumented observability. Treat Lighthouse as a canary for obvious issues; for actual insight into user-facing speed, lean on application monitoring that captures production web vitals data instead of lab results.

The complete demonstration site for every technique described here is available for educational review.