Le problème à résoudre
La lenteur perçue peut naître avant PHP, pendant une requête SQL, dans le navigateur ou chez un service externe. Changer de serveur sans localisation précise risque seulement de déplacer le problème.
Définissez le symptôme : quelle URL, pour quel utilisateur, depuis quand et à quelle fréquence ? Une page lente pour un administrateur n’a pas les mêmes causes qu’un LCP élevé sur mobile.
Reconnaître les bons signaux
| Signal observé | Interprétation probable | Premier contrôle |
|---|---|---|
| TTFB lent, serveur calme | PHP, SQL ou attente externe | Tracer la requête |
| CPU haut pendant un pic | Concurrence ou tâche lourde | Identifier processus et URL |
| Front lent, HTML rapide | Images, scripts ou polices | Analyser le navigateur |
Les notions à maîtriser
- Le cache peut rendre les visiteurs anonymes rapides tout en laissant le back-office lent.
- Une requête SQL sans index devient visible lorsque la base grandit.
- Les services de police, consentement, publicité ou paiement ajoutent des dépendances réseau.
- Le cron WordPress déclenché par les visites peut créer des pointes irrégulières.
Méthode de diagnostic
Plan d’action recommandé
- Corriger d’abord les erreurs et timeouts visibles dans les journaux.
- Supprimer ou remplacer les extensions responsables de délais récurrents.
- Dimensionner PHP-FPM, OPcache et base selon les mesures.
- Alléger médias et scripts du chemin critique.
- Ajouter une surveillance pour vérifier le gain dans la durée.
Premier relevé reproductible
Depuis un poste extérieur, cette commande sépare résolution DNS, connexion, premier octet et durée totale. Remplacez l’URL et répétez le test plusieurs fois, avec et sans cache.
curl -L -o /dev/null -s \
-w 'DNS:%{time_namelookup} Connexion:%{time_connect} TTFB:%{time_starttransfer} Total:%{time_total}\n' \
https://example.fr/Sur le serveur, complétez avec les journaux PHP-FPM et SQL au même horodatage. Une commande isolée ne suffit pas à désigner la cause.
Erreurs fréquentes à éviter
- Se fier uniquement à une note de laboratoire.
- Augmenter RAM et CPU sans savoir quelle ressource sature.
- Faire plusieurs optimisations simultanées et perdre la causalité.
Indicateurs à suivre
| Indicateur | Repère | Pourquoi le suivre |
|---|---|---|
| TTFB | Ventilé cache froid/chaud | Localise le backend |
| CPU/I/O | Corrélés à l’URL lente | Valide la saturation |
| LCP/INP | Mesurés sur utilisateurs réels | Reflètent le navigateur |
Checklist avant validation
- Une mesure de référence est conservée.
- Le changement est testé hors production lorsque c’est possible.
- Une sauvegarde ou un retour arrière est disponible.
- Les dépendances web, e-mail et DNS ont été contrôlées.
- Les journaux et alertes sont surveillés après intervention.
- Le résultat est documenté avec date et responsable.
Questions fréquentes
Le serveur est-il souvent coupable ?
Il peut l’être, mais plugins, base, médias et tiers sont tout aussi fréquents.
Quelle page tester ?
Accueil, page de contenu, recherche, connexion et parcours métier selon le site.
Quand migrer ?
Quand les mesures montrent une limite d’infrastructure ou que l’exploitation ne répond plus au niveau requis.
Sources techniques
Pour vérifier les règles et approfondir le sujet :
Besoin d’un diagnostic WordPress ?
Décrivez les pages lentes, le contexte et l’impact : le diagnostic séparera application, serveur et ressources front-end.
Voir l’accompagnement WordPress