How to trick Google Lighthouse

How to trick Google Lighthouse:

1 Like

Interesting article, thanks for posting. Some questions/comments:

  • How much did this technique improve the Lighthouse score vs naive static SVGs?

  • It appears the SVGs are being loaded uncompressed (unlike the HTML/CSS/JS), and they are drawn to an accuracy of 1/1000 of a pixel. Would compressing them and/or drawing less accurately allow naive static use?

First of all, these images do not count at all in the Google Lighthouse test, as the synthetic test does not detect these images. So it is as if they are not there.

Secondly, I am not sure how optimizing the SVG would improve things. The SVG’s can probably be smaller and the drawing performance can be better… but that would not influence the Google Lighthouse score.

I find your approach brilliant!

1 Like

To clarify, you’re right, the SVG images don’t count towards Lighthouse’s timing audits because your technique delays their loading. However, they do count in the network payload audit (listed as “Avoids enormous network payloads”). The site went from a ~15 KB payload to 480 KB (99% SVG):

The site still passes the payload audit because it is less than the recommended max of 1600 KB, but almost a third of that budget has been used. A new post might unnecessarily fail this audit if it had some large pictures.

Compression would get the payload down to ~180 KB, and lower-accuracy might get it to ~110 KB. That would save both you and your users bandwidth costs. Ref: https://web.dev/total-byte-weight/

Thank you!!! That is some good advice and a great analysis!

If you want to delay loading of JS, I just learnt of a service at JAMStack conference.

It is a something like slowpag.es - can’t remember the last part. You give it a script and a delay in ms and your browser will wait the duration before downloading.