Vos modifications WordPress ne s’affichent pas, qui garde l’ancienne page ?

Vous avez corrigé un horaire d’ouverture sur votre site, enregistré, rafraîchi la page. Le vieil horaire est toujours là.

Vous recommencez. Vous vérifiez que vous étiez bien sur la bonne page, vous enregistrez une seconde fois, et rien ne bouge. La question qui monte à ce moment-là n’a rien de technique. Est-ce que j’ai fait une bêtise… ou est-ce qu’il y a quelque chose qui ne marche pas ?

Presque jamais la première. Si WordPress vous a confirmé la mise à jour, votre modification est bien dans la base de données de votre site. Ce qu’on vous montre à l’écran est une copie de l’ancienne version, gardée par quelqu’un d’autre quelque part sur le trajet entre votre site et vos yeux.

Web designer freelance, je construis des sites WordPress sur-mesure et j’en assure ensuite la maintenance. C’est par là que ce sujet arrive chez moi, parce qu’un cache qui garde une page trop longtemps est un problème de site vivant. Sur celui que vous lisez, j’ai installé une couche de cache serveur en juillet 2026, je l’ai mesurée pendant six semaines, puis je l’ai retirée parce qu’elle n’apportait rien ici. Les chiffres de cet article viennent de ces relevés et de la documentation des éditeurs concernés, jamais d’une estimation.

Reste à savoir laquelle de ces copies vous bloque. Comment trancher en trente secondes entre votre écran et votre site, qui garde vos pages et pendant combien de temps, dans quel ordre on fait tomber ces copies, et les pièges qui donnent l’impression d’avoir tout vidé quand une copie résiste encore quelque part.

Où est passée votre modification ?

Elle est en base de données, enregistrée, et personne ne l’a perdue. Ce qui s’affiche à l’écran vient d’ailleurs.

Un site web évite de refabriquer sa page à chaque visite dès que quelqu’un peut lui épargner le travail. À plusieurs endroits du trajet, un logiciel garde une photocopie de la page telle qu’elle était la dernière fois, et la ressort au visiteur suivant. C’est un cache, et c’est ce qui rend les sites plus rapides. Le mot désigne cette pile de photocopies, rien de plus mystérieux.

Vous en avez un dans votre navigateur, votre hébergeur en a peut-être un sur son serveur, et votre site en héberge peut-être un troisième sous forme d’extension. Aucun des trois ne vous prévient quand c’est sa copie que vous regardez.

Chacune de ces piles se renouvelle à son propre rythme, et surtout, elles ne se parlent pas d’elles-mêmes. Jeter l’une ne jette pas les autres… et c’est de là que vient presque toute la confusion. C’est aussi ce qui explique qu’on puisse appuyer sur un bouton « vider le cache », voir un message de réussite, et continuer de regarder exactement la même vieille page.

Est-ce vous, ou est-ce le site ?

Ouvrez votre page dans une fenêtre de navigation privée, après avoir fermé celles qui seraient déjà ouvertes. Si votre modification y apparaît, votre site est parfaitement à jour et c’est votre propre navigateur qui vous ment.

Une fenêtre privée démarre avec une pile de photocopies vide. Elle est donc obligée de redemander la page, ce que votre fenêtre habituelle s’épargne depuis peut-être plusieurs heures. Le test coûte trente secondes et il tranche la seule question qui compte au départ, celle de savoir si le problème est chez vous ou plus loin.

Si la modification n’apparaît pas non plus en navigation privée, alors une des piles situées entre votre site et vous garde encore l’ancienne version, et la suite de cet article sert à trouver laquelle… à moins que le cache n’y soit pour rien, ce qui arrive aussi.

Sur l’ordinateur c’est bon, sur le téléphone c’est l’ancienne version

Chaque appareil garde sa propre pile, et vider celle de votre ordinateur ne touche pas à celle de votre téléphone. C’est déroutant la première fois, et c’est parfaitement normal.

Le cache du navigateur est un dossier de fichiers posé sur la machine de la personne qui regarde. Il n’y en a pas un pour votre site, il y en a un par appareil et même un par navigateur. Votre ordinateur en a un, votre téléphone en a un autre, et si vous ouvrez le même site dans un second navigateur sur le même ordinateur, celui-là a aussi sa propre pile.

