On sait qu'il est très important d'obtenir, pour un site web, de bons temps de réponses pour l'affichage de ses pages. Certes, cela a un impact sur le crawl de Google, mais avant tout, cela fournit une expérience utilisateur optimale, élément essentiel aujourd'hui dans une stratégie de visibilité et de fidélisation. Voici donc quelques informations sur les différents systèmes de caches serveur du marché (reverse proxy, cache de code, cache mémoire et cache statique) et leurs principales différences.

Introduction aux caches serveur

La rapidité de réponse d’un site web est un facteur prépondérant pour le référencement sur desktop et mobile. Afin d’améliorer la vitesse de réponse d’un site, il existe plusieurs leviers à actionner :

  1. Optimiser le poids de ses ‘assets’ (les images, les scripts et les feuilles de styles) ;
  2. Optimiser son code de génération de contenu dynamique (réduire le nombre de boucles PHP par exemple) ;
  3. Utiliser un hébergeur possédant une bande passante solide ;
  4. Mettre ses contenus en cache (pages web, assets) sur les terminaux client ;
  5. Délivrer des contenus (pages web, assets) en cache coté serveur.

C’est sur ce dernier point que va porter cet article, les autres points ayants déjà été abordés par d’autres auteurs dans des numéros antérieurs de cette lettre.

