NextJS 13 and Lighthouse report on file compression

Hi, I work on a NextJS 13 (13.4.5) App Router app that is served by Netlify. I’m working on Performance and the top critical issue we see in the Lighthouse reports is “Enable text compression”.

I’m investigating the network requests and although I can see some of the assets being served compressed, not all of them are so:

  • image (1)
  • image (2)

When I compare the requests, I see that the first one looks like some initial, pre-render response from Next, while the last is the rendered page.

First ‘pl/’ request (can’t see Response, showing Headers instead):

  • image (3)

Second ‘pl/’ request, Response is HTML:

  • image (4)

Since Lighthouse complains about the first one, I’m wondering what can be done in regards to server compression. From what I read in other threads Netlify does this automatically so it’s not something in my control? I’m wondering if this can/should be compressed since the Content-Type is ‘text/x-component’ and the Request Header includes ‘Accept-Encoding:
gzip, deflate, br, zstd’:

  • image (5)

Thanks in advance,

(note: had to join all images into a single file because new members cannot embed more than 1 asset nor upload zip files here…)

It would be a little hard to advise without knowing the site. Could you please provide the details to so we can check?

Of course!

The Netlify URL is: https://66759b600235b900082ed1fb--production-selgros24pl-selgrospl.netlify.app/pl/

I also have two additional comments:

  1. I read a comment in this forum explaining that not every resource will always be compressed when the final size would be greater than the initial size. However, in the following table I’m curious why one particular JSON (payment.json) which is 1kb was not compressed, while every other >800 B were (except thank-you.json… I was going to assume the ones below 800 B were just skipped due to the reason I just mentioned above, but the exception makes me question if this is the case)
  • image (1)
  1. Sometimes Lighthouse will also indicate an error in “Enable text compression” but it’s not clear to me why that is the case or when it happens… I can’t reproduce it consistently.
  • image (2)

Let me know if this is sufficient or if you need more info!

Best,

(note: again, had to stitch images together due to upload limitation)

@hrishikesh Hi, did you have the chance to look at the latest reply with the details? Thanks,

Checked this further and I was able to reproduce the issue in your last image where Lighthouse just saying “Enable text compression” without any further details, but anyways that’s probably a Lighouse issue. As for file compression, most of the files that I am seeing served for that site have the brotli compression applied (I checked the JS and JSON files).

But I checked our logs and I do see a lot of uncompressed responses being sent for your site. I could not fine a reaonable explanation for that behaviour, so I have asked the devs to take a look.

The devs have been checking this but there’s nothing systemic wrong that we can see for your site or the network as a whole. However, what was interesting is, there’s a chance something could be wrong with Chrome itself could be removing the response header in some cases as discussed here (stackoverflow.com).

We think that could be the issue because we compared multiple responses where the browser didn’t report any content-encoding header, but according to our logs, we served a compressed response for that. So it’s strange why the browser is reporting some responses as compressed and some as uncompressed.

Are you able to reprocuce the issue with curl or some other tool?