Ce n’est donc pas votre connexion qui est en cause, et passer du wifi aux données mobiles ne change rien. Ce qui change tout, c’est l’appareil. Le corollaire est plutôt rassurant, d’ailleurs… La vieille copie de votre téléphone ne regarde que lui. Un visiteur qui arrive chez vous pour la première fois n’en a aucune, et reçoit ce que le site lui sert.

Qui garde une copie de votre page, et pendant combien de temps ?

Cinq couches peuvent garder une copie, et la page entière peut y rester figée jusqu’à une semaine avec les réglages d’origine de l’extension de cache la plus installée. Voici la carte, et chaque couche est détaillée plus bas.

Le navigateur, la copie que vous avez sous la main

Il n’existe aucune durée par défaut du cache navigateur, et c’est la réponse la plus surprenante de tout cet article. Quand personne ne lui dit combien de temps garder un fichier, le navigateur ne le jette pas pour autant. Il devine.

La norme qui régit la mise en cache sur le web, la RFC 9111, l’y autorise explicitement et écrit noir sur blanc qu’elle ne fournit aucun algorithme pour le faire. Elle se contente de suggérer un ordre de grandeur, une fraction du temps écoulé depuis la dernière modification du fichier, et précise qu’un réglage courant de cette fraction serait de dix pour cent.

Traduit dans votre quotidien, un logo modifié pour la dernière fois il y a un an peut rester environ cinq semaines dans le navigateur d’un visiteur. Et comme la norme laisse le calcul à chacun, deux navigateurs ont parfaitement le droit de choisir deux durées différentes pour le même fichier.

Rien de tout cela n’est réglé d’avance par votre site. Le module d’Apache qui pose ces durées est livré éteint, selon sa documentation, et la directive équivalente de NGINX également. Autrement dit, tant que personne n’a écrit cette durée quelque part, il n’y en a pas… et vous ne pouvez pas la connaître.

Le cache de page, celui qui répond avant WordPress

C’est la couche qui garde votre page entière, déjà fabriquée, et qui la ressert sans réveiller WordPress. C’est aussi la première suspecte quand une modification reste invisible.

Elle peut vivre à deux endroits. Sur le serveur, avec un logiciel comme Varnish ou LiteSpeed, avant même que votre site soit sollicité. Ou dans WordPress, sous forme d’extension. Les durées par défaut varient énormément, et elles sont rarement affichées là où on les cherche.

Une semaine, c’est le chiffre qui compte dans ce tableau. Sans purge automatique, une page publique servie par LiteSpeed peut légitimement rester figée sept jours, et rien à l’écran ne vous le dira.

Chez WP Rocket, la mécanique mérite d’être connue parce qu’elle déroute. La durée est bien de dix heures, mais l’extension ne surveille l’âge de ses fichiers qu’une fois par heure, selon sa documentation. Le ménage a donc lieu au premier contrôle qui suit le dépassement… pas à la dixième heure pile.

Les deux couches que personne ne vous montrera

Les deux suivantes travaillent bien plus profond, et la bonne nouvelle est qu’elles sont rarement en cause. Je les décris quand même, parce qu’on vous les citera peut-être un jour et qu’il vaut mieux savoir de quoi il retourne… surtout de la seconde.

Le cache d’objets est-il coupable ?

Sur un WordPress tel qu’il est livré, non, et c’est une couche de moins à soupçonner. La documentation de WordPress est formelle, le cache d’objets est non persistant par défaut, ce qui veut dire que ses données ne vivent qu’en mémoire et seulement le temps d’une seule requête.

Il travaille donc à chaque chargement de page et disparaît à la fin. Il ne peut pas vous servir quelque chose d’hier, puisqu’il ne se souvient de rien au-delà de la seconde en cours. La même page de documentation ajoute que la constante historique censée l’activer n’a plus aucun effet à elle seule.

Sauf si quelqu’un a installé une extension pour le rendre persistant, avec Redis ou Memcached. Là, il garde ses réponses entre les visites, et il devient un suspect à part entière. Votre hébergeur ou votre prestataire saura vous dire si c’est votre cas.

Anecdote qui aide à comprendre à quoi sert cette couche, WordPress s’en sert pour lui-même. Depuis sa version 6.2, la feuille de style globale d’un thème récent, celle qui fusionne vos couleurs et vos polices, est rangée dans ce cache d’objets à chaque calcul. Le cœur du logiciel s’épargne le travail exactement comme il épargne le vôtre.

Le code compilé, la couche dont personne ne parle