Commençons par une définition : Un serveur de cache est un serveur ou un service réseau dédié agissant comme un serveur qui enregistre des pages web ou d'autres contenus Internet localement. En plaçant les informations précédemment demandées dans un stockage temporaire ou dans un cache, un serveur de cache accélère l'accès aux données et réduit la demande de bande passante d'une entreprise. Les serveurs de cache permettent également aux utilisateurs d'accéder au contenu hors ligne, y compris aux fichiers multimédia enrichis ou à d'autres documents. Un serveur de cache est parfois appelé un "moteur de cache ».
(source : http://whatis.techtarget.com/definition/cache-server).


Un serveur de cache ne fait pas qu’améliorer le temps de réponse, il possède d’autres avantages comme la résistance à la montée en charge et la réduction des consommations de ressource processeur et mémoire.

Il existe de nombreuses solutions et typologie de génération et gestion de cache coté serveur. Cet article va vous les présenter.

Les différentes types de cache serveur

Il existe différents types de gestion de cache serveur :

  • Reverse proxy ;
  • Cache de code (ou plutôt code précompilé : bytecode) ;
  • Cache mémoire ;
  • Cache statique (fichier).

 

Le Reverse proxy

Un serveur de cache est presque toujours un serveur proxy, c'est-à-dire un serveur qui "représente" les utilisateurs en interceptant leurs requêtes Internet et en les gérant pour les utilisateurs. Vous pouvez apprendre tout ce qu’il y a à savoir sur les reverse proxy en lisant l’article d’Aymeric Bouillat sur le sujet dans la newsletter d’Abondance.
En résumé, voici son fonctionnement :


Fig. 1. Schéma de principe du reverse proxy : https://fr.wikipedia.org/wiki/Proxy_inverse.

 

Chaque requête http(s) envoyées par les navigateurs est interceptée par le reverse proxy avant d’être éventuellement transmise au serveur web (Apache ou Nginx). Si la requête correspond à une requête déjà en cache, alors la version cachée est renvoyée directement depuis la mémoire du reverse proxy et évite ainsi toute la chaine d’exécution du serveur web (appel php, requête base de donnée, réponse du serveur web). A contrario, si la requête http du navigateur n’est pas en cache alors le reverse proxy passe la requête au serveur Web qui renvoie la réponse au reverse proxy et qui la met en cache pour une durée prédéterminée.


Fig. 2. La chaine d’exécution d’un serveur web classique : http://igm.univ-mlv.fr.

En évitant la chaine d’exécution complète du serveur web, led temps de réponse des requêtes cachées sont réduits au minimum. Le temps de réponse serveur est ce qu’on appelle le TTFB (Time To first Byte).

Il existe deux principaux reverse proxy : NGINX et VARNISH.

Code précompilé ou bytecode

Le bytecode (mot en anglais signifiant « code octal », en référence à l'octet informatique) est un code intermédiaire entre les instructions machines et le code source, qui n'est pas directement exécutable. Le bytecode peut être créé à la volée et résider en mémoire.
source : https://fr.wikipedia.org/wiki/Bytecode

Couplé à une machine virtuelle spécialisée, le bytecode permet une exécution beaucoup plus efficace que l’exécution des scripts non précompilés. Cette efficacité permet de gagner plusieurs dizaines, voire plusieurs centaines de millisecondes à l’exécution de chaque page web.


Fig. 3. gain de performance sur une page produit e-commerce :
https://blog.appdynamics.com/engineering/why-every-php-application-should-use-an-opcache/.

Il en résulte une tenue à la charge améliorée et un temps de réponse fortement réduit sur les pages qui exécutent beaucoup de script comme les pages de recherche ou la page de catégorie ecommerce.

Il existe plusieurs précompileurs de code. Par exemple, en PHP, il existe APC, OPCache ou encore ioncube.
OPCache est installé par défaut depuis PHP5.5 et est basé sur Zend Compiler, il est plus aisé de l’utiliser car il est natif à PHP.
OPCache met les code précompilé en mémoire, n’oubliez pas de redémarrer le service après une modification de vos scripts car sinon vous pourriez bien vous arracher les cheveux en ne voyant pas vos modifications après un refresh de la page.

Cache mémoire

Memcached est un système d'usage général servant à gérer la mémoire cache distribuée. Il est souvent utilisé pour augmenter la vitesse de réponse des sites web créés à partir de bases de données. Il gère les données et les objets en RAM de façon à réduire le nombre de fois qu'une même donnée stockée dans un périphérique externe est lue.
Source : https://fr.wikipedia.org/wiki/Memcached

Il existe plusieurs système de cache mémoire pour serveur, les plus connus sont Memcached et Redis. Ces deux solutions permettent de mettre en cache mémoire des objets informatiques au sens large. Cela peut être une page html complète mais également un objet php comme une session utilisateur ou un panier.

Ces objets étant disponibles en mémoire, le serveur web y accède directement sans avoir besoin de rebuter la base de donnée ni de lire un disque un dur, il en résulte un temps de réponse fortement réduit.

Redis dispose d’un jeu de contrôle de gestion du cache plus important que memcached. Redis propose également plus de type d’objets, la ou memcached ne propose que le type ‘string’, Redis propose également le ‘hash’, cette structure de donnée permet à Redis de persister les données en cas de redémarrage du service.

Memcached est multithread donc plus facilement scalable que Redis qui est monothread.

Enfin memcached est souvent déjà implémenté dans de nombreuses solutions et est donc plus facile à mettre en oeuvre que Redis.

Que vous choisissiez l’une ou l’autre solution, vous améliorerez votre temps de réponse car vous éviterez de solliciter la base de donnée ET le disque dur.

Cache fichier

Le cache fichier met en oeuvre le même mécanisme que le cache mémoire, mis à part le fait que la donnée est stockée sur le disque dur dans un fichier. Le type de fichier dépendra de la structure à cacher, cela peut être du html ou un objet sérialité en texte.

Comme la donnée est stockée dans un fichier, son temps d’accès dépend de la vitesse du disque dur et sera moins efficace qu’un cache mémoire, mais dans le cas d’un disque dur SSD, le cache fichier permettra d’accélérer les temps de réponse.
Il existe plusieurs type de cache fichier, le ‘mod_cache’ d’Apache est déjà disponible sur la plupart des hébergements, il est piloté par les entêtes http ‘cache-control’.

Les plugins de cache wordpress (comme wp-Rocket ou wp-super-cache) sont eux aussi des système de cache fichier, ils stockent dans des fichiers le html généré par WordPress pour éviter, entre autres, les requêtes vers la base de données à chaque appel.

Le cache fichier est souvent le système de cache le plus facile à mettre en oeuvre car il ne nécessite aucune brique logicielle supplémentaire et n’impose pas l’intervention d’un spécialiste.

Chainage

Chaque type de cache a ses spécificités et pour en tirer le meilleur parti il est possible d’en utiliser plusieurs et de les ‘chainer’. Il est par exemple judicieux de coupler le ‘reverse proxy’ au ‘cache de code’. En effe,t le bytecode va accélérer la génération de pages qui seront ensuite servie par le ‘reverse-proxy’.

De la même manière utiliser memcached (ou redis) avec un reverse proxy permettra de soulager le serveur web des parties non mises en cache par le reverse proxy comme le tunnel de vente.

Il est également possible d’imaginer d’autres scénarios de chainage, mais attention : plus vous mettez en oeuvre de systèmes de cache et plus leur synchronisation devient périlleuse et le débogage en cas de problème difficile.

Test de la performance

Une fois que vous aurez mis en place une ou plusieurs solutions de cache, il vous faudra vérifier que tout va bien. Il existe pour cela de nombreuse techniques, la plus simple est certainement d’utiliser l’outil PageSpeed Insights de Google ou encore de faire une requête Curl sur votre URL.

Mais il est également possible d’utiliser des outils en ligne spécialisés qui permettent de simuler la charge, mais également d’avoir le détail précis des goulots d’étranglement de votre site web. Nous vous recommandons les 3 services suivants qui sont complémentaires :

Conclusion

En mettant en oeuvre les techniques de cache que vous venez de découvrir, vous serez certainement capable de faire baisser votre TTFB autour de la demi seconde, et ce même s'il est élevé pour le moment. Il n’est pas rare de voir un TTFB passer de 3 seconde a 0,6 ou 0,5 seconde en mettant en place un reverse proxy couplé a un systeme de cache de code. Suivez bien nos conseils et bonne chance !


Benoît Chevillot Consultant SEO, DivioSeo (http://divioseo.fr)

 

 

Articles similaires :