« Le site est lent » : ce diagnostic de départ, souvent formulé par un client sans plus de précision, pousse presque toujours vers le même réflexe, celui d’ouvrir immédiatement un profileur PHP à la recherche de la requête coupable. Une méthode plus rigoureuse consiste pourtant à commencer un cran plus bas, du côté du protocole réseau, avant même de songer au code applicatif.
La raison est simple : un problème de configuration réseau fausse toute mesure de temps de génération PHP effectuée en aval. Un temps de génération de 80 millisecondes ne veut rien dire si la connexion TLS met elle-même 300 millisecondes à s’établir, ou si la compression n’est pas activée sur une réponse de plusieurs centaines de kilo-octets. Voici les six points vérifiés systématiquement avant d’ouvrir Query Monitor.
1. La version du protocole HTTP réellement négociée
L’onglet réseau des outils de développement, ou la commande curl -I --http2 https://exemple.test/, permet de vérifier si le serveur répond bien en HTTP/2 ou HTTP/3. Un site encore servi en HTTP/1.1 subit une limitation du nombre de connexions parallèles par domaine, un problème structurel qu’aucune optimisation PHP ne peut compenser.
2. La qualité de la négociation TLS
La commande openssl s_client -connect exemple.test:443 -tls1_3 permet de confirmer que le serveur accepte bien TLS 1.3, plus rapide à négocier que les versions antérieures grâce à un aller-retour réseau en moins lors de l’établissement de la connexion. Un certificat expiré ou une chaîne de certification mal ordonnée peut également ajouter des vérifications supplémentaires côté navigateur, invisibles dans les journaux serveur mais mesurables dans le temps de connexion.
3. La compression de réponse
Une simple requête avec curl -H "Accept-Encoding: gzip, br" -I https://exemple.test/ révèle si l’en-tête Content-Encoding est présent dans la réponse. Son absence sur une page HTML de plusieurs centaines de kilo-octets constitue à elle seule un gain immédiat et gratuit, avant toute optimisation de code.
4. Les en-têtes de mise en cache des ressources statiques
Les fichiers CSS, JavaScript et images doivent porter un en-tête Cache-Control avec une durée longue, accompagné d’un identifiant de version dans le nom de fichier pour permettre l’invalidation lors des mises à jour. Un fichier statique sans en-tête de cache oblige chaque visiteur à le retélécharger intégralement, y compris lors d’une simple navigation entre deux pages du même site.
5. Le nombre et l’ordre des redirections
La commande curl -IL https://exemple.test/ affiche la chaîne complète des redirections traversées avant d’atteindre la page finale. Une redirection de http:// vers https://, suivie d’une redirection de sans-www vers www, ajoute deux allers-retours réseau complets avant même que la première requête utile ne soit émise.
6. Le point de terminaison réellement interrogé par le CDN
Lorsqu’un CDN est en place, une requête avec l’en-tête cache-status ou l’équivalent propre au prestataire permet de vérifier si la réponse provient effectivement du cache en périphérie ou si elle a dû remonter jusqu’au serveur d’origine. Un taux de succès de cache anormalement bas explique souvent une lenteur perçue que l’on chercherait, à tort, du côté du code WordPress.
Ce que cette séquence a permis d’éviter
- Sur un audit récent, la compression de réponse était simplement absente : gain immédiat de 65 % sur le poids transféré, sans toucher une ligne de PHP.
- Une chaîne de trois redirections successives ajoutait 240 millisecondes avant même le premier octet utile.
- Le certificat TLS, valide mais mal ordonné dans sa chaîne de confiance, imposait une vérification supplémentaire côté navigateur sur les connexions mobiles.
Un audit qui commence par le code cherche des solutions à des problèmes qui, souvent, ne relèvent pas du code : vérifier le protocole d’abord évite bien des recherches inutiles.
En résumé
Ces six vérifications, réalisables en quelques minutes avec curl et les outils de développement du navigateur, permettent d’éliminer les causes structurelles avant de se plonger dans le code applicatif. Un profileur PHP reste indispensable, mais il ne prend tout son sens qu’une fois la couche réseau confirmée saine.
