Stratégie de mise en cache pour le SEO

Soumis par Georges Dufour le lun, 03/13/2017 - 09:44 dans SEO

Faire du cache sur une application 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.


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-tete suivants:

  • Cache-control (=> version la plus recente)

  • 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é à 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ête 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

Voici un exemple concret avec une image provenant du site Amazon:


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éfinit

  • 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ête 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 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 utilisez 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.

 

Et vous aimerez dans le même genre :