Stratégies d’optimisation du cache

Deux règles principales pour la performance des sites web sont de réduire le nombre de requêtes HTTP et de limiter la taille des données qu’on télécharge.

Malheureusement ces deux règles entre parfois en conflit. Si je fais un gros fichier unique pour toutes mes CSS, je vais inclure des règles qui seront inutiles pour la page courante, et qui augmenteront inutilement la taille totale à télécharger.

Vous avez en fait cinq options :

Des fichiers centraux

La première optimisation est celle qui devrait être faite par défaut : regrouper tous les composants javascripts du site en un seul fichier. Faire de même avec les feuilles de style. Regrouper les images qui le peuvent sous forme de sprites (plusieurs images en un seul fichier, on décide ensuite quelle partie de la grosse image on affiche grâce à des règles CSS).

On réduit ainsi drastiquement le nombre de composants à télécharger pour le client, et donc le nombre de requêtes HTTP. Dans le cas idéal ces gros fichiers sont téléchargés une fois puis mis en cache pour les accès futurs. Le client ne télécharge donc quasiment plus rien par la suite.

Des fichiers isolés

La seconde proposition est de faire exactement le contraire. On laisse chaque composant dans son propre fichier. C’est intéressant quand chaque page n’utilise qu’une partie réduite de tous les javascript et de toutes les règles CSS. On peut se contenter de quelques kilo-octets là où on en aurait téléchargé quelques centaines sinon. C’est aussi intéressant si quelques composants changent fréquemment. Au lieu de tout retélécharger, on ne télécharge que ce qui change, le reste est déjà en cache.

Le contre-coup c’est que du coup le navigateur fait beaucoup de requêtes HTTP pour chaque page. Pour des petits fichiers ça peut rapidement être plus pénalisant que le téléchargement lui-même.

Plusieurs fichiers centraux

Comme les requêtes HTTP deviennent facilement pénalisantes, on tente parfois de trouver un compromis. On ne fait pas un seul fichier central mais quelques uns. Les composants sont regroupés par thème, par rubrique du site, ou/et par fréquence de modification. On obtient alors quelques fichiers au lieu d’un seul ou d’une vingtaine, histoire de trouver un équilibre entre le nombre de requêtes HTTP et le poids des fichiers.

Quand un composant est mis à jour, on impose au visiteur de retélécharger tous les composants qui sont dans le même fichier, mais le fichier en lui même ne sera pas suffisamment gros pour que ça devienne gênant. On reste cependant assuré de devoir souvent faire plusieurs requêtes HTTP à chaque page.

Des agrégats par page

Il est aussi possible de faire un autre type de compromis. Au lieu de considérer qu’un fait plusieurs centraux qui seront utilisés ou non sur chaque page, on va faire un seul fichier par page, mais ce fichier sera différent sur chaque page. C’est quelque chose d’assez facile à réaliser avec les outils actuels et qui ne demande pas forcément beaucoup de travail pour le développeur.

Le côté négatif c’est que vous aurez un résultat différent pour chaque type de page, donc vos utilisateurs auront le plus souvent à télécharger ce nouveau fichier spécifique à la page qu’ils lisent, même si au final ils ont déjà en cache des fichiers presque identiques.

Tout en interne

Enfin, il arrive des fois où une page est tellement spécifique, tellement unique, qu’on ait besoin de mettre les composants directement dans le corps de la page HTML au lieu de fichiers externes. Le cas est cependant rare et très spécifique. En général ce n’est pas ce que vous devriez faire.

Il n’y a pas de solution universelle

S’il y avait une solution universelle, il n’y aurait pas de questions à se poser. Vous pouvez considérer que la première solution est celle à mettre en oeuvre par défaut si vos fichiers ne sont pas trop gros et si vous n’êtes pas certains d’être dans une situation spécifique.

Or .. les situations spécifiques sont légion. On en revient souvent à savoir si on doit optimiser la page pour des gens qui ont déjà nos fichiers en cache ou pour des gens qui devront télécharger les nouveautés, si on doit optimiser la première page ou tout le site.

C’est là que les mesures proposées dans le premier billet sont utiles. Si en moyenne les gens ont un cache vide, vous aurez à privilégier des agrégats spécifiques à chaque page (solution 4). Si vos utilisateurs ont un cache plein et que vous avez des pages très différentes ou des composants qui changent souvent, vous pouvez privilégier plusieurs fichiers centraux (solution 3). Si vos utilisateurs ont un cache vide lors de la première page de chaque visite, mais un cache utilisable par la suite et plusieurs pages par visite, alors un fichier centra unique est préférable (solution 1).

Il est tout à fait possible que certaines pages sont suffisamment différentes du reste du site pour bénéficier d’une stratégie différente. Ce peut être à cause du contenu qui n’est pas du tout le même, ou simplement parce que l’utilisation qu’en font les visiteurs est elle-même différente. Ainsi les pages d’accueil peuvent par exemple bénéficier d’une stratégie différente des pages de contenu. Evitez cependant de multiplier les stratégies sur un même site. A chaque fois cela met en échec le cache quand vous arrivez sur une partie du site avec une nouvelle stratégie d’optimisation du cache. 

Certes ce ne sont que des directions et chaque cas est spécifique, d’autres types d’informations sont à prendre en compte. Pourtant, si les mesures réalisées dans le précédent billet ne sont les seules à rentrer en compte, prendre une décision sans avoir une idée de leur valeur peut mener à une contre-performance. Ne vous fiez pas aux préjugés, mesurez et choisissez seulement ensuite, avec toutes les cartes en main.