Matthias Apsel: Inhalte komprimiert übertragen

Hallo alle,

mit SetOutputFilter DEFLATE lässt sich in der .htaccess die Kompression für alle Dateien einschalten. Gibt es Inhalte (insbesondere Medien), die man vielleicht besser nicht komprimiert ausliefern sollte? Vielleicht, weil ein Video erst starten kann, wenn es vollständig übertragen wurde?

Bis demnächst
Matthias

--
Rosen sind rot.

akzeptierte Antworten

  1. @@Matthias Apsel

    Gibt es Inhalte (insbesondere Medien), die man vielleicht besser nicht komprimiert ausliefern sollte?

    Alles, was schon komprimiert ist – wie Bilder (JPEG, PNG, GIF, WebP, …), Videos, Audio (MP3, …), Webfonts (WOFF2, WOFF, …) –, sollte man nicht nochmals durch eine andere Kompression jagen.

    LLAP 🖖

    --
    “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
    1. Alles, was schon komprimiert ist … sollte man nicht nochmals durch eine andere Kompression jagen.

      Stimmt. Dann sollte man nur noch erwähnen, dass Apache ausdrücklich

      AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
      

      auflistet. Ich würde noch text/json dazu setzen wollen. Hat man aber seine Inhalte sauber "verordnert", dann geht SetOutputFilter DEFLATE per Directory.

      1. Hallo Regina Schaukrug,

        AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
        

        Gibts eine zu beachtende Reihenfolge in der .htaccess?

        auflistet. Ich würde noch text/json dazu setzen wollen. Hat man aber seine Inhalte sauber "verordnert", dann geht SetOutputFilter DEFLATE per Directory.

        Hab ich. Welche Variante wäre zu empfehlen?

        Bis demnächst
        Matthias

        --
        Rosen sind rot.
        1. Gibts eine zu beachtende Reihenfolge in der .htaccess?

          Sehe ich nicht.

          Welche Variante wäre zu empfehlen?

          Tja. AddOutputFilterByType ist sicherer gegenüber Irrtümern beim "Einparken" von Dateien. SetOutputFilter per Directory könnte etwas Systemleistung sparen. Vermutlich in einem nicht mal messbaren Bereich - weil der Mime-Typ ja trotzdem fest gestellt wird. Und dann wären da noch Skripte welche auch alles mögliche mit allen möglichen Mime-Typen senden können.

          My winner is: AddOutputFilterByType.

      2. @@Regina Schaukrug

        auflistet. Ich würde noch text/json dazu setzen wollen.

        ?? “The media type for JSON text is application/json.” [RFC 8259 §11]

        Hinzu kommt noch application/ld+json.

        Für XML sollte auch eher application/xml in Gebrauch sein. Hinzu kommen noch XML-Anwendungen wie application/rdf+xml, image/svg+xml, …

        Kann man mit Wildcards arbeiten? text/*, *json, *xml?

        Hat man aber seine Inhalte sauber "verordnert"

        Die „Verordnerung“ würde ich eher inhaltlich machen. So dass zusammenwächst, was zusammengehört. Und das können Dateien unterschiedlichen Typs sein. Dateien, die nichts miteinander zu tun haben außer dass sie gleichen Typs sind, liegen in verschiedenen Ordnern. Die Dateitypen erkennt man anhand der Endung, nicht anhand des Pfads.

        LLAP 🖖

        --
        “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
        1. ?? “The media type for JSON text is application/json.” [RFC 8259 §11]

          Hinzu kommt noch application/ld+json.

          Für XML sollte auch eher application/xml in Gebrauch sein. Hinzu kommen noch XML-Anwendungen wie application/rdf+xml, image/svg+xml, …

          Damit hast Du recht.

          Kann man mit Wildcards arbeiten? text/*, *json, *xml?

          Ist nicht dokumentiert. Ein erster schneller Test ergab, dass das immerhin nicht zu einem 500er führte (in .htaccess verwendet - ob der Server mit sowas in der Konfiguration starten will weiß ich noch nicht). Allerdings wurde auch nichts komprimiert. Nichtdeszutrotz zeigt die Doku, dass man die Komprimierung auch in Abhängigkeit vom Dateiname steuern kann:

          <FilesMatch "\.(txt|csv|xml|json)$">
             AddOutputFilter deflate
          </FilesMatch>
          

          Dann geht das - aber nur für statische Dateien und man müsste ein wenig mit regulären Ausdrücken spielen.

          Bei nicht-statischen Ressourcen ist es aber womöglich sinnvoller, den Output durch das Programm (Skript) selbst zu zippen. (Da mache ich gerne). Natürlich könnte man auch mit Namen spielen (e.g. "dateiname.packDas.php") und

          <FilesMatch "\.packDas\.php$">
              AddOutputFilter deflate
          </FilesMatch>
          

          setzen. Das geht aber auch nicht immer. z.B. wenn man fertiges Zeug Dritter nachbessern will. Da hätte man allerhand zu tun.

          Hilfe, Hilfe Hilfe!

          Was mir fehlt ist eine Direktive mit der man das Packen erst ab einer bestimmten Dateigröße bestellt. Momentan "packt" der Apache z.B. 500 Bytes in 564 Bytes... Das ist Verschwendung. So und so dürfte unterhalb von 1 MTU (Mit Ethernet <-> DSL <-> Ethernet = 1492 Bytes) das Packen hyperliquid sein.

          1. Tach!

            Was mir fehlt ist eine Direktive mit der man das Packen erst ab einer bestimmten Dateigröße bestellt.

            Mit RewriteMap kannst du ein Programm/Script angeben, über das ein RewriteRule-Ziel festgelegt werden kann. Damit kannst du auf unterschiedliche Ziele routen, die die Requests unterschiedlich abhandeln.

            dedlfix.

            1. Mit RewriteMap

              (Nicht Dein) Mist. Grund: Jetzt war ich ungenau. Richtig gesagt will ich den Apache nicht unbedingt in Abhängigkeit der DATEIGRÖSSE sondern in Abhängigkeit von der Größe der ungepackten Antwort packen lassen. Die steht zu dem Zeitpunkt aber noch nicht fest.

              1. Tach!

                Mit RewriteMap

                (Nicht Dein) Mist. Grund: Jetzt war ich ungenau. Richtig gesagt will ich den Apache nicht unbedingt in Abhängigkeit der DATEIGRÖSSE sondern in Abhängigkeit von der Größe der ungepackten Antwort packen lassen.

                Die Größe von erzeugten Daten kennt der Apache nicht unbedingt, weil er sie nur häppchenweise bekommt und puffergrößenweise durchreicht. Es sei denn, man puffert sie vor dem Komplett-Senden im erzeugenden Progamm (zum Beispiel Output Buffering von PHP), aber das weiß der Apache dann meines Wissens auch nicht, ob das nur ein Schwung ist oder mehrere.

                dedlfix.

                1. Aha. Danke.

                  Dann pack ich mal weiter selbst den gepufferten Output - und zwar brav mit gzip. Da ich auch die gepackten Dateien serverseitig cache lohnt sich mehrfaches Packen für Clients (die z.B. auch brotli verstehen) wegen des Stresses/Speicherplatzes eher nicht.

  2. Hallo alle,

    mit SetOutputFilter DEFLATE lässt sich in der .htaccess die Kompression für alle Dateien einschalten. Gibt es Inhalte (insbesondere Medien), die man vielleicht besser nicht komprimiert ausliefern sollte?

    Ja. Wenn man z.B. eine Progressbar fürs Download realisieren möchte, darf die Response nicht komprimiert sein. MfG

  3. @@Matthias Apsel

    “We can use reliable things that we’ve used in the past, like gzip, but we can also go a little bit deeper… There are two new options: one of them is Zopfli, and the other one is Brotli.” —Vitaly Friedman, New Adventures in Responsive Web Design (ab 1:23)

    LLAP 🖖

    --
    “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
    1. The gzip encoding is the only one supported to ensure complete compatibility with old browser implementations. The deflate encoding is not supported, please check the zlib's documentation for a complete explanation.

      Apache 2.4 Handbuch zu mod_deflate.

      Das verlinkt unter "zlib's documentation" zu

      1. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings?

      "gzip" is the gzip format, and "deflate" is the zlib format. They should probably have called the second one "zlib" instead to avoid confusion with the raw deflate compressed data format. While the HTTP 1.1 RFC 2616 correctly points to the zlib specification in RFC 1950 for the "deflate" transfer encoding, there have been reports of servers and browsers that incorrectly produce or expect raw deflate data per the deflate specficiation in RFC 1951, most notably Microsoft. So even though the "deflate" transfer encoding using the zlib format would be the more efficient approach (and in fact exactly what the zlib format was designed for), using the "gzip" transfer encoding is probably more reliable due to an unfortunate choice of name on the part of the HTTP 1.1 authors.

      Bottom line: use the gzip format for HTTP 1.1 encoding.

      Im Hinblick auf die obige Warnung und darauf, dass womöglich einige Clients (Nicht nur ältere Browser, auch Suchmaschinen und vielleicht gewollte Bots, wg. Virenschutzes oder Inhaltsbegrenzung entpackende Proxys) mit einer Kompression a la Zopfli, Brotli und Co. noch nicht klar kommen wäre ich da derzeit noch konservativ, weil die nach meinen Prämissen gewichtete Gegenüberstellung von Aufwand, Nutzen und Risiken in Richtung "let it bee" zeigt.

      1. @@Regina Schaukrug

        Im Hinblick auf die obige Warnung und darauf, dass womöglich einige Clients … mit einer Kompression a la Zopfli, Brotli und Co. noch nicht klar kommen wäre ich da derzeit noch konservativ

        Wenn „konservativ“ heißt, Zip auszuliefern, dann ja.

        Wenn „konservativ“ heißt, nicht Brotli auszuliefern, dann nein.

        Das Zauberwort heißt: content negotiation. Clients, die Brotli verdauen können, bekommen ihr Brotli; die anderen bekommen den Fallback Zip. Eine Form von progressive enhancement.

        LLAP 🖖

        --
        “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
        1. Clients, die Brotli verdauen können, bekommen ihr Brotli;

          Derzeit nicht von mir. Begründung:

          sudo aptitude show "apache?" | grep "Paket: libapache2-mod-" | sort
          

          zeigt:

          …
          Paket: libapache2-mod-auth-tkt
          Paket: libapache2-mod-authz-securepass
          Paket: libapache2-mod-authz-unixgroup
          Paket: libapache2-mod-bw
          Paket: libapache2-mod-dacs
          Paket: libapache2-mod-defensible
          …
          

          Fazit: Das Apache-Modul brotli fehlt im Repo. Müsste in der Mitte stehen. Ebenso fehlt es in der Dokumentation der Module für den Apache 2.4, für den "trunc" taucht es zwar auf, der ist aber "development version", also nicht für den produktiven Einsatz gedacht.

          Hinzu kommt: Wenn mein Distributor libapache2-mod-brotli nicht liefern will dann hole ich mir mit der manuellen Installation aus den Quellen nämlich "nette" Pflichten an die Backe. Wie eben ein manuelles Update.

          Wie gesagt: Aufwand, Nutzen und Risiko zeigen auf "Let it bee!" - Für Experimentiersysteme oder wenn ich mal anfange mir von einer großen und tollen IT-Abteilung eigene Repos schnitzen zu lassen mag das angehen. So lange ich mich aber auf die Distributoren verlassen muss werde ich es vermeiden irgendetwas zu installieren, was eigentlich nach /opt/google/brotli/bin/ und /opt/google/brotli/lib/ gehört aber nicht dort landet.

  4. [nicht komprimieren], weil ein Video erst starten kann, wenn es vollständig übertragen wurde?

    Also zumindest gzip und de-flate packen blockweise und können blockweise entpackt werden. Aber Videos (und Sounds) sind schon heftig gepackt. Du würdest versuchen mit einer 10-Kilo-Presse etwas zu verdichten, was vorher mit einer 300-Tonnen-Presse verdichtet wurde - und das Ergebnis dann logischerweise nochmal einpacken. Das Ergebnis ist also um die weitere Verpackung größer. Außerdem muss der Empfänger mit der doppelten Verpackung zurecht kommen…