Elle ne concerne pas vos textes, elle concerne les fichiers du site, et aucune des pages françaises que j’ai consultées sur le sujet n’en dit un mot. PHP, le langage dans lequel WordPress est écrit, garde en mémoire une version traduite de chaque fichier pour ne pas la refaire à chaque visite.

Par défaut, ce mécanisme vérifie toutes les deux secondes si un fichier a changé sur le disque, selon le manuel de PHP. À cette échelle, il n’est jamais coupable. Sur le serveur de ce site, ce réglage est à cinq secondes, relevé le 4 septembre 2026, ce qui ne change rien à la conclusion.

Le problème apparaît quand cette vérification est désactivée, ce que font certains hébergements pour gagner en performance. Le manuel de PHP est clair sur ce cas, il faut alors réinitialiser à la main ou redémarrer le serveur web pour qu’une modification de fichier soit prise en compte. Un fichier corrigé peut alors n’avoir strictement aucun effet, quel que soit le nombre de caches que vous videz.

Cette couche-là se règle du côté de votre hébergeur ou de votre prestataire, et c’est tant mieux. Mais si votre prestataire vous dit qu’il a corrigé un fichier et que rien ne bouge, c’est une piste qu’il connaît.

Dans quel ordre faut-il vider ?

De votre site vers vous, en finissant par votre propre navigateur. La raison est mécanique.

Si vous videz votre navigateur en premier, il repart avec une pile vide, redemande la page… et récupère l’ancienne version que le serveur garde encore. Vous venez de re-télécharger le périmé, et il faudra tout recommencer. En partant du site, chaque étape que vous franchissez a déjà de la matière fraîche à vous donner.

1. Le cache de votre constructeur de pages, si votre site en utilise un. Il est séparé de celui de votre extension, et c’est le sujet d’une section entière plus bas.
2. Le cache de votre extension, dans WordPress. Un bouton de purge est presque toujours posé dans la barre noire en haut de l’administration.
3. Le cache du serveur, chez votre hébergeur. Il se vide le plus souvent depuis votre espace client, avec un bouton qui s’appelle en général « vider le cache ». Tous les hébergeurs n’en ont pas.
4. Le réseau de diffusion, si vous en avez un. Il garde ses copies au plus près de vos visiteurs, c’est donc lui qu’on vide après le serveur. Si personne ne vous a jamais parlé de CDN ou de Cloudflare, vous n’en avez sans doute pas… mais certaines offres d’hébergement en incluent un, et votre hébergeur vous le dira.
5. Votre navigateur, en dernier. Un rechargement forcé suffit dans la plupart des cas, avec les touches Ctrl et F5 sur Windows, ou Cmd et Maj et R sur Mac.

À ne pas confondre avec l’ordre du diagnostic, qui est exactement l’inverse. Pour savoir d’où vient le problème, on commence par soi, avec la fenêtre privée, parce que c’est gratuit et instantané. Pour réparer, on commence par le site. Chercher et corriger ne se font pas dans le même sens.

Les pièges qui font croire qu’on a tout vidé

Ils ont tous le même symptôme, un bouton appuyé, un message de réussite, et la même vieille page. Chacun est documenté par l’éditeur de l’outil concerné, ce qui veut dire que ce sont des comportements connus, pas des pannes.

1. Purger le réseau de diffusion ne touche pas votre navigateur. C’est Cloudflare lui-même qui l’écrit dans sa documentation. Le bouton « tout purger » vide les copies posées dans le monde entier, jamais celle qui dort sur votre disque dur.
2. Le mode développement contourne, il ne purge pas. Le réglage que Cloudflare propose pour travailler tranquillement suspend son cache pendant trois heures, sans supprimer un seul fichier. Au bout des trois heures, l’ancienne version peut ressortir intacte, si elle n’a pas expiré entre-temps.
3. Vous êtes connectée à votre administration. Par défaut, une page n’est pas mise en cache pour un utilisateur connecté, c’est écrit dans la documentation de WP Rocket. Vous voyez donc la bonne version pendant que vos clients voient encore l’ancienne.

« Purger le cache de Cloudflare n’a aucun effet sur les fichiers rangés par le navigateur d’un visiteur. »

Documentation Cloudflare, 14 août 2026

Et Cloudflare impose à ce navigateur une durée d’au moins quatre heures par défaut, sur ses quatre formules, gratuite comprise.

