How we improved the Lighthouse score of our landing page to 96.

We recently optimized the hell out of our Lighthouse score, and one of our landing pages went from a low 70s score to a cool 96 and above score. Below I describe what started as a quick lunch break peek into the Google Search Console — maybe some of it will help you optimize your own page!

Page Performance with Google Lighthouse

Let’s dive in:

Houston, we have a problem! Some problems became very evident:

  1. Some key requests are blocking the page rendering for at least 550 ms.
  2. The network payload is pretty big, with more than 2.5 Mb of mostly images, CSS, and JS.
  3. We are delivering images as PNGs and might benefit from using a next-gen format.

Preload fonts & allow for swapping swap

First, we made sure to preload the fonts by adding preload-statements to our HTML-head:

Please note that you need to include ‘crossorigin’ if you want to preload fonts.

The crossorigin attribute indicates whether the resource should be fetched with a CORS request as the font may come from a different domain. Without this attribute, the preloaded font is ignored by the browser.

Find more here:

Second, we introduced a ‘font-display: swap;’ to the font-face definition in our SCSS files. This enables the browser to use a fallback font and display the text before our custom fonts are loaded. The fonts get swapped afterwards. Essentially, this allows faster rendering and not getting blocked by font downloads.

Image compression with IMGBot

Luckily we found a neat little tool that promised to optimize our images without losing quality: Imgbot. Too good to be true? No, it worked! Imgbot reduced our file size by 28% and some of the most used pictures by more than 50% just by applying a lossless encoding. See below..

Image to WebP and the picture tag

brew install webp

Afterward, I used this command with a for-loop to convert all existing png-images to WebP. You can do the same with jpg images by replacing the ‘png’ with ‘jpg’ in the command below.

for i in *.png; do cwebp -q 90 $i -o "${i%.*}.webp"; done

WebP is supported by Chromium and other major browsers but unfortunately not by Safari, but the <picture> HTML tag helps luckily to workaround this:

Browsers knowing the picture tag will select the best image for them, and all other browsers will ignore the tag and work with the img-tag.

Converting the images to WebP decreased our already optimized image sizes by another fantastic 37%!

Lazy loading of images

Browsers get smarter, and with that, browser-level lazy loading landed this year. Chromium-powered browsers and Firefox support it. The implementation for WebKit (Safari) is in progress. Read more here: Browser-level image lazy-loading for the web

Chromium powered browsers run on at least 77% of all desktop computers. That led us to the decision to use <img loading=lazy> for most of the images. This will get interpreted by the browsers supporting this tag; all others will ignore it and act as before.

<img loading="lazy" class="rounded" src="/alternative/home-dashboard@2x.png" alt="Alternative to Pingdom" />

Optimize CSS with purge and minify

We used PurgeCSS, a tool to remove unused CSS. It can run in your deployment workflow. We utilize gulp to build and deploy our website code. Gulp-purgecss is an NPM module that integrates PurgeCSS as a build step in your pipeline by simply adding the following commands to the gulpfile.

PurgeCSS was able to decrease our CSS files by more than 80%.

The next logical step was to apply ‘minification,’ another common optimization, by adding another step to our pipeline. Clean-CSS takes the well-formed CSS code and removes the spacing, indentation, newlines, and comments. These elements are not required by the browsers and use extra storage that needs to get transferred.

Lazyload Intercom

It turns out that there is a way to load Intercom lazily. We can do so by delaying the load of the Intercom-widget until there is a scroll event. We did so by amending the JS-snippet to this:

Other optimizations


96! We have invested eight hours in improving our landing page’s performance and, as a side effect, made a lot faster. It’s obvious to us that there are more improvements to make.

The next weeks will tell if the above will sky-rocket our Google-search ranking.


banner image: “Louisbourg Lighthouse”. Dennis Jarvis from Halifax, Canada, 2008. CC

This article originally appeared on

Originally published at on November 17, 2020.

Head of Developer Relations @ Checkly, core contributor.