Komprimierung in Drupal 7

Ich verwende Drupal (neueste Version 7.22) unter Apache 2.2 und habe auch Varnish (Modul und Proxy) installiert. In Apache habe ich das Modul mod_deflate deaktiviert. Beim Lesen im Internet scheint es, dass die Optionen auf der Leistungsseite in Drupal (aggregiertes CSS, JS) die CSS- und JS-Dateien nicht komprimieren sollten. Beim Durchsuchen meiner Website und Überprüfen der http-Header wird jedoch "Content-Encoding: gzip" angezeigt. Wenn ich mir die (Standard-) .htaccess-Version ansehe, sehe ich, dass es einige Umschreiberegeln gibt, um gzip-Dateien an die Clients zu senden, die sie lesen können. Ich denke, hier kommen die "Content-Encoding: gzip" -Header her. Wenn ich die Komprimierung zwischengespeicherter Seiten auf der Seite mit den Leistungseinstellungen in Drupal aktiviere, wird auch das HTML der angeforderten Seite (nur als anonymer Benutzer) komprimiert zurückgegeben.

1) Führen Sie die Optionen "CSS-Dateien aggregieren und komprimieren" aus. und "JavaScript-Dateien aggregieren". Komprimieren Sie die aggregierten Dateien tatsächlich oder ist es nur so, dass .htaccess sie wie gziped erscheinen lässt? Mit Chrome-Entwicklertools scheinen die Dateien komprimiert zu sein. Wenn Sie sie mit dem Entwickler-Symbolleisten-Addon in Firefox überprüfen (Information -> Dokumentgröße anzeigen), werden sie jedoch nicht als komprimiert gemeldet (während die HTML-Datei immer als solche gemeldet wird, auch wenn ich als authentifizierter Benutzer darauf zugreife!).

2) Wenn sie tatsächlich gziped sind, wo findet die Komprimierung statt? Kann ich den Grad der Komprimierung usw. irgendwie steuern?

3) Ich erhalte immer X-Drupal-Cache "MISS". Es ist mir egal, da ich Lack installiert habe. Wie kommt es jedoch, dass mir eine komprimierte HTML-Datei (die sich nicht im Cache befindet) zurückgegeben wird, da ich den Cache nicht betrete?

4) Besteht die Möglichkeit, dass das Lackmodul irgendetwas durcheinander bringt? Ich greife mit https auf die Website zu, um sicherzugehen, dass der Lack auf jeden Fall umgangen wird.

5) Wenn ich mod_deflate aktiviere, sollte ich diesen Teil von .htaccess intakt lassen? Ich verstehe, dass mod_deflate keine Vorkomprimierung zulässt, aber was ist, wenn die Komprimierung besser ist?

6) Wenn drupal die CSS-, JS- und HTML-Dateien selbst komprimiert, wozu ist dann mod_deflate für diese Dateien aktiviert?

Hier ist der relevante Teil meiner .htaccess-Datei als Referenz:

  <IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

    # Serve gzip compressed JS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

    # Serve correct content types, and prevent mod_deflate double gzip.
    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding
    </FilesMatch>
  </IfModule>

Ein Anfang:

1) Ja.

Hinweis: Wenn ich wirklich wissen möchte, was über die Leitung geht, verwende ich Fiddler (Windows).

2) Siehe Funktion drupal_build_css_cache () in common.inc (Zeile 3603). Sie können die Ebene nicht beeinflussen, aber Sie können beeinflussen, ob sie mit der Variablen 'css_gzip_compression' komprimiert wird oder nicht, siehe Zeile 432 von default.settings.php.

Übrigens: Sie möchten die Komprimierungsstufe nicht beeinflussen: Verwenden Sie für die einmalige Komprimierung in vielen Fällen die maximale Komprimierung immer die beste. Die Übertragungs- und Dekomprimierungszeit auf dem Client ist linear mit der komprimierten Dokumentgröße. Ein einmaliger, leicht erhöhter Leistungseinbruch spart in Zukunft viel Netzwerkaktivität und clientseitige Verarbeitung.

3) -

4) -

5) Die Komprimierung ist besser, da sie nur einmal durchgeführt wird und besser als mod_deflate, das bei jeder Anforderung komprimiert wird und daher eine niedrigere Komprimierungsstufe verwendet. Ich weiß nicht viel über mod_deflate, aber ich denke, wenn es bereits einen Content-Encoding-Header gibt, der besagt, dass der Inhalt komprimiert ist, sollte mod_deflate ihn nicht berühren. Es gab jedoch Fälle, in denen ich eine Sicherungsdatei erhalten habe, die zweimal komprimiert wurde. Daher ist mod_deflate möglicherweise nicht so intelligent und sollte ausdrücklich dazu aufgefordert werden.

