How I Improved Lighthouse Performance by Adding an Image
Tags: react, webdev, performance, javascript
Published: 2022-08-21 15:43:54


Images and videos are slow to load, and most bloggers and companies are eventually coming to the tough decision of whether to take the UI train and include a hero image or going for performance and wave goodbye to the hero. My turn for [my website](https://www.perssondennis.com/) was to go both ways!

## In This Article

1. [The Impact of Loading Images](#the-impact-of-loading-images)
1. [Web Vitals - Largest Contentful Paint](#web-vitals-largest-contentful-paint)
1. [The Inconsistency of Getting a Great Largest Contentful Paint (LCP) Score](#the-inconsistency-of-getting-a-great-largest-contentful-paint-lcp-score)
1. [How I Optimized Largest Contentful Paint (LCP) With an Image](#how-i-optimized-largest-contentful-paint-lcp-with-an-image)
1. [Choosing Between SVG, PNG and WebP](#choosing-between-svg-png-and-webp)
1. [An Attempt to Use a SVG and CSS Solution](#an-attempt-to-use-a-svg-and-css-solution)
1. [Optimizing WebP Image Size](#optimizing-webp-image-size)
1. [Serving Appropriately Sized Images](#serving-appropriately-sized-images)
1. [Great Image Tools To Use](#great-image-tools-to-use)
1. [Back To Network Latency](#back-to-network-latency)
1. [Conclusion](#conclusion)

## The Impact of Loading Images

An image is on average a thousand times as destructive for performance as a thousand words. That's not a joke. Websites are commonly encoded using UTF-8, which uses 1-4 bytes per character, just 1 byte for standard ASCII letters. Average English word is about 5 characters, so a thousand words would be about 5 kB large. A quick google search on [average image sizes on web](https://www.pingdom.com/blog/new-facts-and-figures-about-image-format-use-on-websites/) tells us that's in about the same order of magnitude as those 5 kB of words.

Keep in mind that's just an average number. Hero and banner images which are meant to cover the half or full viewport of a website is most often at least several 100 times as large as that, maybe even a thousand if poorly optimized.

The image size isn't the only time thief when loading images on web. Images are usually fetched by the browser in a separate network request which means there will be an additional server request which incur additional latency, and the request may even have to be queued for a time by the browser. As we will see later in this article, this fact can have a considerable impact.

![Tesla's banner image model 3](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/tesla-banner-image-model-3.webp)
_Tesla's 1.2 MB huge monster banner_

As an example, [Tesla's](https://www.tesla.com/) banner image of their Model 3 Tesla is 1.2 MB large and takes 364 ms to load after having waited 2 seconds to start download on my network with a fairly old MacBook Pro. According to Google, [53 % of users will leave a mobile site that takes longer than 3 seconds to load](https://support.google.com/google-ads/answer/9147021?hl=en). Just loading the image consumes a considerable share of that quota, and before it is finished rendered it has passed that time.

![Tesla timing in Chrome inspector](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/tesla-image-timing.webp)
_Tesla Model 3 image loading time in Chrome inspector_

![Tesla image takes over 3 seconds to render](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/tesla-image-rendering-time.webp)
_Tesla Model 3 accelerates from 0 to 100 km/h in 3.3 s, that's faster than it takes to load the image of it_

## Web Vitals - Largest Contentful Paint

There are many ways measuring performance for a website. Google has initiated [Web Vitals](https://web.dev/vitals/), which is a bunch of metrics that Google think are important for serving a good UX. One of the metrics is [Largest Contentful Paint (LCP)](https://web.dev/lighthouse-largest-contentful-paint/), which measures the time until the largest text or image on the page is visible.

Google has released an open-source tool called [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/) that can be used to measure web vitals and get scores and guidelines. It is built-in into Chrome Dev Tools but can also be used at [PageSpeed Insights](https://pagespeed.web.dev/). The metrics shown is meant to be used as a guidance and can vary between each test.

Although Lighthouse is just for guidance, most or all of the metrics are used directly or indirectly by Google to rank your website when it gets indexed by Google. It's therefore not only important for good UX, but also for [SEO](https://moz.com/learn/seo/what-is-seo).

![Largest contentful paint score](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/largest-contentful-page-tesla-score.webp)
_Largest contentful paint is one of the metrics a Lighthouse test scores you on_

## The Inconsistency of Getting a Great Largest Contentful Paint (LCP) Score

While running Lighthouse speed tests at my website, I noticed that I got very different scores on different pages. My [main page that lists articles](https://www.perssondennis.com/) and an [article page](https://www.perssondennis.com/articles/how-to-report-a-site-that-steals-your-articles) scored significantly different on the performance metric, even though both pages was built almost in the same way with a profile picture, a lot of text and a few images. At the time doing this, the pages looked similar as today, but they did not have a hero image back then.

The culprit for the bad test result on the article page was the LCP score. The Lighthouse test provides a screenshot of the LCP, which made it clear why the article page did get a worse LCP score.

Since the main page had some extra chip components beneath the profile picture, the largest contentful paint on that page was the profile image. None of the dynamic blog articles was ever included in the viewport on a mobile device.

![Largest contentful paint on my landing page](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/largest-contentful-paint-on-my-landing-page.webp)
_The LCP on my landing page is the profile picture_

Meanwhile, on the article page, the first part of the blog article was included in the mobile viewport, meaning that Lighthouse was looking for the LCP in that area as well. The consequence, was that whenever an article began with an image, that image was treated as the LCP, since it was a larger image than my profile picture. If the image was left out, the profile picture was detected as the LCP.

![Largest contentful paint on an article page](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/largest-contentful-paint-on-an-article-page.webp)
_The LCP on an article page with an image was the article image_

## How I Optimized Largest Contentful Paint (LCP) With an Image

I knew I couldn't keep going on with an unreliable LCP score, and it wasn't a good solution to never start an article with an image. I had to find a way to get a predictable score regardless of what content I included in the article itself.

With that in mind, I decided to add an image larger than any potential article image, I decided to add a hero image. That way, I could at least get control of which image was the largest and thereby take control over the LCP score.

For this to be effective, I had to use a hero image that was fast to load. Nothing would ever be better if I did like Tesla have done, adding a gigantic banner at the size of 1.2 MB. I had to use a small optimized image that could fill half the viewport, one that didn't scream poor resolution.

![LCP on article page with a hero image](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/lcp-on-article-page-with-hero-image.webp)
_By adding a hero image, I could control which image I wanted to be the LCP_

### Choosing Between SVG, PNG and WebP

Well, I never really considered using a PNG image for the hero image, that's not the way to optimize web images. Although, I do always keep a PNG copy around for other usages. For example, when posting articles on DEV forum, they don't support WebP images to be uploaded as hero images.

Choosing between SVG and WebP was more difficult. SVG images can be really small if the image consists of a repeating pattern or an abstract pattern using only a few colors and shapes, just because they consist of vectors that can be scaled to any resolution. On the other hand, they will grow ridiculously big for graphic-heavy images with many colors and shadows, due to the high number of vectors required to represent the image.

On the contrary, WebP can compress images effectively by [predicting and reusing pixels](https://developers.google.com/speed/webp), making it superior to PNG and JPEG formats. So, the decision had to be between a minimal abstract hero image in SVG format or a realistic photograph in WebP format.

### An Attempt to Use a SVG and CSS Solution

As you can see on my [website](https://www.perssondennis.com/), I do have a brick wall as the hero image (as long as you don't change the theme to dark mode). That image is in WebP format, but my first attempt was actually to use an SVG image. The brick wall I tried with then was less realistic and more cartoonish, which was served perfectly in SVG format.

To get rid of the extra network latency from fetching an image from a server, I [embedded the image as a CSS background in a data URI](https://www.svgbackgrounds.com/how-to-add-svgs-with-css-background-image/), which should really only be done when dealing with tiny images because of cache and parsing reasons.

Did it work? No, it didn't, the CSS background wasn't detected as the LCP. After all, it is neither a regular image or a text, so it complies with [Google's description of LCP](https://web.dev/lighthouse-largest-contentful-paint/).

![Largest contentful paint](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/largest-contentful-paint.webp)
_Google's largest contentful paint definition_

Even though a CSS solution did not work as expected, it did work to use the SVG image in a normal HTML image element (or to be accurate, Next.js Image component in my case). The only reason I discarded that solution was because I wasn't satisfied with the cartoonish style of the brick wall, I felt I wanted a more realistic brick wall.

## Optimizing WebP Image Size

After having decided to use a photograph of a brick wall as the hero image, it was time to optimize the size of it without losing too much quality. I felt that I didn't need a pixel-perfect photograph, it was fine for me to sacrifice quality for loading speed. The initial image was a JPEG monster at 18.1 MB and a 6000 x 4000 resolution, so it could be optimized a lot.

![18 mega bites pun](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/18-mega-bites-pun-meme.webp)
_My counsellor apologize on my behalf for a mega bad pun_

Now, compressing images is not at all what I am good at, I'm sure compression fanatics would have hit me with their compression bible if they hadn't already compressed it into a holy script at a few kilobytes. But I did succeed to compress the image a lot, compressing it into a 2560 x 1707 WebP image of 37 kB. Obviously, I lost a massive amount of quality, that has to be mentioned.

![.rar picture of a compression fanatic](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/rar-picture-of-a-compression-fanatic-meme.webp)
_I got so scared seeing him I zipped my mouth_

The approach I used to compress my image was to use an online copy of Photoshop called [Photopea](https://www.photopea.com/). Only thing I did was to resize the image and save it in another format, and choosing to lower the quality while saving.

![Photopea save dialog](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/photopea-save-dialog.webp)
_Photopea's save dialog allows you to preview image quality and image size at the same time_

## Serving Appropriately Sized Images

A hero image with a 2K resolution is fine for a 4K monitor, but serving a 2K image to a mobile device is not optimal. Small devices should be served small images. That can be achieved using a [HTML picture element with a srcset](https://www.w3schools.com/tags/att_source_srcset.asp).

In my case, I didn't have to handle that, because my website is written using Next.js. They have a built-in image component which can be used to optimize image loading. At my blog, you can find a guide for [implementing a hero image with that image component](/articles/how-to-make-a-hero-image-in-nextjs), it also explains the benefits of using it.

The image component Next.js offer does not only serve images in different sizes. They also support specifying a quality of the image so they can compress it for you. In my case, it didn't compress the image enough, I experienced better results compressing it myself using Photopea.

## Great Image Tools To Use

When working with images, you often have to manipulate images in certain ways. To easier do that, I suggest checking out [my list of free image tools](https://dev.to/perssondennis/list-of-free-image-tools-every-frontend-developer-needs-489a). Those tools can be used to resize and reformat images and to generate images and backgrounds. It also presents websites which offers royalty free images.

## Back To Network Latency

As I promised in the beginning of this article, we would look at how network requests can be the bottleneck when optmizing image loading times. Look at the picture below. It shows the network timing tab available in Chrome Dev Tools for the hero picture I use on my website. We can see that it takes the same amount of time to get a response from the server as it takes to download the picture.

![Cached server response time](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/cached-server-response-time.webp)
_It takes 32 ms to get a response when I visit my own website_

But Dennis, you say, your image is very small, only 37 kB. 32 ms isn't a very long time. Yeah, that's correct. It's nothing to care about. Or at least it wouldn't be if it wasn't because I had reloaded my page multiple times to get that screenshot.

Reloading the page allows for the server to cache the image and serve it quickly the next time it is requested. When visiting my website during a cold boot at hours I don't have a lot of traffic to the site from Sweden, it can take 5, 10 or maybe 15 times as long time to get a response from the server. When that happens, the 32 ms download time for the image is negligible compared to the server response time.

![Server response time](https://www.perssondennis.com/images/articles/how-i-improved-lighthouse-performance-by-adding-an-image/server-response-time.webp)
_Without a recent cache of the hero image, server response takes plenty of more time_

## Conclusion

What we learned in this article was that adding a large image to a website can actually improve Lighthouse performance tests. We learned what Largest Contentful Paint (LCP) is and how to optimize an image to maximize the LCP score.

We also took a look at when to use SVG images and when to use WebP images. I provided you with a [list of free image tools](/articles/list-of-free-image-tools-every-frontend-developer-needs) which as an example can be used to reformat images in different ways, and explained the importance of keeping the image size low when using images on a website.

Finally, we saw an example of how server response time can be the bottleneck of web image performance when the images themselves has been compressed well enough to be very small.

_&nbsp; {% embed https://dev.to/perssondennis %}_