Mettre en cache son site web, c’est bien. Avoir une stratégie, c’est mieux. Il faut d’abord faire la distinction entre le cache serveur et le cache navigateur. Ces recommandations s’appliquent tout autant pour une version desktop qu’une version mobile de votre site.
Le cache navigateur
Comme son nom l’indique, notre cache se trouvera coté navigateur. C’est la première étape de notre stratégie. Malgré tout, il est important de configurer son serveur pour que le navigateur mette en cache nos pages et ressources.
Sans entrer dans le détail de la configuration serveur, il va falloir que notre fameux serveur retourne dans ces réponses, les en-têtes suivants :
- Cache-control (=> version la plus récente)
- Expires
Cache-control prendra en valeur max-age=60. “max-age=60” permettra de dire à notre navigateur que pour les 60 prochaines seconds, toutes requêtes vers cette même ressource aura pour réponse le cache navigateur.
Expires prendra en valeur une date. Cette date définie jusque quand le navigateur appellera le cache navigateur pour cette ressource.
Attention, pour pouvoir utiliser l’en-tête Expires, il est nécessaire d’avoir l’en-tête Cache-Control dans les headers de réponse. Dans ce cas, le Cache-Control prendra en valeur public. Par contre, si le Cache Control avec la valeur max-age est défini en même temps que le Expires alors c’est le max-age qui prendra le dessus.
Par exemple, pour le logo du site de la revanche, voici les headers de réponses :
Nous avons :
- Cache-Control: max-age=1209600
- Expires: Wed, 19 Oct 2016 13:24:25 GMT
Comme le max-age prend le dessus sur l’en-tête Expires, cela signifie que la page sera en cache pendant 1209600 secondes. Donc, durant ces 1209600 prochaines secondes, le navigateur ira chercher cette ressource depuis le cache navigateur.
Le cache serveur
1 – Les ressources statiques (css / js / images)
Lorsque le cache navigateur a expiré, une requête va à nouveau être envoyée vers notre serveur.
Afin d’éviter d’utiliser de la bande passante pour rien, on aimerait bien vérifier que notre logo a bien été mis à jour. Si ce n’est pas le cas, on souhaiterait l’indiquer au navigateur et ne pas charger à nouveau le logo depuis le serveur.
Pour cela, nous allons utiliser l’en-tête Etag ou l’en-tête Last-Modified.
- Etag est une empreinte de la ressource. Cette empreinte est générée à partir de l’inode du fichier, sa taille et sa dernière date de modification
- Last-Modified fait référence à la dernière date de modification de la ressource
Si vous avez le choix, le mieux est d’utiliser l’en-tête Etag. Lors de la première requête au serveur pour cette ressource, l’en-tete Etag sera envoyé avec les en-têtes de réponse.
Lors d’une nouvelle requête vers le serveur, l’en-tête If-None-Match=etag-valeur sera envoyé au serveur. (C’est géré automatiquement par votre navigateur)
Si l’Etag n’a pas changé alors le serveur renvoie une réponse 304 en indiquant au navigateur qu’il peut utiliser son cache. Cela permet d’éviter de renvoyer la ressource et d’utiliser de la bande passante pour rien (et on gagne en temps de chargement).
Avec l’en-tête Last-Modified, c’est l’en-tête If-Modified-Since=last-modified-valeur qui est envoyé au serveur. Le fonctionnement reste le même.
Dans les “Request Headers”, nous avons bien notre header If-None-Match avec pour valeur notre Etag. On peut constater que le “Status code” de notre réponse est une 304.
Dans les “Response Headers”, nous avons :
- Le Cache-Control de défini
- L’Etag de renvoyé (inchangé par rapport à notre requête, d’où la réponse en 304)
2 – Les pages dynamiques (via Php, Ruby… )
Il faut savoir que les en-têtes Etag et Last-modified ne fonctionnent que sur des ressources statiques, car ils se basent sur le fichier et sa date de modification.
Donc, pour utiliser ces en-têtes, il va falloir créer un cache serveur. C’est-à-dire que pour chaque page php/ruby/langagesquevousvoulez, il va falloir, créer et mettre le contenu généré dans un fichier statique. Et ce fichier devra se mettre à jour lorsque votre page dynamique change de contenu (en même temps, c’est l’intérêt d’avoir des pages dynamiques).
Dis comme ça, c’est peut-être effrayant, mais à vrai dire, c’est de la configuration serveur. Voici un guide pour le mettre en place avec Nginx.
Ensuite, quand vous avez configuré votre serveur, vous pouvez utiliser les en-têtes Etag et/ou Last-modified
En renvoyant une 304, aucune donnée ne sera renvoyé. Le serveur indiquera au navigateur d’utiliser son cache pour cette ressource. On aura donc un “Time To First Byte” plus court, beaucoup moins de donnée à charger.
Au final, un temps de chargement plus rapide. D’ailleurs, même au premier chargement, la page risque de se charger plus vite si le cache a bien été mis en place.
Pour le SEO, ce n’est pas négligeable surtout si votre site contient énormément d’URLS. Pour chaque crawl d’un site, le robot de Google lui dédie un temps déterminé. Plus vos pages se chargeront rapidement, plus Google crawlera de pages sur votre site.
Conclusion
Mettre en place une stratégie de cache bien pensée est un levier puissant pour améliorer les performances globales de votre site et contribue au budget de crawl. Qu’il s’agisse du cache navigateur ou du cache serveur, chaque optimisation contribue à accélérer le temps de chargement, à limiter la consommation de bande passante et à offrir une meilleure expérience utilisateur. Mais ce n’est pas tout : en facilitant l’accès aux ressources pour les robots d’indexation, vous maximisez également vos chances d’être bien positionné dans les résultats de recherche. Un site rapide, bien configuré et techniquement propre est un atout SEO majeur, surtout si votre architecture comporte de nombreuses URLs. Prenez le temps d’auditer, de tester et d’ajuster vos paramètres de cache : les bénéfices seront visibles à la fois côté utilisateurs et côté moteur de recherche.
