WordPress : réduire une première réponse serveur lente malgré une page légère

Une page légère peut demander longtemps au serveur

Votre page contient peu d’images et de scripts, mais le navigateur attend avant de recevoir son contenu. Le TTFB, ou délai avant le premier octet, aide à situer cette attente. Dans une mesure de navigation, il peut inclure les redirections, la recherche de l’adresse réseau et la connexion sécurisée, puis l’attente de la réponse. Il ne mesure donc pas uniquement la vitesse de PHP.

Une petite page peut demander une requête complexe à la base de données ou attendre un service externe. À l’inverse, un document servi rapidement peut ensuite afficher lentement sa grande image. Ce guide vise le premier cas : une navigation qui aboutit, avec une attente initiale importante. Une erreur 504, une image lente ou une administration seule ralentie nécessitent leur diagnostic propre.

Le résultat recherché est une réduction répétable du délai, avec le contenu et les fonctions attendus. Le repère de 0,8 seconde proposé par web.dev aide à orienter l’analyse ; ce n’est ni une garantie pour chaque visite ni un Core Web Vital autonome.

Préparer un relevé qui permette de comparer

Commencez sans installer d’extension. Il vous faut l’adresse publique concernée et un navigateur récent. Notez l’heure avec son fuseau, le réseau utilisé et votre état de connexion à WordPress. Choisissez une page de lecture ordinaire, puis une seconde page du même site. Écartez les URL de paiement, de déconnexion et les liens qui lancent une action.

Effectuez quelques ouvertures espacées, sans lancer de test de charge. Conservez les valeurs individuelles : une première visite lente suivie de visites rapides n’a pas la même signification qu’une lenteur constante. Une comparaison réalisée depuis un autre réseau peut aider, mais elle change aussi le trajet et parfois le serveur CDN sollicité.

Pour modifier du contenu, des extensions ou le cache, il faudra ensuite les droits correspondants. Sur un multisite, certains réglages dépendent du superadministrateur. Sur WordPress.com, utilisez les outils fournis par l’hébergement ; ne transposez pas des instructions de serveur privé. Avant les essais qui changent le fonctionnement, préparez une copie avec sauvegarde des fichiers et de la base, et neutralisez paiements, courriels et synchronisations sortantes.

Approche 1 : trouver la phase lente dans le navigateur

Ce parcours convient à toute personne pouvant ouvrir la page publique. Dans Chrome, le panneau Réseau permet de séparer la connexion, l’attente et le téléchargement. Les libellés anglais correspondants sont Network, Headers et Timing. L’option qui désactive le cache du navigateur ne désactive pas les caches du serveur.

Le résultat attendu est l’identification de la phase dominante sur le document HTML. Si le document arrive vite mais que l’affichage tarde, poursuivez l’analyse du rendu plutôt que le réglage de PHP. Pour terminer, fermez les outils et rétablissez les options de capture modifiées.

1. Ouvrez les outils de développement avec F12, puis Réseau. Activez Conserver le journal pour garder les éventuelles redirections et laissez la limitation réseau désactivée.
2. Ouvrez l’adresse choisie. Sélectionnez la requête de type Document correspondant à la page, plutôt qu’une image ou une requête publicitaire.
3. Dans En-têtes, relevez le statut et l’adresse finale. Dans Chronologie, comparez DNS, connexion, Waiting (TTFB) et téléchargement du contenu.
4. Si des réponses 301 ou 302 précèdent le document, relevez chaque destination. Répétez quelques fois dans les mêmes conditions et gardez une capture des durées.

Corriger un lien qui impose une redirection inutile

Cette correction convient lorsque vous maîtrisez un lien interne qui passe inutilement par une ancienne adresse avant d’ouvrir la bonne page. Elle demande le droit de modifier la page contenant ce lien. Ne supprimez pas la redirection qui protège encore les anciens liens externes : corriger la source du lien suffit ici.

Par exemple, un bouton peut viser une ancienne URL HTTP qui redirige vers une variante du domaine, puis vers la destination HTTPS. Remplacez sa cible par l’adresse finale vérifiée. Cela raccourcit ce parcours ; cela ne réduit pas le temps de calcul du document final. Si l’attente demeure sur une ouverture directe, passez au cache et au travail de WordPress.

