Accéder au contenu principal

Le cache, un outil pour limiter l'utilisation des serveurs et de la bande passante

Il y a plusieurs types de caches mais il y a principalement deux catégories. Le cache navigateur qui va permettre d'optimiser le temps de chargement d'une page en stockant des données sur l'ordinateur du client et le cache serveur qui va permettre de générer du contenu statique sur le serveur et permettre de limiter le recours aux bases de données et de limiter la création de contenu à chaque demande de page.

Influencer le comportement du navigateur


Si votre serveur apache est installé avec le mod_expires, vous pouvez définir des délais d'expiration de votre contenu. C'est à dire le délai pendant lequel le navigateur peut conserver votre contenu. Il n'y a pas de formule magique et la configuration que vous devez choisir dépend grandement du contenu que vous fournissez. Cependant, en règle générale, on a tendance à dire que les images sont peu modifiées une fois en ligne.

Les directives s'écrivent comme suit dans le .htaccess par exemple :

ExpiresDefault "access plus 1 month"
ExpiresDefault "access plus 4 weeks"
ExpiresDefault "access plus 30 days"

ou

ExpiresByType text/html "access plus 1 month 15 days 2 hours"
ExpiresByType image/gif "modification plus 5 hours 3 minutes"

Vous trouverez plus d'information sur le site d'apache.
J'ai testé ça groupé à la minification des css et javascript sur une solution personalisé, le retour est suffisant pour un site ayant ce volume de visites. 

Stocker du contenu statique sur votre serveur dynamique


Penser sa logique de cache

En fonction des possibilités qu'offre votre serveur, votre framework ou votre CMS, votre logique de cache peut être différente. Elle dépend également de la portée du site et de son contenu. Je ne pense pas qu'il soit nécessaire d'avoir recours au cache pour un site dont l'audience est limitée pour des raisons de popularité. Par contre, si votre audience est large mais que vous peinez à vous positionner dans les moteurs de recherche à cause de la lenteur d'accès à vos pages, il est temps d'agir.
Une des première choses tout de même reste la compression du contenu javascript et css. Ensuite, si vous avez un blog, il peut être intéressant de cacher les pages en entier afin de limiter les recours à la base de données. Cela peut être fait simplement en générant les pages en html et en recréant le cache à chaque édition afin de garder des menus à jour.
Dans le cas d'une boutique ou si vous avez des participations d'utilisateur, la technique de cache devra inclure une notion de séparation des composants de la page. Vous pourrez par exemple cacher les menus, les textes qui ne peuvent être éditer par les utilisateurs lambda, la mise en page... Il n'est par contre pas judicieux de cacher le prix ou le stock dans le cas d'une boutique car ils sont fonction de plusieurs facteurs.

Utiliser les outils appropriés pour le stockage


En fonction du volume de visites et de votre infrastructure vous devrez choisir un stockage adéquat. Pour un site générant peu de visites, un stockage sous forme de fichier suffit, surtout si vous générez le cache de page entière. Dans le cas d'un site générant un nombre important de visites avec des appels à la base de données récurent, on préféra un système de gestion de base de données scalable qui permet des performances nettement meilleures que sur un système de fichiers. J'en ai fait l'expérience avec Magento et je peux affirmer que les temps de chargements sur deux sites à moyen et gros volumes s'en sont ressentis. L'utilisation de Redis a permis de délocaliser la charge serveur d'offrir des temps de réponse dignes des boutiques en question. Cela s'est très vite ressenti au niveau de l'indexation et enfin des ventes. Cela dit, il est nécessaire de choisir le CMS en fonction de ses besoins et de l'adapter au fur et à mesure.
Aujourd'hui, j'ai tenté l'expérience full page cache avec un wordpress sur un serveur mutualisé d'OVH, nous allons voir ce que ça donne. Pour info, le site est http://www.banques-assurances.fr/ et avant mise en cache, le robot de google mettait en moyenne 736 millisecondes pour accéder à une page.

Commentaires

Posts les plus consultés de ce blog

[PHP] Faire un petit MVC avec des routes

Pour bon nombre de petits projets, il n'est pas nécessaire de taper dans les frameworks MVC comme Zend ou Symphony qui sont très lourds et un petit truc maison doit suffire. Je vais essayer de donner quelques tuyaux pour pouvoir faire son MVC maison avec des routes qui dirigent vers les contrôleurs et les actions.
Tout d'abord, il faut créer un fichier index.php à la racine de votre site qui va contenir le lien vers tout ce dont vous avez besoin pour faire vos routes. Ensuite, vous devez créer un dossier controlleur (si vous voulez reproduire la faute de frappe de l'exemple) dans lequel vous aurez tous vos contrôleurs. Vous pouvez éventuellement diviser ce dossier en plusieurs dossiers distincts qui contiendront les différentes parties de votre site. Veillez à appeler vos classes en rapport avec vos règles de is_callable. Dans mon exemple, le chemin vers le dossier est en minuscule et la première lettre du fichier est en majuscule. Par exemple : la classe /controlleur/fro…

[Magento 2]Le système de cache

A la lecture de l'article d'Alan Kent sur le système de cache de Magento 2, on ne peut que se réjouir d'une vraie prise de conscience du problème qui avait été déjà pris en compte avec la mise en place des modules Redis de Colin Mollenhour dans Magento 1.8 qui avait permis d'améliorer considérablement les performances sur des Magento à moyen et gros volumes. J'avais pris l'initiative de mettre en place ces deux modules (Session et Backend) sur des 1.7 au grand soulagement des clients qui ont vu les temps de réponses s'améliorer avec un temps de chargement parfois divisé par trois.
Pour la future version de Magento, le système de cache se basera a priori sur un cache de page complète du type Varnish avec un chargement en Ajax pour les parties de la pages qui sont spécifiques à l'utilisateur. On pense notamment au récapitulatif du panier, aux liens vers les différentes parties du compte... En s'appuyant tout de même sur le cache du navigateur pour cac…

Ajouter un administrateur à Magento 1 en SQL

On vous balance sur un projet, vous devez récupérer la base de données et travailler dessus dans votre environnement de développement. Le problème est que vous n'avez pas d'accès à l'administration car vous n'avez pas d'utilisateur créé en production ou en staging. Ce n'est pas une fatalité !

Il est possible de créer facilement un utilisateur qui aura les rôles suffisants dans Magento avec seulement un accès à la base de données. Pour faire cela, il faut comprendre que les administrateurs sont inscrits dans une table et leur rôle dans une autre. Dans le script suivant, on créera un administrateur avec les pleins pouvoirs mais vous pouvez adapter ce script à vos besoin en jetant un oeil à la table admin_role et en modifiant parent_id dans le script. La colonne parent_id définit le parent du rôle en question pour l'utilisateur. Si vous voulez créer un utilisateur avec des pouvoirs différents, regardez le rôle qui correspond au pouvoir que vous accorder et mo…