web-dev-qa-db-fra.com

Compression en Drupal 7

J'utilise Drupal (dernière version 7.22) sur Apache 2.2 et j'ai également installé Varnish (module et proxy). Dans Apache, j'ai désactivé le module mod_deflate. En lisant sur le Web, il semble que les options de la page de performances dans Drupal (css agrégé, js) ne doivent pas compresser les fichiers css et js. Cependant, en parcourant mon site et en vérifiant les en-têtes http, je vois que je suis recevoir "Content-Encoding: gzip". En regardant le (par défaut) .htaccess, je vois qu'il y a des règles de réécriture afin de serveur de fichiers gziped aux clients qui peuvent les lire. Donc, je suppose que c'est là que le "Content -Encoding: gzip "proviennent des en-têtes. De plus, lorsque j'active la compression des pages mises en cache sur la page des paramètres de performances dans drupal, je trouve que même le code html de la page que je demande (en tant qu'utilisateur anonyme uniquement) est renvoyé compressé. Mes questions sur ce qui précède sont:

1) Faites les options "Agréger et compresser les fichiers CSS". et "Agréger les fichiers JavaScript". compresser réellement les fichiers agrégés ou est-ce juste que .htaccess les fait ressembler à gziped? En utilisant chrome, les fichiers semblent compressés. En les vérifiant avec l'addon de la barre d'outils du développeur dans firefox, cependant (Information -> Afficher la taille du document), ils ne sont pas signalés comme compressés (alors que le fichier html est toujours signalé comme tel, même lorsque j'y accède en tant qu'utilisateur authentifié!)

2) S'ils sont effectivement gzipés, où s'effectue la compression? Puis-je contrôler le niveau de compression, etc. d'une manière ou d'une autre?

3) Je reçois toujours X-Drupal-Cache "MISS". Je m'en fiche depuis que j'ai installé Varnish. Pourtant, puisque je ne frappe pas le cache, comment se fait-il que je sois retourné un fichier html compressé (qui n'est pas dans le cache)?

4) Y a-t-il une chance que le module Varnish gâche quelque chose? J'accède au site Web avec https afin d'être sûr que Varnish est contourné, en tout cas.

5) Si j'active mod_deflate, dois-je laisser cette partie de .htaccess intacte? Je comprends que mod_deflate ne permet pas la précompression, mais que faire si la compression est meilleure?

6) De plus, si drupal compresse à lui seul les fichiers css, js et html, quel est l'intérêt d'activer mod_deflate pour ces fichiers?

Voici la partie pertinente de mon fichier .htaccess pour référence:

  <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>
7performancecss-js-aggregation
7
Nikolaos Kakouros

Pour résumer ce que j'ai trouvé jusqu'à présent et la réponse de fietserwin.

1) Ces options se compressent. Peu importe ce que vous avez lu ailleurs. Je suis passé par quelques bugs dans le drupal bug tracker et il y a quelques bugs (par exemple cette discussion pour d8 ) qui discutent de la séparation de ce comportement avec différentes options dans le Paramètres de performances dans drupal. Vous pouvez également le vérifier avec Chromium devtools ou le panneau Firefox Network (pas via la colonne taille, mais en vérifiant les en-têtes de réponse pour Content-Encoding: gzip) et en basculant les options disponibles pour l'agrégation css/js dans drupal La barre d'outils du développeur semble cassée ou je ne peux pas comprendre ce qu'elle fait.

Vous pouvez avoir une agrégation mais pas de compression en définissant les variables css_gzip_compression et js_gzip_compression sur FALSE (voir fietserwin).

2) La compression se produit dans le code php. Pour plus de détails, regardez la réponse de fietswin. A en juger par sa réponse sur le niveau de compression, je suppose que php (au moins pour drupal) se comprime au niveau de compression maximum. Notez que compresser en php et ne pas compter sur le serveur Web est courant pour de nombreuses autres applications php, par exemple owncloud, flyspray, etc.

3) C'est un peu bizarre et je n'ai toujours pas compris pourquoi cela se produit. Je pense que cela a à voir avec le module de vernis. Je ne dis pas le vernis lui-même, car je lance vernis 2 sans support de compression ). Cela ne se produit que lorsque j'accède au site via un vernis (c'est-à-dire lorsque j'y accède avec https, qui contourne le vernis, la page n'est pas mise en cache et n'est pas compressée). Et si l'option "Compresser les pages en cache" est activée. Donc, je suppose que le module de vernis reprend complètement le mécanisme de mise en cache de drupal mais utilise toujours ces options pour définir le comportement (compression, durée de vie, etc.) du cache de vernis.

Comme je n'ai pas pu trouver plus d'informations à ce sujet et que mod_deflate est réglé pour gziper tous les fichiers html, j'ai désactivé cette option pour empêcher les pages mises en cache d'être compressées deux fois. Peut-être qu'il y a un chèque ou qch, comme avec css/js, pour empêcher cela mais je n'en ai pas trouvé un.

4) question obsolète

5) La compression doit se produire dans drupal, pas dans Apache. Là, ça n'arrive qu'une fois (de temps en temps). Ainsi, l'extrait .htaccess ci-dessus doit être laissé intact. Ce qu'il fait, c'est:

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]

Cette partie doit donc être laissée intacte pour profiter en toute sécurité de l'ensemble du mécanisme. La compression, comme dit ci-dessus, est probablement la meilleure possible.

6) Pour compléter la réponse de fietserwin, d'autres applications peuvent également s'exécuter sur le serveur. Dans l'ensemble, activez également la compression pour css et js dans Apache, et htaccess de drupal empêchera la double compression.

0
Nikolaos Kakouros

Un début:

1) Oui.

Remarque: Si je veux vraiment savoir ce qui se passe sur la ligne, j'utilise fiddler (Windows).

2) Voir la fonction drupal_build_css_cache () dans common.inc (ligne 3603). Vous ne pouvez pas influencer le niveau mais vous pouvez déterminer s'il compresse ou non avec la variable 'css_gzip_compression', voir default.settings.php ligne 432.

BTW: Vous ne voulez pas influencer le niveau de compression: pour compresser une fois, utilisez de nombreux cas, la compression maximale est toujours la meilleure. Le temps de transfert et le temps de décompression chez le client sont linéaires avec la taille du document compressé. Ainsi, un coup de performance légèrement augmenté une fois permettra d'économiser beaucoup d'activité réseau et de traitement côté client à l'avenir.

3) -

4) -

5) La compression sera meilleure car elle ne sera effectuée qu'une seule fois et elle sera mieux effectuée par rapport à mod_deflate qui se compressera à chaque demande et utilisera donc un niveau de compression inférieur. Je ne sais pas grand-chose sur mod_deflate, mais je suppose que s'il existe déjà un en-tête Content-Encoding qui indique que le contenu est compressé, mod_deflate ne devrait pas le toucher. Mais j'ai eu des cas où j'ai obtenu un fichier de sauvegarde qui a été compressé deux fois, donc mod_deflate pourrait ne pas être aussi intelligent et devrait être explicitement dit de le faire.

6) Cela ne sert à rien, mais il pourrait y en avoir pour d'autres demandes, en particulier les demandes dynamiques, c'est-à-dire les pages qui ne peuvent pas être mises en cache. Notez que seuls les css et js agrégés et les pages mises en cache (variable 'page_compression') sont compressés par Drupal. Les pages ne pouvant pas être mises en cache ne sont pas compressées par Drupal.

3
fietserwin