1. Copiez l’adresse finale du document qui répond correctement. Vérifiez qu’il s’agit du bon contenu et du domaine prévu.
2. Dans Pages, ouvrez la page d’origine avec Modifier. Sélectionnez le lien ou le bloc Bouton, ouvrez son réglage de lien et conservez l’ancienne cible dans vos notes.
3. Remplacez uniquement cette cible, appliquez le lien et enregistrez la page.
4. Ouvrez le lien public et contrôlez sa destination dans Réseau. Pour annuler, remettez l’ancienne cible conservée ; si une mauvaise destination apparaît, corrigez-la avant de poursuivre.

Mesure facultative avec curl depuis votre ordinateur

Un utilisateur disposant de curl peut mesurer une requête GET sans télécharger les images et scripts associés. Exécutez cet exemple dans un terminal Linux ou macOS, en remplaçant l’adresse fictive par la page publique choisie. Sous PowerShell Windows, utilisez curl.exe et remplacez /dev/null par NUL. Ne collez pas cette commande dans un fichier WordPress.

Les valeurs sont en secondes, mesurées depuis le début de l’opération. Elles ne représentent pas des durées indépendantes à additionner. L’exemple ne suit pas les redirections : un statut 301 mesure cette première réponse, pas la page finale. Il faut alors mesurer séparément sa destination publique vérifiée. Le délai maximal de vingt secondes limite l’attente du client, sans garantir l’arrêt d’un traitement au serveur.

Le résultat attendu est une ligne de mesures accompagnée des en-têtes. Répétez manuellement quelques fois, sans boucle rapide. Cette commande ne modifie aucun réglage local ou WordPress ; aucun retour arrière n’est nécessaire. Les en-têtes peuvent contenir des cookies ou des données d’infrastructure : gardez-les privés.

curl -q --silent --show-error --connect-timeout 5 --max-time 20 --dump-header - --output /dev/null --write-out '\ncode=%{http_code} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} premier_octet=%{time_starttransfer} total=%{time_total}\n' 'https://exemple.invalid/page/'

Interpréter les durées sans attribuer trop vite la cause

Si DNS ou connexion occupe l’essentiel de l’attente, commencez par comparer un autre réseau. Une lenteur limitée à votre poste, à un proxy professionnel ou à une région n’accuse pas automatiquement les extensions. Gardez le domaine et HTTPS actifs : remplacer le domaine par son adresse IP change le certificat, le routage et parfois le site servi.

Si la connexion est rapide puis l’attente domine, cherchez un délai après l’envoi de la demande. Il peut inclure le trajet réseau, le CDN, une file d’attente et le calcul de WordPress. Soustraire la fin de la connexion au premier octet donne un indice, pas une mesure pure de PHP. Les mesures du navigateur peuvent réutiliser une connexion ; une nouvelle commande curl peut en ouvrir une autre.

Des réponses anticipées 103 Early Hints peuvent également modifier le moment compté comme premier octet. Lorsque la valeur paraît très bonne mais que le HTML arrive tard, examinez aussi la réponse finale et le téléchargement. Comparez des relevés du même outil. Un code 000 avec une erreur curl indique une opération qui n’a pas obtenu de réponse HTTP exploitable ; ce n’est pas une preuve de réponse 500 ou 504.

Approche 2 : vérifier le cache du document HTML

Un cache de page conserve une réponse HTML réutilisable. Un cache objet conserve des résultats de calcul ou de base de données ; il ne remplace pas forcément la génération de la page entière. Enfin, un CDN qui accélère les images ne conserve pas nécessairement le HTML. Certains CDN conservent les fichiers statiques sans mettre les documents HTML en cache par défaut.

Avec un compte administrateur, ouvrez Outils, Santé du site, puis l’onglet État. Dépliez le résultat relatif au cache de page et au temps de réponse. WordPress utilise notamment des requêtes vers l’accueil et des indices de cache ; ce contrôle ne décrit pas toutes les pages ni le trajet de chaque visiteur. Une erreur de requête interne peut empêcher la détection : n’installez pas un second cache pour répondre mécaniquement à ce message.

Comparez ensuite deux visites publiques non connectées sur la même URL, sans paramètre ajouté. Relevez les indicateurs de cache documentés par votre prestataire dans les en-têtes, lorsqu’ils existent. Une visite plus rapide ne prouve pas, seule, un succès de cache. Un panier, un compte ou une page personnalisée peut légitimement rester exclu. Le résultat attendu est de savoir si le document mesuré peut être réutilisé, et à quelle couche.

