Issues with image compression

How to ensure things are compressed ? According to developper tools, they are not, and my lighthouse is terrible, 82, saying it’s not compressed.
The example below is for an image of 24kb.

RESPONSE HEADERS:
accept-ranges: bytes
access-control-allow-origin: *
age: 35447
cache-control: public, max-age=31556926
content-length: 24254
content-type: image/jpeg
date: Mon, 22 May 2023 15:28:10 GMT
etag: 817774f18901d7b8fde6f1db02746cddca76a34d
server: Netlify
strict-transport-security: max-age=31536000; includeSubDomains; preload
via: 1.1 25ffb5a941b5a46b102cd385a9cdbb50.cloudfront.net (CloudFront)
x-amz-cf-id: IhOIIJWqWUeOc4kXjqXHjF-Wqn-bKk5_RAM7m4OCw9x8O2o1d2GOzQ==
x-amz-cf-pop: FRA53-C1
x-cache: Hit from cloudfront
x-nf-request-id: 01H1216EDCVR5AHJT4FAS7G6JW

REQUEST HEADERS:
DNT: 1
sec-ch-ua: "Chromium";v="113", "Not-A.Brand";v="24"
sec-ch-ua-mobile: ?1
sec-ch-ua-platform: "Android"
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Mobile Safari/537.36

My config: please tell me what’s wrong. I am new to this and certainly awfully misguided.

[build]
  publish = "public"
[build.processing]
  skip_processing = false
[build.processing.css]
  bundle = true
  minify = true
[build.processing.js]
  bundle = true
  minify = true
[build.processing.images]
  compress = true
[[headers]]
  for = "/*"
  [headers.values]
    Content-Encoding = "br"

This is pretty small for an image. I don’t know how much smaller you expect to compress to. Compression only removes the unnecessary pixels from an image. If you upload a high resolution/quality image, compression will reduce by what it can but ultimately it will still be a high resolution image with a large file size.

We are here to help you with things Netlify related. Optimizing a sites lighthouse score is a specific skill outside of this scope.

However here are a few things I’d suggest:

1 Like

The lighthouse score is my goal but my wish to know how to configure the netlify server to get the compression done because it apparently is not the case.

that config was completely wrong,

[[headers]]
for = “/*”
[headers.values]
Content-Encoding = “br”

made the site wholly unavailable, with an error message on librewolf and a weird cached version from who knows where on chromium. The other lines are fine. This picture also was a bad one, this one is much bigger gif, 4.2mb.

Request URL: https://d33wubrfki0l68.cloudfront.net/a38290ce8c4f4a4fdbc4ed2a11dc3ea87d538e68/84e40/images/memes/transcendence_tranquility_hu6a45a5541c100ecb57e6befebaaf963a_3645068_400x 0_resize_q100_mitchellnetravali_1.gif
Request mode: GET
Status code: 200
Remote address: 99.84.155.55:443
Referrer URL policy: strict-origin-when-cross-origin
accept-ranges: bytes
access-control-allow-origin: *
age: 40522
cache-control: public, max-age=31556926
content-length: 4186946
content-type: picture/gif
date: Tue, 23 May 2023 00:57:40 GMT
etag: ecbf00cfa9ca05ccbd24ba4cbb8491bf7f73d36c
server: Netlify
strict-transport-security: max-age=31536000; includeSubDomains; preload
via: 1.1 468db87750f18f9c88fefdcaa2347b8a.cloudfront.net (CloudFront)
x-amz-cf-id: HHKownuFIYNF-4QIg2iO318EpBm6HAMUTrAZeQND-hYsuZJYWXyZPQ==
x-amz-cf-pop: TXL52-C1
x-cache: Hit from cloudfront
x-nf-request-id: 01H131S6ZDX6XVVJ08THQM931D
:authority:d33wubrfki0l68.cloudfront.net
:method: GET
:path: /a38290ce8c4f4a4fdbc4ed2a11dc3ea87d538e68/84e40/images/memes/transcendence_tranquility_hu6a45a5541c100ecb57e6befebaaf963a_3645068_400x0_resize_q100_mitchellnetravali_1.gif
:scheme: https
accept: image/avif,image/webp,image/apng,image/svg+xml,image/,/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
cache-control: no-cache
dnt: 1
pragma: no-cache
referer: https://national-naturalism.org/
sec-ch-ua: “Chromium”;v=“113”, “Not-A.Brand”;v=“24”
sec-ch-ua-mobile: ?1
sec-ch-ua-platform: “Android”
sec-fetch-dest: image
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Mobile Safari/537.36

So please… what should I write to just say:
compress everything with brotli and bundle everything ?
Thanks for your help…

Is this in your root? If not add it.

Adding this causes

Content Encoding Error
An error occurred during a connection to ##website_name##.

Using netlify’s domain name: https://64712ab17840e20064fe1c9f--guileless-nasturtium-7220f7.netlify.app/ I don’t even get any error, just a white screen. Pinging can resolve the domain name, but there’s no response at all.

As it will set br as the Content-Encoding on all assets, ignoring what the browser has requested.

The same happens on the real domain which I see you removed from the last post (though you have left it in a previous post.)

I’m an idiot, I know. Not that I care though.
Understood, so how do I write “only on images” (assuming that is what should happen) ?

You can’t.

Stop trying to force compression on images that are already small and don’t need additional compression. A < ~100KB image doesn’t need additional compression. It is small enough.

1 Like

you can verify yourself:
Look on this page, open the <details> at “small mammals, up to young antelopes”, and click on the middle image with the developers tools on. It will display cephalope.webp which is a whopping 5.6Mb, and there is no “content-encoding”.

That’s as small in size as the image can get at Netlify. Netlify is not a image CDN. For runtime optimization of image, take a look at other CDNs dedicated for images like Cloudinary.

5.6mb is considered small ? Then what image on Earth is considered big enough to warrant compression ? I don’t understand you. I just want to know if the behavior I’m point at is normal or not.

I didn’t say so. I said, it’s as small as it can get on Netlify. Those two sentences are very different.

If you upload a ultra-HD image and expect Netlify to resize it by maintaining the image dimensions, that’s not going to happen. In case you’ve not noticed, Netlify’s image optimization tries for lossless compression, thus, in some cases it might not even compress the image if it’s already optimised. If you want a smaller image, upload a smaller image OR use a image CDN that can resize images for you on-the-fly like I mentioned. But, if you want the image dimensions to remain unchanged, you’re at an impasse.

With that being said, i didn’t find any 5.6 MB image on your site (even after loading the details that you mentiond).

2 Likes

No, it’s a link: clicking on the cephalope’s picture will open the original, 5.6 Mb one.
Maybe just click here.
I don’t need resizing , it’s done by my SSG already, I don’t know why you mention this Though I understand what you say, my question was simply if a “content-encoding” header should be present in this case, when downloading something of that size ? If not, then from what size is deflate/gz/brotli compression even supposed to occur ?

GZIP/Brotli is for text assets since text can be compressed really well. You have a WebP image which is already a highly compressed format. Adding another layer of Brotli would not make it any smaller and rather just increase the time to serve the asset.

I tried using 7-zip compression on the image with its ultra settings and the image size did not make a meaningful difference - because the image is already highly compressed.

So to answer this part, content-encoding is applied when we know it might help - for highly compressed assets like these, it doesn’t help.

1 Like

Ah ! Ok, I understand now. Makes sense. Thanks !