montre un exemple typique du cas d'hébergement pour lequel
- la compression gzip du flux http par Apache n'est pas activée par défaut
- activer la compression par PHP via un tampon provoque un écroulement du temps d'envoi de la page
Je serais personnellement d'avis de supprimer complètement cette option de configuration car tous les hébergements bien dimensionnés activent la compression par apache. Lorsque celle-ci n'est pas activée, c'est qu'un problème de ressource se pose, et le faire au niveau de PHP est contre-productif.
On peut remplacer par un avertissement et une doc, mais
traditionnellement SPIP essaie de tirer le meilleur de tout
hébergement, ême le plus pourri. Cela dit s'il faut passer par un
define() pour activer la chose ça ne me choque pas
J'ai quelques sites en mutualisés sur lesquels la compression n'est pas activée au niveau global, mais sur lesquels j'arrive à servir les .gz via une modification du .htaccess:
<files *.js.gz>
AddType "text/javascript" .gz
AddEncoding gzip .gz
Header set Vary "Accept-Encoding"
</files>
<files *.css.gz>
AddType "text/css" .gz
AddEncoding gzip .gz
Header set Vary "Accept-Encoding"
</files>
#Check to see if browser can accept gzip files.
ReWriteCond %{HTTP:accept-encoding} gzip #make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$ #check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f #All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L]
En fait, est-ce que vous pouvez préciser votre pensée? Parce que j'ai l'impression que j'ai donné un exemple à côté de la plaque.
Ce qui rame, c'est la négociation (et la création) de la version .gz depuis PHP, en direct, pour les pages «html» de SPIP, non?
Oui, via un buffer gz :
ob_start('ob_gzhandler');
Comme le gz se fait à chaque hit, ça consomme du processeur, et sur un hebergement sous dimensionné ça peut conduire à pire que mieux.
Dans mon exemple, les .gz concernent les fichiers de cache et les javascript. C'est fait une fois et on est tranquille; c'est une «simple» redirection qui envoie le .gz au client. Là, il n'y a plus de PHP qui entre en jeu. Du coup, ça ne devrait pas trop peser sur le temps de réponse?
Oui, ça c'est bon puisque le gz est créé une fois pour toute (enfin a la remise a jour du fichier près).
Ce qui passerait en define, ça serait la négociation des pages HTML, c'est-à-dire le premier élément de la config. Et le fait de créer un .js.gz et un .css.gz pour les fichiers statiques, ça ça ne changerait pas. C'est ça?