{"id":485,"date":"2024-06-11T18:00:00","date_gmt":"2024-06-11T18:00:00","guid":{"rendered":"https:\/\/upprofits.net\/?p=485"},"modified":"2024-08-30T11:28:31","modified_gmt":"2024-08-30T11:28:31","slug":"how-to-hack-your-google-lighthouse-scores-in-2024","status":"publish","type":"post","link":"https:\/\/upprofits.net\/index.php\/2024\/06\/11\/how-to-hack-your-google-lighthouse-scores-in-2024\/","title":{"rendered":"How To Hack Your Google Lighthouse Scores In 2024"},"content":{"rendered":"<p>              <title>How To Hack Your Google Lighthouse Scores In 2024<\/title><\/p>\n<article>\n<header>\n<h1>How To Hack Your Google Lighthouse Scores In 2024<\/h1>\n<address>Salma Alam-Naylor<\/address>\n<p>                  2024-06-11T18:00:00+00:00<br \/>\n                  2024-08-30T10:05:08+00:00<br \/>\n                <\/header>\n<p>This article is sponsored by <b>Sentry.io<\/b><\/p>\n<p>Google Lighthouse has been one of the most effective ways to gamify and promote web page performance among developers. Using Lighthouse, we can assess web pages based on overall performance, accessibility, SEO, and what Google considers \u201cbest practices\u201d, all with the click of a button.<\/p>\n<p>We might use these tests to evaluate out-of-the-box performance for front-end frameworks or to celebrate performance improvements gained by some diligent refactoring. And you know you love sharing screenshots of your perfect Lighthouse scores on social media. It\u2019s a well-deserved badge of honor worthy of a confetti celebration.<\/p>\n<figure><a href=\"https:\/\/upprofits.net\/wp-content\/uploads\/2024\/06\/1-google-lighthouse-scores-800px.gif\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/upprofits.net\/wp-content\/uploads\/2024\/06\/1-google-lighthouse-scores-800px.gif\" width=\"800\" height=\"430\" alt=\"Animated gif of four perfect Google Lighthouse scores with confetti popping in all over the place\" \/><\/a><\/figure>\n<p>Just the fact that Lighthouse gets developers like us talking about performance is a win. But, whilst I don\u2019t want to be a party pooper, the truth is that web performance is far more nuanced than this. In this article, we\u2019ll examine how Google Lighthouse calculates its performance scores, and, using this information, we will attempt to \u201chack\u201d those scores in our favor, <strong>all in the name of fun and science<\/strong> &mdash; because in the end, Lighthouse is simply a good, but rough guide for debugging performance. We\u2019ll have some fun with it and see to what extent we can \u201ctrick\u201d Lighthouse into handing out better scores than we may deserve.<\/p>\n<p>But first, let\u2019s talk about data.<\/p>\n<h2 id=\"field-data-is-important\">Field Data Is Important<\/h2>\n<p>Local performance testing is a great way to understand if your website performance is trending in the right direction, but it won\u2019t paint a full picture of reality. The World Wide Web is the Wild West, and collectively, we\u2019ve almost certainly lost track of the variety of device types, internet connection speeds, screen sizes, browsers, and browser versions that people are using to access websites &mdash; all of which can have an impact on page performance and user experience.<\/p>\n<p>Field data &mdash; and lots of it &mdash; collected by an <a href=\"http:\/\/sentry.io\/for\/performance\/\">application performance monitoring<\/a> tool like Sentry from real people using your website on their devices will give you a far more accurate report of your website performance than your lab data collected from a small sample size using a high-spec super-powered dev machine under a set of controlled conditions. Philip Walton reported in 2021 that \u201c<a href=\"https:\/\/philipwalton.com\/articles\/my-challenge-to-the-web-performance-community\/\">almost half of all pages that scored 100 on Lighthouse didn\u2019t meet the recommended Core Web Vitals thresholds<\/a>\u201d based on data from the HTTP Archive.<\/p>\n<p>Web performance is more than a single <a href=\"https:\/\/sentry.io\/for\/web-vitals\/\">core web vital metric<\/a> or Lighthouse performance score. What we\u2019re talking about goes way beyond the type of raw data we\u2019re working with.<\/p>\n<h2 id=\"web-performance-is-more-than-numbers\">Web Performance Is More Than Numbers<\/h2>\n<p><em>Speed<\/em> is often the first thing that comes up when talking about web performance &mdash; just how long does a page take to load? This isn\u2019t the worst thing to measure, but we must bear in mind that speed is probably influenced heavily by business KPIs and sales targets. Google <a href=\"https:\/\/www.thinkwithgoogle.com\/marketing-strategies\/app-and-mobile\/mobile-page-speed-new-industry-benchmarks\/\">released a report in 2018<\/a> suggesting that the probability of bounces increases by 32% if the page load time reaches higher than three seconds, and soars to 123% if the page load time reaches 10 seconds. So, we must conclude that converting more sales requires reducing bounce rates. And to reduce bounce rates, we must make our pages <em>load faster<\/em>.<\/p>\n<p>But what does \u201cload faster\u201d even mean? At some point, we\u2019re physically incapable of making a web page load any faster. Humans &mdash; and the servers that connect them &mdash; are spread around the globe, and modern internet infrastructure can only deliver so many bytes at a time.<\/p>\n<p>The bottom line is that page load is not a single moment in time. In an article titled \u201c<a href=\"https:\/\/web.dev\/articles\/what-is-speed\">What is speed?<\/a>\u201d Google explains that a page load event is:<\/p>\n<blockquote><p>[\u2026] \u201can experience that no single metric can fully capture. There are multiple moments during the load experience that can affect whether a user perceives it as \u2018fast\u2019, and if you just focus solely on one, you might miss bad experiences that happen during the rest of the time.\u201d<\/p><\/blockquote>\n<p>The key word here is <em>experience<\/em>. Real web performance is less about <em>numbers<\/em> and <em>speed<\/em> than it is about <em>how we experience<\/em> page load and page usability as users. And this segues nicely into a discussion of how Google Lighthouse calculates performance scores. (It\u2019s much less about pure speed than you might think.)<\/p>\n<h2 id=\"how-google-lighthouse-performance-scores-are-calculated\">How Google Lighthouse Performance Scores Are Calculated<\/h2>\n<p>The Google Lighthouse performance score is calculated using a weighted combination of scores based on core web vital metrics (i.e., First Contentful Paint (FCP), Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS)) and other speed-related metrics (i.e., Speed Index (SI) and Total Blocking Time (TBT)) that are <strong>observable throughout the page load timeline<\/strong>.<\/p>\n<p>This is <a href=\"https:\/\/developer.chrome.com\/docs\/lighthouse\/performance\/performance-scoring\/#weightings\">how the metrics are weighted<\/a> in the overall score:<\/p>\n<table class=\"tablesaw break-out\">\n<thead>\n<tr>\n<th>Metric<\/th>\n<th>Weighting (%)<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Total Blocking Time<\/td>\n<td>30<\/td>\n<\/tr>\n<tr>\n<td>Cumulative Layout Shift<\/td>\n<td>25<\/td>\n<\/tr>\n<tr>\n<td>Largest Contentful Paint<\/td>\n<td>25<\/td>\n<\/tr>\n<tr>\n<td>First Contentful Paint<\/td>\n<td>10<\/td>\n<\/tr>\n<tr>\n<td>Speed Index<\/td>\n<td>10<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>The weighting assigned to each score gives us insight into how Google prioritizes the different building blocks of a good user experience:<\/p>\n<h3 id=\"1-a-web-page-should-respond-to-user-input\">1. A Web Page Should Respond to User Input<\/h3>\n<p>The highest weighted metric is <strong>Total Blocking Time (TBT),<\/strong> a metric that looks at the total time after the <strong>First Contentful Paint (FCP)<\/strong> to help indicate where the main thread may be blocked long enough to prevent speedy responses to user input. The main thread is considered \u201cblocked\u201d any time there\u2019s a JavaScript task running on the main thread for more than 50ms. Minimizing TBT ensures that a web page responds to physical user input (e.g., key presses, mouse clicks, and so on).<\/p>\n<h3 id=\"2-a-web-page-should-load-useful-content-with-no-unexpected-visual-shifts\">2. A Web Page Should Load Useful Content With No Unexpected Visual Shifts<\/h3>\n<p>The next most weighted Lighthouse metrics are <strong>Largest Contentful Paint (LCP<\/strong>) and <strong>Cumulative Layout Shift (CLS)<\/strong>. LCP marks the point in the page load timeline when the page\u2019s main content has <em>likely<\/em> loaded and is therefore <em>useful<\/em>.<\/p>\n<p>At the point where the main content has likely loaded, you also want to maintain visual stability to ensure that users can use the page and are not affected by unexpected visual shifts (CLS). A good LCP score is anything less than 2.5 seconds (which is a lot higher than we might have thought, given we are often trying to make our websites <em>as fast as possible<\/em>).<\/p>\n<h3 id=\"3-a-web-page-should-load-something\">3. A Web Page Should Load Something<\/h3>\n<p>The <strong>First Contentful Paint (FCP)<\/strong> metric marks the first point in the page load timeline where the user can see <em>something<\/em> on the screen, and the <strong>Speed Index (SI)<\/strong> measures how quickly content is visually displayed during page load over time until the page is \u201ccomplete\u201d.<\/p>\n<p>Your page is scored based on the speed indices of real websites using performance <a href=\"https:\/\/developer.chrome.com\/docs\/lighthouse\/performance\/performance-scoring#metric-scores\">data from the HTTP Archive<\/a>. A good FCP score is less than 1.8 seconds and a good SI score is less than 3.4 seconds. Both of these thresholds are higher than you might expect when thinking about <em>speed<\/em>.<\/p>\n<h2 id=\"usability-is-favored-over-raw-speed\">Usability Is Favored Over Raw Speed<\/h2>\n<p>Google Lighthouse\u2019s performance scoring is, without a doubt, less about speed and more about <strong>usability<\/strong>. Your SI and FCP could be super quick, but if your LCP takes too long to paint, and if CLS is caused by large images or external content taking some time to load and shifting things visually, then your overall performance score will be lower than if your page was a little slower to render the FCP but didn\u2019t cause any CLS. Ultimately, if the page is unresponsive due to JavaScript blocking the main thread for more than 50ms, your performance score will suffer more than if the page was a little slow to paint the FCP.<\/p>\n<p>To understand more about how the weightings of each metric contribute to the final performance score, you can play about with the sliders on the <a href=\"https:\/\/googlechrome.github.io\/lighthouse\/scorecalc\/\">Lighthouse Scoring Calculator<\/a>, and here\u2019s a rudimentary table demonstrating the effect of skewed individual metric weightings on the overall performance score, proving that page usability and responsiveness is favored over raw speed.<\/p>\n<table class=\"tablesaw break-out\">\n<thead>\n<tr>\n<th>Description<\/th>\n<th>FCP (ms)<\/th>\n<th>SI (ms)<\/th>\n<th>LCP (ms)<\/th>\n<th>TBT (ms)<\/th>\n<th>CLS<\/th>\n<th>Overall Score<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Slow to show something on screen<\/td>\n<td>6000<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>90<\/td>\n<\/tr>\n<tr>\n<td>Slow to load content over time<\/td>\n<td>0<\/td>\n<td>5000<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>90<\/td>\n<\/tr>\n<tr>\n<td>Slow to load the largest part of the page<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>6000<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>76<\/td>\n<\/tr>\n<tr>\n<td>Visual shifts occurring during page load<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>0.82<\/td>\n<td>76<\/td>\n<\/tr>\n<tr>\n<td>Page is unresponsive to user input<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>0<\/td>\n<td>2000<\/td>\n<td>0<\/td>\n<td>70<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>The overall Google Lighthouse performance score is calculated by converting each raw metric value into a score from 0 to 100 according to where it falls on its Lighthouse scoring distribution, which is a <strong>log-normal<\/strong> distribution derived from the performance metrics of real website performance data from the HTTP Archive. There are two main takeaways from this mathematically overloaded information:<\/p>\n<ol>\n<li>Your Lighthouse performance score is plotted against real website performance data, not in isolation.<\/li>\n<li>Given that the scoring uses log-normal distribution, the relationship between the individual metric values and the overall score is non-linear, meaning you can make substantial improvements to low-performance scores quite easily, but it becomes more difficult to improve an already high score.<\/li>\n<\/ol>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/2-log-normal-distribution-curve-visualization.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"461\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/2-log-normal-distribution-curve-visualization.png\" alt=\"Log-normal distribution curve visualization, high on the left, low on the right.\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/2-log-normal-distribution-curve-visualization.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Read more about <a href=\"https:\/\/developer.chrome.com\/docs\/lighthouse\/performance\/performance-scoring#metric-scores\">how metric scores are determined<\/a>, including a visualization of the log-normal distribution curve on <a href=\"http:\/\/developer.chrome.com\/\">developer.chrome.com<\/a>.<\/p>\n<h2 id=\"can-we-trick-google-lighthouse\">Can We \u201cTrick\u201d Google Lighthouse?<\/h2>\n<p>I appreciate Google\u2019s focus on usability over pure speed in the web performance conversation. It urges developers to think less about aiming for raw numbers and more about the real experiences we build. That being said, I\u2019ve wondered whether today in 2024, it\u2019s possible to fool Google Lighthouse into believing that a bad page in terms of <em>usability and usefulness<\/em> is actually a great one.<\/p>\n<p>I put on my lab coat and science goggles to investigate. All tests were conducted:<\/p>\n<ul>\n<li>Using the Chromium Lighthouse plugin,<\/li>\n<li>In an incognito window in the Arc browser,<\/li>\n<li>Using the \u201cnavigation\u201d and \u201cmobile\u201d settings (apart from where described differently),<\/li>\n<li>By me, in a lab (i.e., no field data).<\/li>\n<\/ul>\n<p>That all being said, I fully acknowledge that my controlled test environment contradicts my advice at the top of this post, but the experiment is an interesting ride nonetheless. What I hope you\u2019ll take away from this is that Lighthouse scores are only one piece &mdash; and a tiny one at that &mdash; of a very large and complex web performance puzzle. And, without field data, I\u2019m not sure any of this matters anyway.<\/p>\n<h2 id=\"how-to-hack-fcp-and-lcp-scores\">How to Hack FCP and LCP Scores<\/h2>\n<p><strong>TL;DR: Show the smallest amount of LCP-qualifying content on load to boost the FCP and LCP scores until the Lighthouse test has likely finished.<\/strong><\/p>\n<p>FCP marks the first point in the page load timeline where the user can see <em>anything<\/em> at all on the screen, while LCP marks the point in the page load timeline when the main page content (i.e., the largest text or image element) has <em>likely<\/em> loaded. A fast LCP helps reassure the user that the page is <em>useful<\/em>. \u201cLikely\u201d and \u201cuseful\u201d are the important words to bear in mind here.<\/p>\n<h3 id=\"what-counts-as-an-lcp-element\">What Counts as an LCP Element<\/h3>\n<p>The types of elements on a web page considered by Lighthouse for LCP are:<\/p>\n<ul>\n<li><code>&lt;img&gt;<\/code> elements,<\/li>\n<li><code>&lt;image&gt;<\/code> elements inside an <code>&lt;svg&gt;<\/code> element,<\/li>\n<li><code>&lt;video&gt;<\/code> elements,<\/li>\n<li>An element with a background image loaded using the <code>url()<\/code> function, (and not a CSS gradient), and<\/li>\n<li>Block-level elements containing text nodes or other inline-level text elements.<\/li>\n<\/ul>\n<p>The following elements are <em>excluded<\/em> from LCP consideration due to the likelihood they do not contain useful content:<\/p>\n<ul>\n<li>Elements with zero opacity (invisible to the user),<\/li>\n<li>Elements that cover the full viewport (likely to be background elements), and<\/li>\n<li>Placeholder images or other images with low entropy (i.e., low informational content, such as a solid-colored image).<\/li>\n<\/ul>\n<p>However, the notion of an image or text element being useful is completely subjective in this case and generally out of the realm of what machine code can reliably determine. For example, <a href=\"https:\/\/hacking-lighthouse.netlify.app\/lcp\/\">I built a page<\/a> containing nothing but a <code>&lt;h1&gt;<\/code> element where, after 10 seconds, JavaScript inserts more descriptive text into the DOM and hides the <code>&lt;h1&gt;<\/code> element.<\/p>\n<p>Lighthouse considers the heading element to be the LCP element in this experiment. At this point, the page load timeline has finished, but the page\u2019s main content has <em>not<\/em> loaded, even though Lighthouse thinks it is <em>likely<\/em> to have loaded within those 10 seconds. Lighthouse still awards us with a perfect score of 100 even if the heading is replaced by a single punctuation mark, such as a full stop, which is even <em>less useful<\/em>.<\/p>\n<p>This test suggests that if you need to load page content via client-side JavaScript, we\u2018ll want to avoid displaying a skeleton loader screen since that requires loading more elements on the page. And since we know the process will take some time &mdash; and that we can offload the network request from the main thread to a web worker so it won\u2019t affect the TBT &mdash; we can use some arbitrary \u201csplash screen\u201d that contains a minimal viable LCP element (for better FCP scoring). This way, we\u2019re giving Lighthouse the <em>impression<\/em> that the page is useful to users quicker than it actually is.<\/p>\n<p>All we need to do is include a valid LCP element that contains something that counts as the FCP. While I would never recommend loading your main page content via client-side JavaScript in 2024 (serve static HTML from a CDN instead or build as much of the page as you can on a server), I would definitely not recommend this \u201chack\u201d for a good user experience, regardless of what the Lighthouse performance score tells you. This approach also won\u2019t earn you any favors with search engines indexing your site, as the robots are unable to discover the main content while it is absent from the DOM.<\/p>\n<p>I also tried this experiment with a variety of random images representing the LCP to make the page even less useful. But given that I used small file sizes &mdash; made smaller and converted into \u201cnext-gen\u201d image formats using a third-party image API to help with page load speed &mdash; it seemed that Lighthouse interpreted the elements as \u201cplaceholder images\u201d or images with \u201clow entropy\u201d. As a result, those images were disqualified as LCP elements, which is a good thing and makes the LCP slightly less hackable.<\/p>\n<p>View <a href=\"https:\/\/hacking-lighthouse.netlify.app\/lcp\/\">the demo page<\/a> and use Chromium DevTools in an incognito window to see the results yourself.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/3-non-useful-page-scored-100-lighthouse-performance.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"461\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/3-non-useful-page-scored-100-lighthouse-performance.png\" alt=\"In-browser proof that the non-useful page scored 100 on Lighthouse performance\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/3-non-useful-page-scored-100-lighthouse-performance.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>This hack, however, probably won\u2019t hold up in many other use cases. Discord, for example, uses the \u201csplash screen\u201d approach when you hard-refresh the app in the browser, and it receives a sad 29 performance score.<\/p>\n<p>Compared to my DOM-injected demo, the LCP element was calculated as some content behind the splash screen rather than elements contained within the splash screen content itself, given there were one or more large images in the focussed text channel I tested on. One could argue that Lighthouse scores are less important for apps that are behind authentication anyway: they don\u2019t need to be indexed by search engines.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/4-lighthouse-score-29.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"461\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/4-lighthouse-score-29.png\" alt=\"Lighthouse screenshot of a score of 29 next to a blurred-out Discord server channel.\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/4-lighthouse-score-29.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>There are likely many other situations where apps serve user-generated content and you might be unable to control the LCP element entirely, particularly regarding images.<\/p>\n<p>For example, if you can control the sizes of all the images on your web pages, you might be able to take advantage of an interesting hack or \u201coptimization\u201d (in <em>very<\/em> large quotes) to arbitrarily game the system, as was the case of RentPath. In 2021, developers at RentPath managed to <a href=\"https:\/\/blog.rentpathcode.com\/we-increased-our-lighthouse-score-by-17-points-by-making-our-images-larger-83f60b33a942\">improve their Lighthouse performance score by 17 points<\/a> when <em>increasing<\/em> the size of image thumbnails on a web page. They convinced Lighthouse to calculate the LCP element as one of the larger thumbnails instead of a Google Map tile on the page, which takes considerably longer to load via JavaScript.<\/p>\n<p>The bottom line is that you can gain higher Lighthouse performance scores if you are aware of your LCP element and in control of it, whether that\u2019s through a hack like RentPath\u2019s or mine or a real-deal improvement. That being said, whilst I\u2019ve described the splash screen approach as a hack in this post, that doesn\u2019t mean this type of experience couldn\u2019t offer a purposeful and joyful experience. Performance and user experience are about understanding what\u2019s happening during page load, and it\u2019s also about intent.<\/p>\n<h2 id=\"how-to-hack-cls-scores\">How to Hack CLS Scores<\/h2>\n<p><strong>TL;DR: Defer loading content that causes layout shifts until the Lighthouse test has<\/strong> <strong><em>likely<\/em><\/strong> <strong>finished to make the test think it has enough data. CSS transforms do not negatively impact CLS, except if used in conjunction with new elements added to the DOM.<\/strong><\/p>\n<p>CLS is measured on a decimal scale; a good score is less than 0.1, and a poor score is greater than 0.25. Lighthouse calculates CLS from the largest burst of unexpected layout shifts that occur during a user\u2019s time on the page based on a combination of the viewport size and the movement of unstable elements in the viewport between two rendered frames. Smaller one-off instances of layout shift may be inconsequential, but a bunch of layout shifts happening one after the other will negatively impact your score.<\/p>\n<p>If you know your page contains annoying layout shifts on load, you can defer them until after the page load event has been completed, thus fooling Lighthouse into thinking there is no CLS. <a href=\"https:\/\/hacking-lighthouse.netlify.app\/cls-bad\/\">This demo page I created<\/a>, for example, earns a CLS score of 0.143 even though JavaScript immediately starts adding new text elements to the page, shifting the original content up. By pausing the JavaScript that adds new nodes to the DOM by an arbitrary five seconds with a <code>setTimeout()<\/code>, Lighthouse doesn\u2019t capture the CLS that takes place.<\/p>\n<p><a href=\"https:\/\/hacking-lighthouse.netlify.app\/cls-hacked\/\">This other demo page<\/a> earns a performance score of 100, even though it is arguably less useful and useable than the last page given that the added elements pop in <em>seemingly<\/em> at random without any user interaction.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/5-lighthouse-performance-score-100-second-test.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"516\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/5-lighthouse-performance-score-100-second-test.png\" alt=\"Lighthouse performance score of 100 following the second test.\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/5-lighthouse-performance-score-100-second-test.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Whilst it is possible to defer layout shift events for a page load test, this hack definitely won\u2019t work for field data and user experience over time (which is a more important focal point, as we discussed earlier). If we perform a \u201ctime span\u201d test in Lighthouse on the page with deferred layout shifts, Lighthouse will correctly report a non-green CLS score of around 0.186.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/6-timespan-test.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"516\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/6-timespan-test.png\" alt=\"Screenshot of a timespan test performed on the same page with layout shifts.\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/6-timespan-test.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>If you do want to intentionally create a chaotic experience similar to the demo, you can use CSS animations and transforms to more purposefully pop the content into view on the page. In <a href=\"https:\/\/web.dev\/articles\/cls\">Google\u2019s guide to CLS<\/a>, they state that \u201ccontent that moves gradually and naturally from one position to another can often help the user better understand what\u2019s going on and guide them between state changes\u201d &mdash; again, highlighting the importance of user experience in context.<\/p>\n<p>On <a href=\"https:\/\/hacking-lighthouse.netlify.app\/cls-animated\/\">this next demo page<\/a>, I\u2019m using CSS <code>transform<\/code> to <code>scale()<\/code> the text elements from <code>0<\/code> to <code>1<\/code> and move them around the page. The transforms fail to trigger CLS because the text nodes are already in the DOM when the page loads. That said, I did observe in my testing that if the text nodes are added to the DOM programmatically after the page loads via JavaScript and <em>then<\/em> animated, Lighthouse will indeed detect CLS and score things accordingly.<\/p>\n<h2 id=\"you-can-t-hack-a-speed-index-score\">You Can\u2019t Hack a Speed Index Score<\/h2>\n<p>The Speed Index score is based on the visual progress of the page as it loads. The quicker your content loads nearer the beginning of the page load timeline, the better.<\/p>\n<p>It is possible to do some hack to trick the Speed Index into thinking a page load timeline is <em>slower<\/em> than it is. Conversely, there\u2019s no real way to \u201cfake\u201d loading content faster than it does. The only way to make your Speed Index score better is to optimize your web page for loading as much of the page as possible, as soon as possible. Whilst not entirely realistic in the web landscape of 2024 (mainly because it would put designers out of a job), you could go all-in to lower your Speed Index as much as possible by:<\/p>\n<ul>\n<li>Delivering static HTML web pages only (no server-side rendering) straight from a CDN,<\/li>\n<li>Avoiding images on the page,<\/li>\n<li>Minimizing or eliminating CSS, and<\/li>\n<li>Preventing JavaScript or any external dependencies from loading.<\/li>\n<\/ul>\n<h2 id=\"you-also-can-t-really-hack-a-tbt-score\">You Also Can\u2019t (Really) Hack A TBT Score<\/h2>\n<p>TBT measures the total time after the FCP where the main thread was blocked by JavaScript tasks for long enough to prevent responses to user input. A good TBT score is anything lower than 200ms.<\/p>\n<p>JavaScript-heavy web applications (such as single-page applications) that perform complex state calculations and DOM manipulation on the client on page load (rather than on the server before sending rendered HTML) are prone to suffering poor TBT scores. In this case, you could probably hack your TBT score by deferring all JavaScript until after the Lighthouse test has finished. That said, you\u2019d need to provide some kind of placeholder content or loading screen to satisfy the FCP and LCP and to inform users that something will happen <em>at some point<\/em>. Plus, you\u2019d have to go to extra lengths to hack around the front-end framework you\u2019re using. (You don\u2019t want to load a placeholder page that, at some point in the page load timeline, loads a separate React app after an arbitrary amount of time!)<\/p>\n<p>What\u2019s interesting is that while we\u2019re still doing all sorts of fancy things with JavaScript in the client, advances in the modern web ecosystem are helping us all reduce the probability of a less-than-stellar TBT score. Many front-end frameworks, in partnership with modern hosting providers, are capable of rendering pages and processing complex logic on demand without any client-side JavaScript. While eliminating JavaScript on the client is not the goal, we certainly have a lot of options to use a lot <em>less<\/em> of it, thus minimizing the risk of doing too much computation on the main thread on page load.<\/p>\n<h2 id=\"bottom-line-lighthouse-is-still-just-a-rough-guide\">Bottom Line: Lighthouse Is Still Just A Rough Guide<\/h2>\n<p>Google Lighthouse can\u2019t detect everything that\u2019s wrong with a particular website. Whilst Lighthouse performance scores prioritize page usability in terms of responding to user input, it still can\u2019t detect every terrible usability or accessibility issue in 2024.<\/p>\n<p>In 2019, Manuel Matuzovi\u0107 <a href=\"https:\/\/www.matuzo.at\/blog\/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score\/\">published an experiment<\/a> where he intentionally created a terrible page that Lighthouse thought was pretty great. I hypothesized that five years later, Lighthouse might do better; but it doesn\u2019t.<\/p>\n<p>On this final <a href=\"https:\/\/hacking-lighthouse.netlify.app\/unusable\/\">demo page<\/a> I put together, input events are disabled by CSS and JavaScript, making the page technically unresponsive to user input. After five seconds, JavaScript flips a switch and allows you to click the button. The page still scores 100 for both performance <em>and<\/em> accessibility.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/7-lighthouse-perfect-performance-useless-inaccessible-page.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"461\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/7-lighthouse-perfect-performance-useless-inaccessible-page.png\" alt=\"Lighthouse showing perfect performance and accessibility scores for a useless, inaccessible page.\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/how-hack-google-lighthouse-scores-2024\/7-lighthouse-perfect-performance-useless-inaccessible-page.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>You really can\u2019t rely on Lighthouse as a substitute for usability testing and common sense.<\/p>\n<h2 id=\"some-more-silly-hacks\">Some More Silly Hacks<\/h2>\n<p>As with everything in life, there\u2019s always a way to game the system. Here are some more tried and tested guaranteed hacks to make sure your Lighthouse performance score artificially knocks everyone else\u2019s out of the park:<\/p>\n<ul>\n<li>Only run Lighthouse tests using the fastest and highest-spec hardware.<\/li>\n<li>Make sure your internet connection is the fastest it can be; relocate if you need to.<\/li>\n<li>Never use field data, only lab data, collected using the aforementioned fastest and highest-spec hardware and super-speed internet connection.<\/li>\n<li>Rerun the tests in the lab using different conditions and all the special code hacks I described in this post until you get the result(s) you want to impress your friends, colleagues, and random people on the internet.<\/li>\n<\/ul>\n<p><strong>Note<\/strong>: <em>The best way to learn about web performance and how to optimize your websites is to do the complete opposite of everything we\u2019ve covered in this article all of the time. And finally, to seriously level up your performance skills, <a href=\"https:\/\/sentry.io\/for\/performance\/?utm_source=smashingmag&amp;utm_medium=paid-community&amp;utm_campaign=perf-fy25q2-evergreen&amp;utm_content=blog-lighthouseblog-signup\">use an application monitoring tool like Sentry<\/a>. Think of Lighthouse as the canary and Sentry as the real-deal production-data-capturing, lean, mean, <a href=\"https:\/\/docs.sentry.io\/product\/performance\/web-vitals\/?utm_source=smashingmag&amp;utm_medium=paid-community&amp;utm_campaign=perf-fy25q2-evergreen&amp;utm_content=blog-lighthouseblog-signup\">web vitals<\/a> machine.<\/em><\/p>\n<p>And finally-finally, <a href=\"https:\/\/hacking-lighthouse.netlify.app\/\">here\u2019s the link to the full demo site<\/a> for educational purposes.<\/p>\n<div class=\"signature\">\n  <img decoding=\"async\" src=\"https:\/\/www.smashingmagazine.com\/images\/logo\/logo--red.png\" alt=\"Smashing Editorial\" width=\"35\" height=\"46\" loading=\"lazy\" \/><br \/>\n  <span>(gg, yk, il)<\/span>\n<\/div>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>How To Hack Your Google Lighthouse Scores In 2024 How To Hack Your Google Lighthouse Scores In 2024 Salma Alam-Naylor 2024-06-11T18:00:00+00:00 2024-08-30T10:05:08+00:00 This article is sponsored by Sentry.io Google Lighthouse has been one of the most effective ways to gamify and promote web page performance among developers. Using Lighthouse, we can assess web pages based [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":487,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"class_list":["post-485","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-performance"],"_links":{"self":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts\/485"}],"collection":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/comments?post=485"}],"version-history":[{"count":2,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts\/485\/revisions"}],"predecessor-version":[{"id":488,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts\/485\/revisions\/488"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/media\/487"}],"wp:attachment":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/media?parent=485"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/categories?post=485"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/tags?post=485"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}