Réactiver le cache global géré sur WordPress.com

Ce parcours concerne un site public WordPress.com Business ou Commerce dont le cache global a été désactivé sans raison encore valable. Il demande l’accès aux réglages d’hébergement. Sur Free, Personal et Premium, ce cache est toujours activé selon la documentation actuelle ; n’y cherchez pas le même interrupteur. Ne rendez pas public un site privé uniquement pour gagner du temps de réponse.

Le cache global rapproche les réponses des visiteurs. Avant son activation, vérifiez les exclusions prévues pour vos pages privées ou personnalisées. Le cache objet fourni par WordPress.com est distinct et automatiquement actif. Ajouter une extension de cache serveur concurrente n’est pas nécessaire pour ce parcours.

1. Ouvrez le tableau de bord d’hébergement WordPress.com et sélectionnez le titre du site concerné.
2. Dans la barre latérale, ouvrez Settings, puis la rubrique Caching de Server. Notez l’état actuel du réglage global.
3. Si le site est public et que les conditions précédentes sont remplies, activez Enable global edge caching for faster content delivery.
4. Ouvrez quelques pages publiques dans une session non connectée, avec des visites espacées. Vérifiez le contenu, les délais et les parcours personnalisés prévus. Si un problème apparaît, rétablissez le réglage initial et faites contrôler la politique de cache.
5. Ne cliquez pas systématiquement sur Clear all avant chaque mesure : la reconstruction peut ralentir les visites suivantes.

Approche 3 : alléger une boucle WordPress trop large

Ce parcours vise une page contenant un bloc natif Boucle de requête configuré pour afficher beaucoup de publications, avec une génération plus lente que les autres pages. Il demande le droit d’éditer cette page. Faites d’abord la comparaison sur la copie ; une baisse du nombre d’articles change aussi le contenu présenté.

L’exemple consiste à passer d’une liste de soixante éléments à douze. Ces nombres illustrent un essai, sans seuil universel ni gain promis. Ne changez pas une requête d’archive héritée en requête personnalisée pour faire apparaître un réglage : vous pourriez modifier les articles affichés. Le parcours ci-dessous concerne une boucle déjà personnalisée.

1. Dans Pages, choisissez Modifier sur la copie de la page concernée. Ouvrez la Vue en liste et sélectionnez Boucle de requête, plutôt que son Modèle de publication interne.
2. Dans les réglages du bloc, confirmez que le type de requête est Personnalisé, ou Custom. Notez le nombre initial d’éléments par page.
3. Dans les options d’affichage, rendez visible Items per Page si nécessaire via le menu à trois points, puis diminuez cette valeur et enregistrez.
4. Mesurez de nouveau dans les mêmes conditions de cache. Vérifiez les publications affichées et la pagination. Si le délai ne s’améliore pas ou si la présentation ne convient pas, remettez le nombre initial.

Comparer une extension sur une copie isolée

Si la lenteur commence après l’ajout ou la mise à jour d’une extension, vous pouvez comparer son effet sans nouvel outil. Il faut une copie fonctionnelle, un compte administrateur et un moyen de restaurer ses fichiers et sa base. Vérifiez que les actions sortantes de cette copie sont neutralisées avant de l’ouvrir.

Choisissez une extension suspecte à partir d’un changement daté ou d’un relevé. Ne désactivez pas le composant qui fournit la page étudiée : une page privée de son contenu est naturellement différente et ne valide pas une optimisation. Évitez aussi les composants indispensables à ses dépendances ou au cache que vous comparez.

1. Sur la copie, ouvrez Extensions, Extensions installées. Notez le nom, la version et l’état du composant retenu, puis les mesures de référence.
2. Cliquez sur Désactiver pour cette seule extension. Ne choisissez pas Supprimer. Si la désactivation est bloquée par des dépendances, arrêtez ce parcours ciblé.
3. Rechargez la même page et contrôlez que sa fonction utile existe toujours. Reprenez les mesures avec une situation de cache comparable.
4. Réactivez l’extension, puis refaites le contrôle. Si la lenteur revient et que le contenu est comparable, vous disposez d’un indice reproductible à transmettre à son éditeur, avant toute modification de production.