6) Es hat keinen Sinn, aber es kann auch andere Anforderungen geben, insbesondere dynamische, dh nicht zwischenspeicherbare Seiten. Beachten Sie, dass nur aggregierte CSS- und JS- und zwischengespeicherte Seiten (Variable 'page_compression') von Drupal komprimiert werden. Nicht zwischenspeicherbare Seiten werden von Drupal nicht komprimiert.

Um zusammenzufassen, was ich bisher gefunden habe und Fietserwins Antwort.

1) Diese Optionen werden komprimiert. Egal was Sie woanders gelesen haben. Ich habe einige Fehler im Drupal-Bug-Tracker durchgesehen und es gibt einige Fehler (z. B. diese Diskussion für d8 ), die die tatsächliche Trennung dieses Verhaltens mit verschiedenen Optionen in den Leistungseinstellungen in Drupal erläutern. Sie können dies auch mit Chromium devtools oder dem Firefox-Netzwerkfenster überprüfen (nicht über die Größenspalte, sondern durch Überprüfen der Antwortheader für Content-Encoding: gzip) und das Umschalten der verfügbaren Optionen für die CSS / JS-Aggregation in Drupal. Die Entwickler-Symbolleiste scheint kaputt zu sein oder ich kann nicht verstehen, was sie tut.

Sie können eine Aggregation, aber keine Komprimierung durchführen, indem Sie die Variablen css_gzip_compression und js_gzip_compression auf FALSE setzen (siehe fietserwin).

2) Die Komprimierung erfolgt im PHP-Code. Weitere Informationen finden Sie in der Antwort von fietswin. Nach seiner Antwort auf die Komprimierungsstufe zu urteilen, denke ich, dass PHP (zumindest für Drupal) auf der maximalen Komprimierungsstufe komprimiert. Beachten Sie, dass das Komprimieren in PHP und das Nicht-Verlassen auf den Webserver bei vielen anderen PHP-Anwendungen üblich ist, z. B. Owncloud, Flyspray usw.

3) Das ist ein bisschen komisch und hat immer noch nicht herausgefunden, warum es passiert. Ich denke, das hat mit dem Lackmodul zu tun. Ich sage nicht Lack selbst, da ich Lack 2 ohne Komprimierungsunterstützung verwende . Dies geschieht nur, wenn ich über Lack auf die Site zugreife (dh wenn ich mit https, das den Lack umgeht, darauf zugreife, wird die Seite nicht zwischengespeichert und nicht komprimiert). Und wenn ich die Option "Zwischengespeicherte Seiten komprimieren" aktiviert habe. Ich vermute also, dass das Lackmodul den Caching-Mechanismus von Drupal vollständig übernimmt, diese Optionen jedoch weiterhin verwendet, um das Verhalten (Komprimierung, Lebensdauer usw.) des Lackcaches festzulegen.

Da ich keine weiteren Informationen dazu finden konnte und mod_deflate so eingestellt ist, dass alle HTML-Dateien gzip sind, habe ich diese Option deaktiviert, um zu verhindern, dass die zwischengespeicherten Seiten doppelt komprimiert werden. Vielleicht gibt es einen Check oder etw, wie bei css / js, um dies zu verhindern, aber ich habe keinen gefunden.

4) veraltete Frage

5) Die Komprimierung sollte bei Drupal erfolgen, nicht bei Apache. Dort kommt es nur einmal vor (ab und zu). Daher sollte der obige .htaccess-Auszug intakt bleiben. Was es tut ist:

RewriteCond %{HTTP:Accept-encoding} gzip #if the client can handle compression
RewriteCond %{REQUEST_FILENAME}\.gz -s #and if the (aggregated css file already exists
RewriteRule ^(.*)\.css $1\.css\.gz [QSA] #serve the compressed file instead

# The same for js files
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

# Do no actual rewriting but set the no-gzip apache variable to inform apache not to compress the already compressed files.
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

Daher sollte dieser Teil intakt bleiben, um den gesamten Mechanismus sicher nutzen zu können. Die Komprimierung ist, wie oben erwähnt, wahrscheinlich die bestmögliche.

6) Um die Antwort von fietserwin zu ergänzen, werden möglicherweise auch andere Apps auf dem Server ausgeführt. Alles in allem aktivieren Sie einfach die Komprimierung für CSS und JS auch in Apache, und der Zugriff von drupal verhindert eine doppelte Komprimierung.