Le compresseur nGzip est un script PHP qui produit une version compressée d'un fichier directement sur le site. À quoi cela sert-il ? Juste à gagner du temps, à mieux utiliser les ressources et à améliorer l'expérience d'utilisateur, rien que ça ! Mais lisez plutôt...
La visite d'une page sur un site donne lieu à une négociation de contenu entre le navigateur et le serveur (Apache). Si elle est concluante, le serveur envoie la version compressée de la page. Plus vite rendue à destination, elle est aussi plus vite exploitée. La réactivité d'un site a toujours la faveur des utilisateurs.
Dans le dialogue qui s'instaure entre le navigateur et le serveur, tout se joue au niveau des en-têtes contenues dans les requêtes et réponses HTTP.
Le navigateur demande un certain fichier au serveur : il annonce ses possibilités de traitement au travers des en-têtes de la requête. Le serveur en tient compte pour déterminer le fichier à servir : il répond en envoyant le fichier accompagné d'en-têtes, qui sont autant d'indications de traitement pour le navigateur.
Prenons l'exemple suivant :
En-têtes HTTP envoyées par le navigateur
Accept-Charset: UTF-8,*
Host: example.org
Connection: keep-alive
Keep-Alive: 300
Accept-Language: fr,en;q=0.5
Accept: text/xml,...,*/*;q=0.5
User-Agent: Mozilla/5.0 ...
Accept-Encoding: gzip, deflate
Notez l'en-tête Accept-Encoding indiquant que le navigateur accepte les formats de compression
gzip et deflate.
En-têtes HTTP envoyées par le serveur
Date: Tue, 24 Jul 2007 15:32:58 GMT Server: Apache Last-Modified: Mon, 23 Jul 2007 12:27:33 GMT Etag: "40f98da-636-46a49eb5;468273e9" Accept-Ranges: bytes Content-Length: 1590 Content-Type: text/html Content-Language: fr Vary: negotiate, accept-language, accept-encoding TCN: choice Content-Location: fichier.fr.html.gz Content-Encoding: gzip
Les en-têtes Vary et TCN confirment l'issue positive d'une négociation de contenu,
l'en-tête Content-Location donne le nom du fichier servi,
et Content-Encoding précise qu'il est compressé au format gzip (suffixe .gz).
Le navigateur tiendra compte de ces indications pour traiter comme il se doit le contenu du fichier à suivre, c'est-à-dire le décompresser puis l'interpréter normalement.
Le mécanisme de la négociation repose sur un algorithme complexe, sommairement illustré au travers des exemples suivants.
| Cas | Demandé | Disponibles | Servi | Commentaire |
|---|---|---|---|---|
| (1) | nom.html | nom.html nom.html.gz |
nom.html | pas de négociation |
| (2) | nom.html | nom.html.html nom.html.gz |
nom.html.gz | on force la négociation en sur-suffixant le nom |
| (3) | nom.html | nom.html.gz nom.html.en nom.html.fr |
nom.html.fr | la langue a priorité sur le codage |
| (4) | nom.html | nom.html.la nom.html.en nom.html.en.gz |
nom.html.en.gz | la sélection a lieu sur la langue secondaire puis le codage |
| (5) | nom.fr | nom.html.fr nom.en.html nom.html.en |
aucune base ne correspond | |
| (6) | nom | nom.fr.html nom.html.en |
nom.fr.html | le succès de la négociation est quasi assuré |
Ce qu'il faut retenir du tableau ?
Nous prendrons le cas d'un site en hébergement mutualisé avec Apache v.1.x. En général, la seule option laissée à l'utilisateur pour modifier le comportement du serveur est celle d'utiliser un fichier htaccess. Si l'hébergeur l'interdit, voyez ailleurs…
Voici les directives qui doivent y apparaître au minimum pour que la négociation ait lieu :
Options +MultiViews AddEncoding x-gzip .gz AddType text/html .gz
Si le site est multilingue, on y inclut aussi les déclarations de langue. Par exemple, du français et de l'anglais :
AddLanguage fr .fr AddLanguage en .en LanguagePriority fr en
Si les feuilles de style CSS et/ou les scripts JavaScript doivent faire l'objet d'une négociation, on place alors un fichier htaccess supplémentaire dans les répertoires respectifs. Les noms des fichiers doivent être sur-suffixés, par exemple, style.css.css ou script.js.js, car il n'y aurait pas de négociation sinon (cf. la règle 1).
Dans le répertoire des feuilles de style :
ForceType text/css
Dans le répertoire des scripts :
ForceType text/javascript
Par précaution, testez d'abord le bon fonctionnement des fichiers htaccess dans des répertoires à part.
Dans l'exemple de requête précédent, l'en-tête Accept-Encoding comprenait 2 valeurs :
gzip et deflate. La première correspond à un format de compression établi,
reconnu par 90 % des navigateurs actuels, la seconde à un format plus récent donc moins répandu.
La compression est l'opération qui fabrique une version équivalente mais allégée d'un fichier. Cette version transite plus vite dans les réseaux et le navigateur en disposera donc plus tôt. La décompression est l'opération qui restitue le fichier original. Réalisée par le navigateur, elle est automatique et quasi instantanée.
Le serveur peut effectuer la compression à la volée. Pour gzip, cela implique l'utilisation
d'un module supplémentaire (mod_gzip), rarement présent en hébergement mutualisé. Quant à deflate,
le serveur Apache version 2 inclut en standard le module mod_deflate : la compression est alors automatique si activée. Mais cette version
est encore bien récente. Les modalités de la négociation sont les mêmes quel que soit le format.
Pour pallier l'absence de ces modules, on peut compresser les fichiers au préalable. Le serveur pourra donc libérer les ressources qu'il aurait sinon consacrées à la compression. Ces ressources sont d'autant plus précieuses que la charge sur le serveur est forte, tandis que les utilisateurs attendent.
Quand faut-il compresser les fichiers ? Ça dépend… Les situations sont bien sûr différentes. Toujours est-il, voici quelques lignes directrices :
Si je vous entretiens du tandem « négociation de contenu/compression de fichiers », c'est que ce site applique la recette. Toutes les pages susceptibles d'être compressées le sont, que ce soient les pages HTML, les feuilles de style ou les scripts. Ce sont beaucoup de documents textuels, parfois très lourds (certains dépassent 600 ko). Autant de caractéristiques en faveur de leur compression.
Mais la mise en œuvre est fastidieuse. Il faut renommer les fichiers puis les compresser, ensuite les télécharger sur le site, et recommencer encore à chaque mise à jour. Les inconvénients contrebalanceraient-ils les avantages au point de condamner une solution si prometteuse ? Non, bien sûr. Tout peut s'arranger en automatisant un peu les choses.
C'est la raison d'être de nGzip : le script permet de gérer en ligne la compression et le renommage approprié de tous les fichiers de type HTML, JavaScript et CSS. On peut facilement ajouter d'autres types en éditant le script (cf. les commentaires dans le code).
Le script nGzip nécessite Apache (version 1 ou 2), PHP (version 4 ou 5) avec l'extension Zlib (presque toujours installée), la possibilité d'utiliser des fichiers htaccess et un navigateur. Certains effets d'interface ne sont disponibles que si JavaScript est activé sur le navigateur.
Choisissez le format d'archive souhaité : nGzip (Zip) ou nGzip (Tgz).
Décompressez l'archive puis chargez le fichier ngzip.php sur le site. Le script peut s'installer n'importe où. Par précaution, il vaut mieux le placer dans un répertoire à accès protégé car il pourrait révéler des détails de la structure du site sinon. En revanche, le script ne peut pas modifier ou détruire les fichiers originaux.
Remarque :
Bien que le traitement des fichiers soit très rapide, le délai alloué au script sera peut-être insuffisant
si les fichiers sont nombreux et/ou volumineux. Auquel cas, il suffit de traiter le contenu du répertoire en plusieurs fois.
Le calcul de la date et de la taille consomme aussi quelques millisecondes en plus.
Voici des copies d'écran :
La fenêtre de démarrage
Tous les fichiers sont affichés
Les fichiers sont traités (taille affichée)
Si vous utilisez le navigateur Firefox, l'extension Web Developer a une option pour voir les en-têtes de réponses. Certains sites permettent de vérifier que les pages reçues sont bien compressées, par exemple, Leknor, GidNetwork, et d'autres.
Peut-être dans une version ultérieure :
Le script est mis à disposition sous licence GPLv3.