L’essentiel
- Mesurez le TTFB d'une page et celui d'un fichier statique avant de toucher au site.
- Si le fichier statique est lent lui aussi, la cause est chez l'hébergeur : aucune extension ne la corrige.
- Le cache de page de nexya Pro se vide tout seul, y compris après un enregistrement Elementor, et vide aussi Cloudflare depuis la version 1.2.31.
- Une page périmée vient souvent d'une couche de cache qui n'est pas avertie : navigateur, hébergeur, CDN ou seconde extension.
- Le nettoyage de la base est gratuit dans le module Maintenance. Le nettoyage programmé fait partie de nexya Pro.
Site WordPress lent : deux problèmes qui se ressemblent
Sur les forums WordPress.org, la question d'un site WordPress lent revient souvent, et elle mélange presque toujours deux situations. Dans la première, la page met plusieurs secondes avant de commencer à s'afficher. Dans la seconde, elle s'affiche vite, mais dans une version que vous avez déjà modifiée.
Le premier cas concerne le temps de réponse du serveur. Le second, un cache qui n'a pas été vidé au bon moment. Les gestes à faire ne sont pas les mêmes, et un cache de page ne règle pas tout.
Cet article explique comment faire la différence, ce que le cache de page de nexya Pro prend en charge et ce qu'il ne peut pas faire. Il montre aussi ce que la version gratuite apporte déjà du côté de la base de données.
Commencer par mesurer : le temps avant le premier octet
Avant de changer quoi que ce soit, mesurez. Le chiffre utile s'appelle le TTFB, pour Time To First Byte : c'est le temps qui sépare la demande du navigateur du premier octet renvoyé par le serveur. Vous le trouvez dans l'onglet Réseau des outils de développement du navigateur, en cliquant sur la première ligne, celle du document.
Faites la mesure en navigation privée, pour ne pas être connecté au site, et chargez la même page deux fois de suite. Comparez ensuite avec un fichier statique du même site, par exemple une image de la médiathèque. Ce fichier ne passe pas par WordPress.
Ces trois chiffres suffisent, la plupart du temps, à savoir où se trouve le problème.
- La page est lente, le fichier statique rapide : le temps se perd dans WordPress, ses extensions ou sa base de données.
- Le fichier statique est lent lui aussi : le temps se perd avant WordPress, chez l'hébergeur ou sur le réseau.
- La deuxième visite est rapide et la première lente : un cache fonctionne, mais il se reconstruit souvent.
Quand la lenteur vient de l'hébergeur
Un des sujets du forum décrit un TTFB d'environ cinq secondes, alors que PHP et la base de données répondent vite. Dans une situation comme celle-ci, la cause se trouve le plus souvent en amont de WordPress : un serveur mutualisé saturé, une configuration réseau, un proxy, une résolution DNS lente.
Aucune extension ne corrige ce qui se passe avant que WordPress démarre, nexya pas plus qu'une autre. Un cache de page économise le travail de WordPress, mais il ne raccourcit pas le chemin entre le visiteur et le serveur.
La bonne démarche consiste à écrire à l'hébergeur avec vos mesures : le TTFB de la page, celui du fichier statique, l'heure du test. Avec ces chiffres, le support peut voir que le problème ne vient pas de votre code.
Si un simple fichier image met plusieurs secondes à arriver, le problème ne vient pas de WordPress.