Query Monitor pour préciser le travail côté WordPress

Query Monitor est une extension gratuite de John Blackbourn, utile pour observer le chargement courant. La fiche consultée annonce la version 4.1.1, WordPress 6.3 minimum, PHP 7.4 minimum et des essais déclarés jusqu’à WordPress 7.1.4. Vérifiez de nouveau ces informations avant installation. L’extension observe ; elle ne corrige pas automatiquement les lenteurs.

Ce parcours facultatif demande un administrateur, ou un superadministrateur en multisite. Faites-le sur la copie, sans ajouter un diagnostic permanent à la production. Une page servie entièrement par un cache peut ne pas exécuter WordPress et ne pas fournir le relevé recherché. Une session administrateur peut elle-même contourner des caches : son résultat n’est pas celui de tous les visiteurs.

Le résultat attendu est une piste sur le temps de génération, les requêtes SQL ou les appels externes. Ce relevé concerne une ouverture, sans historique complet ni mesure du temps passé avant que PHP commence à travailler. Pour terminer, désactivez Query Monitor dans Extensions installées.

1. Dans Extensions, Ajouter, recherchez Query Monitor, vérifiez l’auteur, installez puis activez sur la copie.
2. En restant connecté, ouvrez la page lente. Dans la barre d’administration, ouvrez le menu Query Monitor puis Overview.
3. Examinez Timeline, puis Queries, Queries by Component, et HTTP API Calls selon les événements présents. Notez la durée et le composant associé, en gardant les données privées.

Lire les requêtes SQL et les appels externes

Une requête SQL est une demande adressée à la base de données. Dans le panneau des requêtes de Query Monitor, privilégiez les durées et les appels responsables plutôt que le seul nombre de requêtes. Une extension qui lance quelques demandes très lentes peut coûter davantage qu’une autre qui effectue de nombreuses lectures rapides. Les requêtes dupliquées orientent l’analyse, mais leur présence ne justifie pas une suppression de tables.

Dans HTTP API Calls, cherchez un service attendu longtemps, son statut et le composant qui l’appelle. Ces échanges partent du serveur WordPress ; ils peuvent être absents de la liste des requêtes réseau du navigateur. Une attente externe peut expliquer une page visuellement très simple.

Utilisez ensuite la comparaison ciblée sur copie ou un réglage documenté du composant concerné. Conservez les dépendances et la fonction rendue au visiteur. Ne bloquez pas arbitrairement un service de licence, de paiement ou de stock ; ne réduisez pas son délai au hasard. Envoyez à l’éditeur l’appel, sa durée et la version impliquée, sans jeton ni données personnelles. Si le temps SQL est faible mais la génération lente, poursuivez le profilage PHP avec une personne compétente plutôt que de modifier les index à l’aveugle.

Reconnaître une saturation de l’hébergement

Si toutes les pages non mises en cache ralentissent au même moment, confrontez vos relevés aux graphiques disponibles chez l’hébergeur. Cherchez la période exacte, les limites de ressources atteintes et les traitements planifiés. Les intitulés varient selon l’offre ; un graphique moyen sur une journée peut masquer une pointe courte.

Une file d’attente de travailleurs PHP peut retarder la réponse avant l’exécution que mesure votre extension de diagnostic. Une base distante ou saturée peut aussi allonger les requêtes. Un processeur momentanément peu occupé ne suffit donc pas à exclure une limite. Ne fixez pas au hasard un nombre supérieur de travailleurs : chaque processus consomme des ressources et peut aggraver la pression mémoire.

Transmettez l’URL de lecture, les heures et fuseaux, les durées, les statuts de cache, les versions et les comparaisons déjà réalisées. Demandez la corrélation avec les files PHP, la base et les journaux à ces instants. Ce dossier permet de décider entre une correction applicative et un changement de ressources, sans acheter une offre sur la seule base d’un score.

Contrôler la correction avec le même protocole

Après chaque changement, revenez aux deux pages retenues au départ. Gardez le même réseau et le même état de connexion, puis notez à nouveau plusieurs durées espacées. Séparez la première visite après invalidation du cache des suivantes. Une purge générale avant chaque essai fausse l’observation et peut ajouter du travail au serveur.