4. Votre feuille de style est un fichier à part. Une modification d’apparence peut rester bloquée dans le navigateur même après la purge de l’extension, cas que WP Rocket documente en français dans une page dédiée.
5. Le cache serveur sert du périmé exprès. Quand une copie expire, Varnish continue de la livrer le temps d’aller chercher la nouvelle, dans une marge de dix secondes par défaut selon son manuel, que l’hébergeur peut allonger de plusieurs heures. Une vraie purge, elle, efface la copie… si l’ancienne page revient après une purge, c’est qu’une autre couche la garde, ou que la purge n’est jamais arrivée jusqu’au serveur.
6. Deux caches de page peuvent se neutraliser. Chez o2switch, la documentation prévient que le cache serveur, combiné avec Cloudflare, bloque les mécanismes internes de purge. Le bouton s’exécute, ne renvoie aucune erreur… et n’a aucun effet. Certaines extensions savent se synchroniser avec un cache serveur, mais la règle la plus sûre tient en une phrase, un seul cache de page à la fois.
7. La purge automatique d’une extension est souvent partielle. Publier un article ne vide que sa page, l’accueil, la page des articles et quelques archives, d’après la documentation de WP Rocket. Si vous corrigez le titre d’un article et qu’une autre page, qui le présente en vignette, garde l’ancien, vous n’avez pas de bug. Vous avez une purge ciblée.

Le cas des constructeurs de pages, qui gardent leurs propres fichiers

Un constructeur de pages écrit souvent vos styles dans des fichiers séparés, qu’il faut alors régénérer à la main quand ils ne suivent plus. C’est une couche de plus, distincte des précédentes, et c’est la plus facile à oublier.

Chez Elementor, ce comportement est le réglage par défaut. Son fichier de configuration décrit deux méthodes possibles, l’une qui pose les styles directement dans la page et sert au dépannage, l’autre qui passe par un fichier externe pour de meilleures performances… et c’est la seconde qui est livrée d’origine.

L’éditeur le documente sans détour. Sa page d’aide écrit que des fichiers et des données en cache peuvent créer un écart entre ce qui s’affiche sur le site et ce que vous avez dessiné dans l’éditeur. Le bouton qui règle ça s’appelle « Clear Files & Data », il se trouve dans les outils d’Elementor, et il est aussi accessible depuis la barre noire en haut du site. La même page recommande de sauvegarder avant de l’utiliser.

Sur un site de ce type que j’ai eu à faire vivre pendant plusieurs années, il fallait presque systématiquement passer par ce bouton pour voir apparaître une modification de mise en forme. Ce n’était pas une panne, c’était le fonctionnement normal, et j’ai mis un certain temps à le comprendre.

Les autres constructeurs ont chacun leur variante, avec leurs propres mots. Bricks écrit ses fichiers dans un dossier dédié et propose un bouton de régénération, sa documentation précisant que son autre mode, celui qui pose les styles dans la page, est toujours à jour et ne met rien en cache. Beaver Builder range les siens dans un dossier de cache et les recrée tout seul à la mise à jour d’une page. Divi a sa génération de fichiers statiques, annoncée par son éditeur, avec un bouton pour les vider.

Ce que j’ai vu sur mes propres sites

Deux situations valent d’être racontées, parce qu’elles montrent qu’un cache peut mentir dans les deux sens. Dans la première, il annonçait travailler sans rien faire. Dans la seconde, il travaillait si bien qu’il a ignoré une consigne.

Le panneau annonçait un cache actif, et rien n’était jamais servi depuis le cache

Le 20 juillet 2026, j’ai relevé sur deux sites qu’aucune page n’était jamais resservie depuis un cache, alors que le tableau de bord de l’extension affichait le contraire. Chaque visite, y compris celle d’un robot, faisait tourner le site de bout en bout.

Le détail qui m’a mise sur la piste est presque comique. L’extension posait bien sa signature dans la réponse du serveur, à chaque appel, sans exception. Or cette signature n’est censée apparaître qu’au moment où une page est rangée dans le cache. Si elle revient à chaque fois, c’est qu’aucune page n’est jamais ressortie… L’extension parlait, le serveur ne l’écoutait pas.

La confirmation est venue d’une comparaison simple. On mesure le temps de réponse d’une page normale, puis celui de la même page avec un paramètre inventé au bout de l’adresse, ce qui oblige en général le serveur à la refabriquer. Si les deux durées sont identiques, rien n’est servi depuis le cache. Elles l’étaient, à quelques millièmes de seconde près, sur les quatre pages testées.