Ce que fait le cache de page de nexya Pro
Le cache de page fait partie de nexya Pro, vendu sur nexya.dev et livré par Freemius après l'achat. La version gratuite n'en contient pas le code. nexya Pro remplace l'extension gratuite et garde les mêmes réglages.
Le principe est simple. Chaque page est gardée sous forme de fichier, puis servie au visiteur suivant avant que WordPress ne se charge. Quand quelque chose modifie la page, le fichier est jeté. La purge est automatique, y compris quand vous enregistrez une page dans Elementor.
Depuis la version 1.2.31, le cache de Cloudflare se vide en même temps que celui de nexya : en entier, ou seulement pour les adresses de la page modifiée. Depuis la 1.2.34, la page d'accueil d'un site qui redirige selon la langue du navigateur est de nouveau servie depuis le cache. Seule une première visite dont le navigateur demande une autre langue du site passe par WordPress.
Comme tous les modules nexya, le cache s'allume et s'éteint depuis le hub. Tant qu'il est éteint, il n'enregistre rien et aucun de ses hooks ne tourne sur le site.
Remettre le cache en ordre, en quatre étapes
-
1
Mesurer le TTFB
En navigation privée, notez le TTFB d'une page chargée deux fois, puis celui d'une image de la médiathèque. Si l'image est lente elle aussi, écrivez à l'hébergeur en joignant ces chiffres.
-
2
Ne garder qu'un seul cache de page
Videz puis désactivez toute autre extension de cache de page. Allumez ensuite le cache depuis le hub nexya.
-
3
Relier Cloudflare si le site l'utilise
Avec nexya Pro, le cache de Cloudflare se vide avec celui du site, en entier ou seulement pour la page modifiée. Vérifiez aussi si l'hébergeur ajoute son propre cache.
-
4
Alléger la base
Exportez la base depuis le module Maintenance, puis lancez le nettoyage. Servez-vous de l'écran de performance pour repérer ce qui pèse dans l'autoload.
Le cache affiche une ancienne version : où chercher
Si les visiteurs voient une page périmée, c'est généralement qu'une couche de cache n'a pas été avertie de la modification. Il peut y en avoir plusieurs les unes sur les autres : le navigateur, une extension de cache, le cache du serveur proposé par certains hébergeurs, puis un CDN.
Deux extensions de cache de page actives en même temps se gênent : chacune garde sa copie, et en vider une ne vide pas l'autre. Gardez-en une seule. Si vous choisissez celle de nexya, désactivez l'autre et videz-la avant.
Un autre sujet du forum parle d'un shortcode qui ne se met pas à jour. Un cache de page enregistre le résultat de la page tel quel. Un shortcode qui affiche une information changeante reste donc figé dans le fichier jusqu'à la prochaine purge. C'est le fonctionnement normal d'un cache de page, pas une panne.
- Testez en navigation privée pour écarter le cache du navigateur.
- Vérifiez si l'hébergeur ajoute son propre cache et comment le vider.
- Si le site passe par Cloudflare, vérifiez que sa purge est reliée à celle du site.
- Ne gardez qu'une seule extension de cache de page.

Alléger la base : l'écran de performance et le nettoyage
Si les mesures montrent que le temps se perd dans WordPress, regardez aussi la base de données. Certaines options sont chargées automatiquement à chaque page : c'est l'autoload. Des extensions supprimées depuis longtemps y laissent parfois des données. L'écran de performance de nexya aide à repérer ce qui pèse dans l'autoload.
Le module Maintenance, gratuit, nettoie la base de données et sait l'exporter. Faites toujours un export avant un nettoyage, pour pouvoir revenir en arrière. Le nettoyage programmé, qui revient tout seul à intervalle régulier, fait partie de nexya Pro.
Une base plus légère ne remplace pas un cache de page, et un cache ne remplace pas une base saine. Les deux se complètent. Mais ni l'un ni l'autre ne corrige un hébergeur trop lent.
Questions fréquentes
Le cache de page est-il inclus dans la version gratuite de nexya ?
Non. Le cache de page est l'un des trois modules ajoutés par nexya Pro, vendu sur nexya.dev. La version gratuite n'en contient pas le code.
Faut-il vider le cache après avoir modifié une page dans Elementor ?
Avec le cache de nexya Pro, non. La purge est automatique, y compris quand vous enregistrez dans Elementor.
Le cache de nexya vide-t-il aussi Cloudflare ?
Oui, depuis la version 1.2.31 : le cache de Cloudflare se vide en même temps que celui de nexya, en entier ou seulement pour les adresses de la page modifiée.
Un cache de page corrige-t-il un TTFB élevé ?
Il aide quand le temps se perd dans WordPress. Si le délai vient de l'hébergeur ou du réseau, ce que montre un fichier statique lent lui aussi, le cache ne le corrige pas.
Les modules de cet article
Essayez nexya Pro 7 jours, gratuitement
Tous les modules, les formulaires, les newsletters et le cache de pages, sur votre site. Sans engagement.