Lighthouse flagging HLS video chunks as text content

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

https://hls-js.netlify.app/demo/?src=https://hls.enniscdn.net/ded3f0fb-0721-49bb-b761-2123d7be9ed7/master.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==

What happened?

When running Lighthouse on a page with an embedded HLS video, the video chunks are incorrectly flagged as “text content”. This seems false, especially as the chunks come back with Content-Type: application/octet-stream.

They’re also flagged as “enormous payloads”. Are there any docs pointing to how best to chunk up video for playback? HLS/DASH seems best practise at the moment.

What did you expect?

For Lighthouse not to interpret video chunks as text content.

What have you tried?

No response

How were you running Lighthouse?

Chrome DevTools

Lighthouse Version

9.6.1

Chrome Version

Chromium: 103.0.5060.114 (arm64)

Node Version

No response

OS

macOS

Relevant log output

No response

[connorjclark]

Would need to add application/octet-stream here:

https://github.com/GoogleChrome/lighthouse/blob/c31a92a2224b8d491f22a95278f1b7a4f87acdc3/core/gather/gatherers/dobetterweb/response-compression.js#L30

---

Although, we may want to rethink this audit. Why only text? Sure, many binary files are already compressed, but the one in the provided example clearly isn’t - the page could be serving 25% of the bytes it currently is for these resources.

Maybe the ResponseGatherer should only skip the expensive “will it gzip” check for formats that are known to always be compressed, and this audit should be renamed to not single out only text.

[connorjclark]

Is is standard to encode video files like this that are meant to be served over the web? We don’t have experience here with video specific web performance tuning, so we’ll have to investigate, but at a first glance it seems that the level of compression applied is just too low to be a reasonable thing to serve over a web connection.

how do I avoid the “enourmous payload” warning and score penalty?

FYI, the only thing that impacts scores is the actual metrics. This is just an educated guess on how to move that needle. We could delete the audit entirely and the score wouldn’t change.