La leçon vaut pour tous les tableaux de bord de ce genre. Un panneau qui affiche « cache actif » décrit une intention, pas un résultat. Ce qui prouve qu’un cache travaille se lit dans les réponses du serveur, soit par la différence de temps entre une page servie et une page refabriquée, soit par la mention que certains caches ajoutent quand ils servent une copie.

Activer la maintenance ne fermait pas le site

Sur un autre site qui vend, l’audit des trois caches du 21 juillet 2026 a montré qu’activer la maintenance ne pouvait pas fermer le site. L’interrupteur fonctionnait… et le cache serveur aurait continué de servir les pages publiques.

La cause a été trouvée le même jour. Le mécanisme de purge n’existait tout simplement pas sur ce site. Aucune extension de liaison, aucune constante dans la configuration, rien. Le cache gardait donc ses copies, et la page de maintenance ne concernait que les visiteurs qui demandaient une page absente de ses piles.

Le même trou avait une conséquence beaucoup plus discrète et beaucoup plus gênante. Une modification de prix, de stock ou d’image produit n’apparaissait pas avant l’expiration naturelle du cache, soit jusqu’à une heure, et jusqu’à quatre en cas d’incident sur le serveur pendant ce délai. Rien ne le signalait, et le site répondait normalement tout du long.

Un cache peut-il faire disparaître vos messages de contact ?

Oui, et c’est l’effet le plus sournois de cette liste, parce que vous n’en voyez rien. Une page gardée trop longtemps peut finir par contenir un jeton de sécurité expiré.

Votre formulaire porte peut-être un petit code à durée limitée, valable entre douze et vingt-quatre heures avec les réglages de WordPress, qui sert à vérifier que l’envoi part bien d’une page de votre site. Si votre page de contact dort dans un cache depuis trois jours, elle transporte un code périmé.

Le visiteur remplit alors le formulaire, appuie sur envoyer, et reçoit une erreur de sécurité qu’il ne comprend pas. Le message n’arrive jamais. Et rien ne dit qu’il prendra la peine de réessayer…

C’est pour cette raison que j’ai réglé la conservation à une heure sur ce site, tant qu’il a eu un cache serveur, très en dessous du seuil de risque, plutôt que de profiter des durées confortables que permettent ces outils. Un site vitrine n’a rien à gagner à garder ses pages une semaine, et il a tout à perdre à ne plus recevoir ses demandes de devis.

Et si ce n’était pas le cache ?

Il reste une famille de causes qu’aucune purge ne résoudra, et la documentation officielle de WordPress lui consacre une section entière. Elle mérite d’être vérifiée avant de vider un huitième cache.

• Vous avez enregistré un brouillon. Le bouton d’enregistrement d’une page déjà publiée et celui d’un brouillon ne portent pas le même nom, et la confusion est très banale.
• Vous modifiez une autre page que celle que vous regardez. Deux pages au titre proche, une page et un article du même nom.
• Le texte que vous voyez ne vient pas de là où vous croyez. Un bloc réutilisé sur plusieurs pages, un élément de gabarit, un menu. On corrige la page, alors que le texte est ailleurs.

La documentation de WordPress propose un test que je trouve excellent parce qu’il ne demande aucune compétence. Une fois vos caches vidés, écrivez une modification délibérément voyante, un mot en majuscules au milieu du titre, et regardez. Si elle n’apparaît pas davantage, vous savez que vous n’éditiez pas le bon endroit. Vous l’effacerez ensuite… promis.

Ce que vous pouvez régler seule, et ce qui demande votre hébergeur

Vous pouvez presque tout faire seule. L’exception est le cache du serveur, qui vit avant votre site et n’en fait pas partie. C’est votre hébergeur qui décide si vous avez la main dessus.

J’ai lu la documentation de cinq hébergeurs français, et il n’en sort aucune règle. Chez o2switch et PlanetHoster, le serveur sait le faire mais le client doit l’activer, en deux gestes explicites. Chez Infomaniak, je n’ai trouvé le moteur de cache décrit que sur les offres de Serveur Cloud. Chez LWS, à l’inverse, la technologie est décrite comme déployée sur tous les hébergements mutualisés récents. Et chez OVHcloud, je n’ai trouvé aucun cache de pages décrit sur mutualisé, seulement une option de réseau de diffusion incluse dans certaines formules.

