[Bug] Http-compression of small files

[ghost]

No description provided.

[molant]

Hello @gottfridsberg,

can you please provide more information about what issue are you experiencing with http-compression (hopefully with a URL we can reproduce on our end)?

[ghost]

Sorry for the incomplete (missing) bug repport. The tested site has a few files that are smaller than 500b, but I still get http-compression hints.

URL: https://www.tomasmoberg.org
Original file sizes: image.svg: 289 B; max-width.css: 1.32 KB; min-width.css: 1.33 KB; pwa.webmanifest: 346 B
CDN: Netlify (Brotli compression of files > 1KB)

http-compression: 6 hints

hint #1: Response should be compressed with gzip when gzip compression is requested.
https://www.tomasmoberg.org/v8/static/image.svg

hint #2: Response should be compressed with Brotli when Brotli compression is requested over HTTPS.
https://www.tomasmoberg.org/v8/static/image.svg

hint #3: Response should be compressed with Zopfli when gzip compression is requested.
https://www.tomasmoberg … static/max-width.css

hint #4: Response should be compressed with Zopfli when gzip compression is requested.
https://www.tomasmoberg … static/min-width.css

hint #5: Response should be compressed with gzip when gzip compression is requested.
https://www.tomasmoberg … static/pwa.webmanifest

hint #6: Response should be compressed with Brotli when Brotli compression is requested over HTTPS.
https://www.tomasmoberg … static/pwa.webmanifest

[ghost]

@molant, I've added some content to bug repport #4031...

[antross]

Thanks for the additional detail @gottfridsberg!

@molant - looks like hint-http-compression should consider a minimum size limit for reporting files (which should probably be configurable), agreed? We could use 1KB to align with the reported Netlify behavior, though I'd be curious if we can find any other resources discussing a recommended cutoff size.

[molant]

What do you think of changing the severity if the files are under the threshold?

I think the cutoff size depends a lot if you are using HTTP2 or not, the size of the headers, if it's the first resource from a given domain (and all the price that you need to pay for shaking and such).

From a quick search it seems:

• the average size of a TCP package is around 1500 bytes (that's the MTU on Ethernet)
• the typical size is 700-800bytes

While headers seem to take about half the size of the package, I think that rounding to 1KB the threshold seems reasonable.

[antross]

What do you think of changing the severity if the files are under the threshold?

Depends on the severity. If we're going to show anything I'd say no stronger than a "hint" - "warning" seems like too much. That said, I think I'd prefer nothing at all unless there are a lot of small, uncompressed files (though I know that's harder to account for given the way the hint is written).

[molant]

I was thinking on hint. Definitely not warning.

[sarvaje]

I have started working on this and I have just realized that IIRC, the online scanner is going to show all the issues regardless of their severities, so if we just change the severity to hint, people are still going to see the hints.
@molant @antross are we ok with that? should we just ignore the files? Maybe we can consider what @antross said about ignore them unless there are a lot of small files.

[antross]

@sarvaje I'm okay with these still appearing in the online scanner initially. I'd rather separately get that updated to correctly communicate severity as opposed to working around the limitation at the hint level.