Ce post est le premier d’une série de 3 et est tiré de l’expérience des finalistes du concours de performance Web 2010

Il traite rapidement des actions classiques en Performances Web qui sont les plus faciles à mettre en place tout en offrant un retour sur investissement souvent suffisant. Il devrait être utile aux novices mais ceux qui connaissent déjà les bases devraient aller voir les 2 articles suivants.

La configuration d’Apache

Les premières actions pour améliorer à peu de frais et de manière impactante les performances Web passent par la configuration de son serveur Web. Si vous voulez un exemple complet, regardez ce .htaccess, fait par Omar Haddouchi, qui a fait par ailleurs un boulot impressionant. Il y a principalement 3 actions :

Gérer le cache navigateur

Il s’agit de demander au navigateur de garder chez lui autant que possible les fichiers statiques. Non les techniques à base de ETag et de réponse 304 sont quasiment inutiles car une requête HTTP est tout de même faite pour vérifier la fraîcheur du fichier. Et sur des fichiers de page Web, généralement entre 1 et 200Ko, l’aller-retour au serveur seul est plus long que le téléchargement. Voici un exemple de configuration :

<IfModule mod_expires.c>
	ExpiresActive On
	ExpiresDefault "access plus 1 month"
	ExpiresByType image/jpeg "access plus 1 month"
# ../..
	ExpiresByType text/javascript "access plus 1 month"
</IfModule>

Un mois ça n’est pas encore assez agressif, la valeur généralement recommandée est de 10 ans :) Par contre cela demande une très bonne gestion (dynamique donc) des URLs qui mènent aux fichiers statiques, afin de faire recharger les JS/CSS/images que vous mettez à jour.

La compression Gzip

Compresser à la volée les fichiers non binaires (HTML, CSS, JS) vous épargne d’envoyer 80% de leurs poids sur votre réseau, et aide vos utilisateurs à petit débit (à l’étranger, sur mobile, un petit pourcentage de français). Compresser du binaire est généralement inutile et consommateur de ressources serveur, d’où cette configuration :

<IfModule mod_gzip.c>
	mod_gzip_on       yes
	mod_gzip_dechunk  yes
	mod_gzip_item_include file      \.(html|txt|css|js|json)$
	mod_gzip_item_exclude file      \.(jpg|png|gif|ico)$
</IfModule>

Vous pouvez aller encore plus loin avec gzip et ne pas faire faire la compression par Apache à chaque requête mais plutôt en générant des fichiers gzipés (au build, ou de manière dynamique) de vos HTML (si la page est statique) et CSS/JS et en servant cette version si le navigateur le supporte. Voici un exemple de configuration :

# déclaration des types des fichiers gzipés
AddType "application/javascript" .jsgz
AddType "text/css" .cssgz
AddType "text/html" .htmlgz
# ajout de l'entête gzip pour ces fichiers
AddEncoding gzip .jsgz
AddEncoding gzip .cssgz
AddEncoding gzip .htmlgz

Cet exemple est pris du .htaccess de Etienne Guilluy. Dans le cadre du concours, l’intérêt était limité, mais en production l’avantage est évident car il permet d’épargner du CPU et donc de mieux résister aux charges.

Supprimer les cookies inutiles

Un cookie fait entre 0.5 et 4ko. Une page moyenne déclenche une cinquantaine de requêtes (115 sur cette page de la FNAC …). Si vous n’y prenez pas garde vous allez donc demander à votre utilisateur d’uploader chez vous entre 25Ko et 200Ko (le double donc pour la FNAC) alors que le cookie n’est généralement utile que pour la partie dynamique qui génère le HTML, et que l’upload des ADSL beaucoup plus précieux que le download.

La technique consiste à mettre ses fichiers statiques sur un autre nom de domaine ou sous-domaine et à ne pas activer les cookies. Pour ce concours, nous fournissions des sous-domaines, mais il fallait penser à remplacer la définition du cookie sur le domaine faite en JS dans le marqueur pour en bénéficier complètement.

Le poids des images

et le choc des mots… Mais je m’égare :) L’avantage de ce concours, c’est que certains ont pu revisiter les images de la FNAC qui comme sur beaucoup de sites sont fabriquées à la chaîne, sans optimisation particulière. Plusieurs concurrents ont donc réduit le poids des images avec les techniques suivantes :

• réduction de la palette de couleurs pour les PNG 8 bits
• indexed colors pour les images de moins de 256 couleurs

Optimisation du CSS

Automagique

La technique générale a été de générer une version « de production » par un outil, en voici plusieurs :

• CSS Tidy pour le compresser
• l’addon Firefox css-usage pour ne récupérer que les CSS utilisés

Il n’y a pas vraiment d’outil meilleur que l’autre en terme de performance pure (poids final et rendu). Prenez donc celui qui s’adapte le mieux à votre environnement de mise en production (vous en avez un n’est ce pas ?) et vérifiez bien que tous vos hacks restent compris.

Si dans le cadre du concours il était intelligent de réduire le CSS en supprimant les lignes inutilisées dans cette page, en environnement de production, c’est forcément plus délicat

A la main

Dans les recommandations Google se trouve depuis le début un conseil sur les sélecteurs CSS qui permettent d’accélérer le rendu. Théoriquement c’est évident. Mais on va se parler franchement : je n’ai jamais constaté ou lu que cela permettait de gagner quoi que ce soit de significatif ( > 100ms).