Fragen? Antworten! Siehe auch: Alternativlos
gatling komprimiert nichts, aber wenn man nach foo.html fragt, und man kann Brotli, und da liegt foo.html.br, dann kriegt man das ausgeliefert. Es kostet also nicht viel, auch kurz nach foo.html.zst zu gucken.
Ich habe das also kurz gemacht. Nota bene: Die Browser, die jetzt zstd können, können auch alle brotli.
Stellt sich raus: brotli komprimiert in eigentlich allen Fällen besser. Das liegt vor allem daran, dass Brotli bescheißt, und mit einem Dictionary an bekannten Wörtern kommt, die aus typischen HTML- und Javascript-Dateien extrahiert wurden.
Das könnte man mit zstd natürlich auch machen. Machen die Browser das? Wüsste ich gerade nicht. Wenn doch, könnte ich meine Dateien natürlich auch mit einem shared dictionary ala brotli zstd-komprimieren.
Ist zstd damit nutzlos? Nein, bei weitem nicht. Wenn man dynamische Daten ausgibt, wie es beispielsweise mein Blog tut, dann kann ich die ja nicht vorkomprimiert ins Dateisystem legen. Also könnte ich vielleicht doch partiell, wenn ich ein bisschen trickse. Mache ich aber nicht.
Jedenfalls: Für mein Blog würde es Sinn ergeben, zstd zu unterstützen. Da mache ich im Moment nur gzip, und das auch nur bei einer relativ kleinen Kompressionsstufe. Da würde sich zstd wahrscheinlich lohnen, weil es vergleichsweise rattenschnell komprimieren kann.
Das ist jetzt jedenfalls ein bisschen antiklimaktisch und ich werde auf die Erkenntnis mal reagieren, indem ich einfach nur zstd-Dateien hinlege, wenn die kleiner als die Brotli-Version sind.
Update: Das Blog kann jetzt zstd. Das hat die Größe des Binaries direkt verdoppelt. Lohnt sich hoffentlich in der Praxis.