Web Performance : cache, domain sharding et CDN

Après la compression côté serveur, la minification des fichiers JS et CSS et les images, voici la gestion du cache et le domain sharding.

La gestion du cache

Les utilisateurs qui viennent sur votre site vont très certainement regarder plusieurs pages. C’est en tout cas ce que je vous souhaite. Dès la première page, le visiteur aura, normalement, chargé les fichiers JavaScript et CSS nécessaires à l’ensemble du site. Inutile donc de lui imposer ce chargement à chaque page visitée. C’est justement l’objet du cache.

Le cache du navigateur va donc charger uniquement ce qui est nouveau. Mais pour cela, il faut lui indiquer comment s’y prendre. La façon la plus simple consiste à modifier votre fichier .htaccess et d’y ajouter ces quelques lignes (à adapter selon vos besoins) :

# Active l'expiration de contenu et met par défaut à 0 le temps d'expiration
ExpiresActive On
ExpiresDefault A0

# Les fichiers qui seront cachés pour 1 semaine
<FilesMatch "\.(gif|jpg|png|swf)$">
ExpiresDefault A604800
Header append Cache-Control "public"
</FilesMatch>

# Les fichiers qui seront cachés pour 1 an
<FilesMatch "\.(ico)$">
ExpiresDefault A29030400
Header append Cache-Control "proxy-revalidate"
</FilesMatch>

# Les fichiers qui seront cachés pour 1 mois
<FilesMatch "\.(js|css)$">
ExpiresDefault A2419200
Header append Cache-Control "proxy-revalidate"
</FilesMatch>

# pas de cache pour les fichiers dynamiques
<FilesMatch "\.(php|cgi|pl|htm)$">
ExpiresActive Off
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</FilesMatch>

Le temps est indiqué en secondes. Donc, pour 1 journée, vous aurez : 86400

Et c’est tout. Avec cela, vos visiteurs vont apprécier le passage d’une page à une autre.

Le domain sharding

Mais qu’est-ce donc que cela ?
Nous avons vu précédemment que les navigateurs sont limités en nombre de connexions simultanées sur un même domaine. La solution consiste donc à multiplier les domaines afin d’avoir plus de canaux de chargement.

Cette solution nécessite donc d’avoir un nom de domaine. Elle n’est pas non plus adaptée à tous les sites. Elle dépend beaucoup du contenu.
De plus, il faut bien comprendre que la résolution d’un nom de domaine prend du temps : trop de noms de domaine ne serait donc pas bon.

Je vais prendre 2 exemples qui vous montreront bien le fonctionnement du domain sharding.

Premier exemple

Le premier site est WOO (http://woo.pbem.be). La page d’accueil contient peu d’images.

J’ai utilisé le site WebPageTest pour contrôler la vitesse de chargement de la page.

 

Les gains ne sont pas vraiment là. Pas étonnant vu le nombre réduit d’images sur cette page.

Second exemple

Pour bien voir la différence, voici un autre cas particulier d’une page contenant beaucoup d’images. Nous allons voir comment le domain sharding fait son effet sur ce type de page. La page en question provient du site Films-Vampires.com. C’est la page contenant la liste des films avec une petite image par film.

On voit très nettement sur ce gros plan que les images sont chargées 2 par 2 puisque IE7 ne peut avoir que 2 connexions simultanées par domaine.

Et là, surprise, le temps de chargement est le même avec ou sans domain sharding ! Que se passe t-il ? Pour le savoir, il suffit de regarder comment sont chargées les images avec et sans le domain sharding : de la même façon. En effet, nous n’avons que déplacé le problème sur un autre domaine.

Alors, quelle est la solution ? Nous allons placer le domain sharding une image sur 2 :

Cette fois-ci, l’effet est bien là. Le temps de chargement à été réduit de moitié. Et en regardant le graphe, on constate bien que IE7 charge 4 images à la fois : 2 sur le domaine principal et 2 sur le domaine statique.

Pour mettre en place le chargement des images 1 sur 2, vous pouvez utiliser un simple modulo :

// 'boucle' représente une variable qui s'incrémente à chaque passage

if(($boucle % 2) == 0) {
	$domain = 'http://static.mon-domaine.com/';
}else{
	$domain = '';
}
$img = $domain.$url_image;

Mais avec cette méthode, vous risquez d’avoir, en fonction des pages, des images chargées depuis un domaine et sur une autre page, depuis un autre domaine. Du coup, le cache ne va pas fonctionner correctement.

L’une des solutions consiste à utiliser la première lettre du nom de l’image comme valeur du modulo :

if((ord($nom_image[0]) % 2) == 0) {
	$domain = 'http://static.mon-domaine.com/';
}else{
	$domain = '';
}
$img = $domain.$url_image;

Vous voyez le principe. Je vous laisse trouver d’autres solutions adaptées à vos besoins.

Sur IE8, qui peut faire 6 connexions simultanées, le temps de chargement de cette même page sans domain sharding est de 6.034s. Avec domain sharding ce temps descend à 5.877s. Et avec le domain sharding 1/2, ce temps descend à 4.960s.

Nous le voyons ici qu’avec les navigateurs modernes, le domain sharding n’est pas forcément d’une grande utilité.

Ce qui va faire surtout une différence, c’est le fait qu’il n’y aura pas de cookie sur le domain sharding. C’est toujours ça de moins à charger et sur une centaine d’images, on commence à sentir une petite différence.
Comment ne pas générer de cookie sur le sous-domaine ? En fait, en ne faisant rien, tout simplement. Les cookies sont générés par le JavaScript ou le PHP. Si vous n’appelez que des images, il n’y aura pas de cookie. Faites quand même attention que les sessions ne soient pas démarrées automatiquement dans votre configuration PHP.
Toutefois, si vous utilisez Google Analytics, faites bien attention à prendre le dernier code en spécifiant que les sous-domaines ne sont pas pris en compte sinon vous aurez un cookie sur le sous-domaine. Sinon, placez vos codes JavaScript en fin de page.

Évitez de mettre vos CSS sur des domaines autres que le principal. En effet, le chargement du fichier CSS va bloquer le rendu. Comme il va falloir au navigateur faire une résolution de nom de domaine, vous risquez d’avoir une perte de temps au final.
Éventuellement, vous pouvez faire des tests avec les fichiers JavaScript se trouvant en fin de fichier.

Content Delivery Network

À ne pas confondre avec le domain sharding, les CDN vous permettent de délivrer du contenu situé géographiquement proche de vos utilisateurs, évitant ainsi des temps de latences trop important. D’ailleurs, vous pouvez mettre vos domaines statiques sur des CDN, tant qu’à faire.

Et pour faire cela, votre contenu va être placé sur différents serveurs situés un peu partout dans le monde.

Évidement, ce système à un coût et n’est peut-être pas adapté à votre site. Utiliser un CDN est surtout pratique si vous avez une cible internationale.

Par contre, rien ne vous interdit d’utiliser les librairies JavaScript partagées sur Google. Il est fort probable que vos utilisateurs soient déjà passé par un site utilisant ces librairies et, du coup, n’aura pas à les recharger. Par contre, vous êtes à la merci des latences des serveurs Google.

À noter aussi cdnjs.com qui héberge beaucoup de scripts JavaScript populaires. Ils hébergent les scripts que Google ou Microsoft n’hébergent pas. Et c’est gratuit.

Si vous comptez vraiment utiliser un CDN, Akamai reste le leader dans ce domaine. Amazon propose également une offre : Amazon CloudFront.