Table des matières de l'article :
Aujourd'hui, nous allons parler de quelque chose qui, semble-t-il, est souvent négligé dans le monde de l'hébergement, tant par les développeurs que par les administrateurs système : les en-têtes HTTP.
Imaginez conduire une Ferrari de F1, une voiture puissante et rapide, mais à la condition que vous ne sachiez pas vraiment comment conduire une voiture de Grand Prix à son plein potentiel. Que pensez-vous qu'il en sortira ? Gagner la course ou assurer une sortie de piste dès le premier tour ?
Mais faisons une petite prémisse, ou peut-être un exutoire. Le monde de l'hébergement de nos jours est, malheureusement, un gâchis. Avec la guerre des prix lancée depuis des années par les Hébergeurs qui vendent des forfaits d'hébergement à 100 euros par an (mais on en a aussi vu à 30 euros), l'industrie de l'hébergement est devenue une machine à sous qui scale brillamment la vente de ses services, mais ne scale pas du tout l'application et les sites de leurs clients. Bref, c'est un business très lucratif mais avec très peu d'attention aux besoins réels du client et aux problèmes intrinsèques que cache normalement tout projet créé en « assemblant » des plugins comme WordPress.
Lorsque le webmaster de l'entreprise qui a mandaté un e-commerce (sur WooCommerce, Prestashop ou Magento, peu importe) entre dans le jeu en achetant un plan d'hébergement et en le payant par carte de crédit, les identifiants pour le panneau de contrôle, le FTP et la base de données lui sont automatiquement délivrés et, au final, les paramètres de certains caches plus ou moins valides sont configurés.
De plus, il faut prendre en compte par exemple que la plupart des développeurs de plugins WordPress, habitués au "code spaghetti", ignorent parfaitement les en-têtes HTTP et leur fonctionnement, ce qui conduit à des sites avec une mise en cache côté serveur qui fonctionnent presque comme s'ils n'avaient pas de cache du tout. En conséquence, le client se retrouve avec un site lent, ce qui génère de la frustration chez les utilisateurs finaux, provoquant des abandons, moins de ventes, moins de chiffre d'affaires et moins de profit.
Presque tous les problèmes de vitesse sur les serveurs qui ont encore les bonnes exigences pour être rapides, proviennent précisément des en-têtes HTTP, comme le Cache-Control. Cet en-tête est destiné à gérer à la fois la mise en cache côté navigateur et côté serveur ou proxy inverse. Une utilisation incorrecte de l'en-tête HTTP Cache-Control peut entraîner une expiration trop prématurée du cache côté serveur, ce qui ralentit un site même avec la mise en cache côté serveur.
Souvent, il est de bonne pratique et beaucoup plus pratique de prendre en charge la production du site client et d'ignorer les en-têtes HTTP Cache-control au niveau du serveur qui pourraient être incorrects ou provenir de plugins installés avec la fonctionnalité pseudo Application Cache qui invaliderait le cache côté serveur.
Là encore la comparaison avec Ferrari : un bon hébergement orienté performances est potentiellement une Formule 1, mais le client ou le développeur, non expert dans la conduite d'une F1 à son plein potentiel, doit nécessairement être limité par certains dispositifs, comme le contrôle électronique de la traction et du freinage, afin d'éviter les hors-piste. Dans notre cas, par exemple, une fois que nous avons vérifié que l'application envoie des en-têtes HTTP incorrects, nous nous limitons à ignorer certains en-têtes si nous voyons qu'ils produisent des problèmes de persistance du cache, le rendant pratiquement inutile ou presque inutile.
Contrôle du cache d'en-tête et contournement du cache
Varnish Cache et FastCGI Cache sont deux outils de mise en cache populaires utilisés pour accélérer les sites Web et réduire la charge sur les serveurs principaux. Cependant, Varnish Cache et FastCGI Cache respectent les en-têtes Cache-Control.
Vernis Cache
Varnish Cache est un accélérateur HTTP extrêmement rapide, flexible et performant. Utilisez la mise en cache en mémoire pour stocker des copies des réponses HTTP et les servir plus rapidement lors de requêtes ultérieures.
Supposons que votre serveur envoie la réponse suivante :
HTTP/1.1 200 OK Cache-Control : no-cache Content-Type : text/html Bonjour le monde!
Dans ce cas, même si la réponse est mise en cache dans Varnish, pour chaque demande ultérieure, Varnish enverra une demande de validation au serveur d'origine avant de servir la ressource mise en cache. Si la ressource n'a pas changé, le serveur d'origine répondra avec un statut HTTP de 304 (non modifié) et Varnish servira la ressource à partir du cache. Si la ressource a changé, le serveur enverra la nouvelle ressource, que Varnish mettra en cache et servira au client.
Cache CGI rapide
De même, FastCGI Cache est une méthode de mise en cache basée sur Nginx et FastCGI qui peut être utilisée pour mettre en cache des pages HTML entières ou d'autres types de contenu. Cela fonctionne de la même manière en ce qui concerne le vernis en ce qui concerne la directive Cache-Control: no-cache.
Si tu utilises Cache-Control: no-cache, FastCGI Cache enverra une demande de validation au serveur principal avant de servir la ressource à partir du cache. Si la ressource a changé, le serveur principal répondra avec la nouvelle ressource, que FastCGI Cache mettra en cache et servira au client.
En conclusion, l'utilisation de l'en-tête Cache-Control: no-cache peut être une solution efficace lorsque vous souhaitez avoir un contrôle granulaire sur le comportement du cache pour des ressources spécifiques. Cependant, il est important de se rappeler que chaque demande de validation entraîne une certaine latence, d'où la surutilisation de no-cache peut affecter négativement les performances du site Web.
Le problème de l'utilisation sans le savoir d'un contrôle de cache incorrect.
La gestion du cache Web, bien que cruciale pour les performances du site, est souvent négligée ou mal comprise par les développeurs et les clients. Le client, dans la plupart des cas, n'a pas les compétences techniques pour identifier une mauvaise utilisation de l'en-tête Cache-Control ou pour vérifier que le cache fonctionne correctement. Cela devient un problème lorsqu'il s'agit d'optimiser l'expérience du visiteur ou l'évolutivité du site.
D'un autre côté, certains développeurs, en particulier ceux qui travaillent sur des plateformes comme WordPress, adoptent souvent une approche connue sous le nom de "code spaghetti". Ce terme fait référence à une structure de code désorganisée, complexe et difficile à suivre ou à maintenir. C'est une façon d'écrire du code qui peut entraîner divers problèmes, notamment des inefficacités, des erreurs difficiles à retracer et, dans le contexte de notre discussion, une mauvaise utilisation des en-têtes. Cache-Control.
Dans certains cas, les développeurs de plugins WordPress peuvent utiliser l'en-tête Cache-Control: no-cache sans bien comprendre ses implications. Ils peuvent penser que "sans cache" est un moyen infaillible d'éviter les problèmes de cohérence des données, alors qu'en fait, cela empêche l'utilisation efficace du cache, ce qui peut être désastreux dans un environnement d'hébergement hautes performances où vous souhaitez mettre en cache autant que possible.
Ce problème est aggravé par le fait que même de nombreux administrateurs système ne comprennent pas entièrement le rôle de l'en-tête Cache-Control. On pourrait facilement installer une pile de logiciels avec une mise en cache pleine page intégrée, sans jamais se demander si cette configuration particulière est appropriée pour le site en question. Ils ne se demandent pas s'ils réduisent réellement la latence et améliorent le Time to First Byte (TTFB), ou s'ils ajoutent simplement un "effet cosmétique", c'est-à-dire en affichant des en-têtes de réponse HTTP indiquant l'utilisation d'un système de mise en cache qui, en raison d'une mauvaise utilisation de Cache-Control, est contourné.
Par exemple, vous pouvez toujours voir des résultats "MISS" ou des valeurs "Age 0", indiquant que la ressource n'a pas été traitée à partir du cache comme prévu. Le résultat est un environnement qui semble être optimisé pour les performances, mais qui ne tire pas pleinement parti du cache.
Bad Cache Controls et CDN comme CloudFlare par exemple.
Les réseaux de diffusion de contenu (CDN) comme CloudFlare sont conçus pour améliorer les performances d'un site Web en distribuant son contenu sur un réseau mondial de serveurs. Ces CDN, suivant les normes et les meilleures pratiques de l'industrie, sont automatiquement configurés pour respecter les en-têtes Cache-Control ils reçoivent. Par exemple, si un en-tête vient avec Cache-Control: no-cache, CloudFlare contournera automatiquement son cache, comme vous vous en doutez.
Cependant, ce comportement peut devenir problématique en présence d'en-têtes Cache-Control mal configuré. CloudFlare, comme les autres CDN, fonctionne comme un proxy inverse, fonctionnant sur des versions personnalisées de NGINX (avant d'adopter sa propre solution propriétaire, Pingora). Donc, si un plugin ou une autre partie du site envoie un en-tête Cache-Control: no-cache inutile ou inapproprié, CloudFlare honorera cet en-tête, en contournant le cache et en transmettant la requête GET au serveur d'origine. Ce comportement peut avoir un impact important sur les performances du site, en particulier si vous utilisez des plans de service premium comme les plans d'affaires de CloudFlare ou des extensions comme l'optimisation automatique de la plate-forme (APO) de CloudFlare.
Optimisation automatique de la plateforme (APO) par CloudFlare est un service qui améliore encore les performances du site grâce à l'optimisation de la mise en cache et à la minification des fichiers. Mais même avec APO, si un plugin envoie un en-tête Cache-Control: no-cache, le CDN respectera cet en-tête et contournera le cache, ce qui affectera les performances.
La situation est encore compliquée par le fait que de nombreux développeurs et administrateurs système ne sont pas suffisamment compétents ou observateurs pour détecter quand quelque chose ne fonctionne pas comme il se doit. La clé pour éviter ces problèmes est une gestion soigneuse des en-têtes Cache-Control, en s'assurant qu'ils sont utilisés correctement et uniquement en cas de besoin. Si l'attention requise n'est pas accordée à cet aspect, vous risquez de saboter involontairement l'efficacité d'un CDN comme CloudFlare, annulant les investissements réalisés dans les plans et services premium.
Notre approche système sur mesure.
Une des raisons pour lesquelles nous préférons avoir une petite conversation à chaque demande de devis est de comprendre la préparation de ceux qui nous font face. Il n'y a rien de mal à ne pas connaître certains aspects du système en profondeur. Dans presque tous les cas, à l'exception de quelques groupes d'édition de premier plan, très importants sur la scène italienne, tous les autres ne prêtent pas la moindre attention à la responsabilité que l'on a d'utiliser correctement les en-têtes HTTP, mais laissent les différents plugins installés les envoyer à leur guise sans même comprendre pourquoi.
Suivre un client dans la mise en place d'un site et prêter attention aux en-têtes potentiellement erronés, est un effort de temps et de ressources qui ne peut être vendu au prix d'un hébergement à bas prix, qu'ils vantent avec des slogans et des gains plutôt pittoresques, tous auto-célébrant car ils sont le meilleur hébergement. Alors si tout le monde est le meilleur, quelque chose ne colle pas, n'est-ce pas ?
Cependant, cet effort initial, qui implique nécessairement un coût beaucoup plus élevé que les forfaits low cost habituellement trouvés sur le marché, tend à donner au client la solution définitive à ses vrais problèmes de vitesse. Ainsi, nous garantissons une expérience utilisateur fluide et rapide, un TTFB inférieur à 50 millisecondes et un pourcentage de HIT Ratio supérieur à 95%. En d'autres termes, presque toutes les pages sont servies immédiatement à partir du cache côté serveur.
Réclamez les performances que vous méritez. Assurez-vous que votre site Web fonctionne à son plein potentiel!
Êtes-vous fatigué de voir les performances de votre site web ralentir à cause d'une mauvaise utilisation des en-têtes HTTP ? Craignez-vous que votre cache fonctionne mal, affectant l'expérience de vos utilisateurs et votre classement SEO ?
Tu n'es pas seul. Trop de sites Web sont victimes d'une mauvaise gestion du cache, souvent sans qu'ils en soient conscients. Mais il n'a pas à être de cette façon. Avec les bons conseils, vous pouvez maximiser les performances de votre site Web, en garantissant une expérience utilisateur fluide et rapide et un Time to First Byte (TTFB) inférieur à 50 millisecondes.
Nous pouvons t'aider. Nous sommes experts dans l'optimisation des performances des sites Web et avons l'expertise nécessaire pour identifier et corriger les en-têtes HTTP mal configurés qui peuvent saboter votre cache. Nous sommes là pour vous aider à tirer le meilleur parti de votre CDN en nous assurant que chaque page de votre site Web est servie presque instantanément à partir du cache du serveur.
Il est temps d'agir.
Contactez-nous dès aujourd'hui pour une consultation et découvrez comment nous pouvons vous aider à améliorer les performances de votre site Web. Ne laissez pas une mauvaise utilisation des en-têtes HTTP limiter votre succès en ligne. Sécurisez votre avenir numérique grâce à nos conseils d'experts.
N'attend pas.