Comparez la réduction du délai avec le contenu réellement conservé. Vérifiez les liens, la pagination, la connexion et les pages personnalisées concernées. Sur une boutique, utilisez uniquement un environnement et des moyens de paiement de test prévus pour les contrôles transactionnels. N’effectuez pas un achat réel pour chronométrer le site.

Si une seule mesure devient meilleure, gardez la conclusion provisoire. Si le défaut revient après réactivation de l’extension ou restauration du réglage, la comparaison devient plus utile. Conservez le détail avant de déployer la correction ciblée avec sa sauvegarde et son retour arrière. Des données de visiteurs réels peuvent ensuite confirmer la tendance ; elles ne se mettent pas nécessairement à jour dès le premier rechargement.

Prévenir le retour d’une attente initiale excessive

Conservez une petite fiche de référence : deux URL représentatives, des mesures datées, les conditions de cache et le changement retenu. Reprenez ce protocole après une modification importante du thème, d’une extension, de la politique de cache ou de l’hébergement. Cela permet de rapprocher une régression d’un événement concret.

Sur WordPress.com, l’outil Performance du tableau de bord d’hébergement fournit aussi un relevé des pages publiques disponibles dans son sélecteur. Son score global ne remplace pas la lecture du document et de ses phases. Sur un autre hébergement, gardez la même discipline avec les outils effectivement fournis.

Évitez d’empiler les caches ou les optimisations sans relevé préalable. Une réponse rapide doit aussi rester correcte, actualisée et adaptée au visiteur. Gardez une place distincte pour le suivi du rendu de l’image principale et des interactions : améliorer le TTFB facilite leur démarrage, sans garantir à lui seul une page agréable.

Comparer le même document sans changer son poids

Sur la copie WordPress, la page d’essai renvoie le même HTML et le même repère visible pendant tous les essais. La génération comporte une attente programmée dans le thème de test. Un deuxième état sert la réponse HTML déjà produite. Un troisième état laisse WordPress générer la page avec une attente plus courte. Curl mesure le premier octet et l’empreinte du document confirme que le corps de 154 octets est identique. Le TTFB médian est de 650 ms en génération, de 1,3 ms avec le HTML déjà prêt et de 245 ms avec la génération allégée.

Cette comparaison distingue le coût de génération de la taille du document. Une page publique rapide servie depuis un cache peut coexister avec une génération lente. À l’inverse, si la génération allégée répond plus tôt avec le même HTML, ce gain existe aussi pour les requêtes que le cache ne sert pas. La recette utilise un fichier HTML servi par le routeur du banc pour représenter une réponse déjà prête. Elle mesure le scénario de copie.

Vérifier la génération et la réutilisation de la page séparément

Si vous avez uniquement accès au navigateur, utilisez une fenêtre déconnectée et relevez quelques ouvertures du même document dans Réseau. Gardez le statut, l’heure et les indices de cache indiqués par votre prestataire. Comparez le contenu affiché et la destination finale. Une différence de temps invite à chercher quelle réponse a été servie. Faites confirmer un succès ou une absence de cache dans les journaux si les en-têtes ne suffisent pas.

Si vous disposez d’une copie et des droits d’édition, retenez une page dont la génération est lente. Faites une mesure de référence puis réduisez le travail d’un seul composant, comme une boucle déjà personnalisée. Reprenez les mesures avec des états de cache comparables. Vérifiez la liste, la pagination et la fonction que la page doit rendre. Si le contenu ou la navigation ne convient plus, rétablissez la version précédente et relevez de nouveau le premier octet. Le changement du banc porte sur une attente volontaire dans le thème. Une lenteur réelle demande de retrouver le travail qui occupe cette attente.

Vérifier le retour à l’état de départ

La recette répète chaque état trois fois. Après l’essai avec le HTML déjà prêt et celui avec génération allégée, elle rétablit l’attente initiale. Le TTFB médian remonte à 618 ms et le corps de la réponse conserve son empreinte. Sur votre copie, reprenez la même méthode en rétablissant la seule modification testée. Si l’attente ne revient pas, vérifiez l’état de cache et les autres changements intervenus avant d’attribuer le résultat.

Les mesures du banc sont prises sur la boucle locale, avec la même adresse et sans redirection. Pour comprendre le symptôme des visiteurs, comparez aussi leur trajet et leurs conditions de consultation. Si le document répond vite mais que l’image principale tarde à apparaître, mesurez la demande et le rendu de cette image.