Hostinger décrit un gestionnaire du cache de son serveur dans son tableau de bord. Pour Ionos, je n’ai pas trouvé la réponse dans son centre d’aide. Autrement dit, vous ne pouvez pas le deviner depuis votre écran, et personne ne peut le deviner à votre place.

« Il est recommandé de s’assurer que votre hébergeur n’utilise pas un cache serveur sans vous en tenir explicitement informé·e. »

Documentation WordPress, Dion Hulse, mise à jour le 19 novembre 2021

C’est le meilleur conseil de tout cet article, et il vient du logiciel lui-même. Un message au support de votre hébergeur, avec une seule question, y a-t-il un cache serveur sur mon offre et comment je le vide.

Quand ce genre de question revient trop souvent, elle finit par faire partie de ce qu’on délègue, et c’est précisément ce que couvre un contrat de maintenance, dont j’ai détaillé le contenu réel dans un autre article.

Une page en retard n’est pas une page perdue

Revenons à l’horaire d’ouverture du début. Si c’était bien un cache, il est enregistré depuis la première seconde, il n’a jamais bougé de votre base de données, et tout ce que vous avez vu depuis n’était qu’une photocopie qui n’avait pas encore été remplacée.

Ce qui rend ce problème si désagréable, ce n’est pas tant sa gravité que la façon dont il vous laisse seule devant un écran qui a l’air de vous dire que vous vous y prenez mal. Quand c’est un cache, vous n’avez rien fait de travers… un mécanisme d’accélération a simplement une longueur de retard sur vous.

Trois gestes suffisent la prochaine fois. La fenêtre privée pour savoir si c’est vous, la purge du site vers votre écran pour réparer, et la question à votre hébergeur pour ne plus jamais vous la poser. Le reste de cet article n’est là que pour les jours où ces trois-là ne suffisent pas… et ces jours-là existent.

Questions fréquentes

Sources

Les citations en anglais ont été traduites par Graph’Web Studio. Le texte d’origine est accessible via les liens.

Textes officiels et institutions

• IETF, RFC 9111, HTTP Caching, section 4.2.2 sur la fraîcheur estimée

Documentation officielle d’un éditeur

• WordPress, Je fais des modifications sur mon site WordPress et rien ne se passe, Dion Hulse, 11 mars 2019, mis à jour le 19 novembre 2021
• WordPress, documentation de la classe WP_Object_Cache et de l’interface des transients
• PHP, configuration de l’OPcache
• Varnish 7.1.1, page de manuel de varnishd, paramètres default_ttl et default_grace
• LiteSpeed, valeurs de conservation par défaut du cache
• Cloudflare, durée du cache navigateur et portée d’une purge et mode développement
• WP Rocket, durée de conservation du cache, fréquence de mise à jour et les modifications CSS qui ne s’affichent pas
• Elementor, Clear Files & Data, mise à jour le 20 janvier 2026
• Bricks, réglages et régénération des fichiers CSS ; Beaver Builder, onglet Outils ; Elegant Themes, génération de fichiers CSS statiques pour Divi
• Apache, module mod_expires ; NGINX, module headers ; MDN, guide de la mise en cache HTTP

Documentation officielle d’un hébergeur

• o2switch, activer le cache LiteSpeed et xtremCache et son incompatibilité avec Cloudflare
• LWS, utiliser les modules de cache sur LWSPanel
• PlanetHoster, installer et activer l’extension LSCache, 12 août 2026
• Infomaniak, optimiser un site surchargé, mise à jour le 1er septembre 2026
• OVHcloud, option CDN des hébergements web, source officielle du guide, mise à jour le 27 octobre 2025
• Hostinger, utiliser le gestionnaire de cache, mise à jour le 15 septembre 2026

Relevés de Graph’Web Studio

• graphwebstudio.com, diagnostic de cache sur deux sites, en-têtes servis et test de contournement, 20 juillet 2026
• graphwebstudio.com, audit des trois couches de cache d’un site marchand, 21 juillet 2026
• graphwebstudio.com, relevé de la configuration de l’OPcache du serveur, 4 septembre 2026
• graphwebstudio.com, relevé des durées de conservation par défaut de sept extensions de cache, 4 septembre 2026

Écrit par Alexandra Dubois Webdesigner freelance, spécialisée dans la création de sites WordPress sur-mesure avec l’éditeur de site natif, en Full Site Editing (FSE). Faisons connaissance →

Partager cet article

Ce sujet peut intéresser votre réseau ? Faites-le circuler.