« Mon site rame. » C'est la plainte la plus fréquente en support, et aussi la plus vague. Avant de toucher à quoi que ce soit, il faut localiser la lenteur. Un site lent, c'est un problème à trois couches possibles : le navigateur qui peine à rendre la page, le réseau qui traîne entre le visiteur et le serveur, ou le serveur lui-même qui met du temps à générer la réponse. Ce guide sert de point de départ. À chaque symptôme, on renvoie vers la doc qui approfondit.
Les trois couches de lenteur
Avant tout diagnostic, gardez en tête cette décomposition. Une même page mal perçue peut venir de n'importe laquelle, souvent d'un cumul :
- Frontend (navigateur) — le HTML arrive vite mais le rendu est long : images lourdes, JS bloquant, CSS non découpé, fonts qui bloquent le texte. Symptôme typique : LCP élevé alors que le TTFB est bon.
- Réseau (DNS, TLS, CDN, géographie) — le premier octet met des lustres à arriver alors que le serveur n'est pas chargé. Symptôme : TTFB > 600 ms depuis l'étranger, bon TTFB depuis la France.
- Backend (serveur, PHP, MySQL) — le serveur lui-même met du temps à construire la réponse. Symptôme : TTFB > 1 s en origine (mesuré avec le CDN désactivé ou en bypass), CPU ou I/O qui grimpent.
Les outils de mesure
PageSpeed Insights
pagespeed.web.dev — gratuit, donne le verdict Core Web Vitals (LCP, INP, CLS) en mobile et desktop. Idéal pour un premier coup d'œil. Attention : les scores sont synthétiques (Lighthouse) et peuvent différer du « terrain » (données CrUX). Regardez les deux onglets.
WebPageTest
webpagetest.org — le couteau suisse. Waterfall détaillé, test depuis plusieurs points du globe, comparaison avant/après, filmstrip visuel du chargement. Pour creuser un problème réseau ou un blocage JS, rien de mieux.
Lighthouse (Chrome DevTools)
F12 > onglet Lighthouse > Analyze page load. Même moteur que PageSpeed mais en local, avec vos extensions désactivées. Utile quand vous voulez tester une page pre-prod non accessible publiquement.
GTmetrix, Pingdom
Alternatives à WebPageTest, avec des interfaces plus lisibles. GTmetrix fait un bon combo Lighthouse + waterfall. Pingdom Tools reste pratique pour une mesure rapide depuis un POP précis.
Frontend lent : LCP au-dessus de 2,5 s
Le HTML arrive vite mais la page met du temps à s'afficher. Pistes, par ordre d'impact :
Images non optimisées
- Format moderne : WebP partout, AVIF quand c'est possible. Gain typique de 25 à 50 % vs JPEG.
srcset+sizesresponsive pour ne pas servir du 2400px à un téléphone.loading="lazy"sur tout ce qui est sous la ligne de flottaison,fetchpriority="high"sur l'image LCP.- Largeurs et hauteurs explicites (
width,height) pour éviter le CLS.
JavaScript bloquant
asyncoudefersur tous les<script>non critiques.- Code splitting : charger les modules au besoin, pas tout sur la home.
- Auditer les third parties (pixels, widgets chat, tag managers). Un seul tracker mal fichu peut ruiner l'INP.
- Sur WordPress, désinstaller les plugins inutiles. Query Monitor permet de voir qui charge quoi.
CSS non découpé
Inliner le CSS critique (above-the-fold) dans le <head>, charger le reste en lazy. Les outils comme critical (npm) automatisent ça. Objectif : que la page commence à s'afficher avant que le CSS principal ne soit téléchargé.
Fonts bloquantes
font-display: swapdans le@font-face— le texte s'affiche dans une police système en attendant, puis bascule.- Subset : ne garder que les glyphes latin-ext si vous ne faites pas de chinois. Gain de 60 à 80 % sur le poids.
- Préférer le format woff2 et auto-hébergé plutôt que Google Fonts (un aller-retour DNS en moins, et conforme RGPD).
Réseau lent : TTFB > 600 ms
Le serveur répond vite en local mais le premier octet met du temps à atteindre le visiteur. Causes fréquentes :
DNS lent
Un DNS à la traîne ajoute 50 à 300 ms à chaque nouvelle connexion. Bascule chez un résolveur sérieux (Cloudflare, NS1, Gandi LiveDNS) et activez le DNS prefetch pour les domaines tiers : <link rel="dns-prefetch" href="//cdn.exemple.com">.
TLS handshake lent
Activer HTTP/2 minimum, HTTP/3 (QUIC) si possible. Sur une connexion mobile médiocre, HTTP/3 fait une vraie différence (pas de head-of-line blocking, reprise de connexion plus rapide). Voir Activer HTTP/2 et HTTP/3.
Pas de CDN
Un visiteur à Marseille qui tape sur un serveur à Paris, ça va. Un visiteur à Montréal, ça ne va plus. Cloudflare (gratuit) met vos assets statiques dans 300+ POP à travers le monde. Voir Cloudflare devant Plesk.
Géographie
Si votre audience est internationale, le CDN n'est pas optionnel. Même avec un backend parfait, la latence physique impose ses limites.
Backend lent : TTFB > 1 s en origine
On parle du TTFB mesuré sans CDN (development mode Cloudflare, ou depuis un monitor interne). Si la lenteur est là, c'est le serveur qui travaille trop ou mal.
PHP
- OPcache activé ? Sans lui, PHP recompile les scripts à chaque requête. Pénalité x2 à x3 sur WordPress. Vérification :
phpinfo()ouphp -i | grep opcache. - Version PHP récente ? PHP 8.3 est environ 25 % plus rapide que 7.4 sur WordPress. Voir Changer la version PHP dans Plesk.
memory_limitsuffisant (256 Mo minimum pour WP avec WooCommerce, 512 Mo recommandé).- PHP-FPM bien dimensionné :
pm.max_childrencohérent avec la RAM dispo, sinon file d'attente et timeouts.
MySQL / MariaDB
- Activer le slow query log (seuil 1 s) pour identifier les requêtes qui tuent le serveur. Voir Optimiser MySQL.
- Ajouter les index manquants — un
EXPLAINsur la requête lente vous dit lesquels. - Table
wp_optionsobèse avec des transients expirés : faire le ménage régulièrement.
Cache applicatif
- Page cache manquant ? Pour un WordPress, c'est non négociable. Voir Quel cache choisir pour WordPress.
- Redis object cache pour les pages dynamiques (dashboard, panier). Voir Redis : cache objet pour CMS.
- Sur PrestaShop, voir LiteSpeed pour PrestaShop.
Plugins WordPress lourds
La méthode brutale mais efficace : désactiver tous les plugins, remesurer, réactiver un par un en mesurant à chaque étape. Query Monitor (plugin) profile les requêtes SQL et le temps passé dans chaque hook, ce qui accélère énormément le diagnostic.
Checklist diagnostic en 5 minutes
À dérouler dans l'ordre, sans rien installer :
- ☐ PageSpeed Insights mobile sur l'URL. Noter LCP, INP, CLS.
- ☐ TTFB dans Chrome DevTools > Network > premier document > onglet Timing. Au-dessus de 1 s, le backend est suspect.
- ☐ Page cache actif ? Inspecter les réponses pour un header
X-Cache: HIT,cf-cache-status,x-litespeed-cache, etc. - ☐ OPcache activé ? Créer temporairement un
phpinfo.php, chercher la section OPcache (puis le supprimer). - ☐ Version PHP ≥ 8.2 ? Visible aussi dans
phpinfo(), ou dans Plesk > Hébergement > Paramètres PHP. - ☐ CDN en front ? Un
digounslookupsur le domaine : si l'IP est dans les plages Cloudflare ou Fastly, oui.
Cinq minutes, six cases. À la fin, vous savez déjà sur quelle couche concentrer l'effort.
Pro move : tester dans de bonnes conditions
Les mesures biaisées, c'est le piège classique.
- Ouvrir une fenêtre privée : pas de cache navigateur, pas d'extensions, pas de session connectée (donc page cache HIT sur WP).
- Désactiver toutes les extensions Chrome. Un bloqueur mal réglé, un traducteur automatique, et vos chiffres sont faussés.
- Throttling 3G Fast dans DevTools > Network. Ça reproduit l'expérience d'un visiteur mobile en zone moyenne. C'est là qu'on voit vraiment les fonts qui bloquent et le JS en trop.
- Mesurer plusieurs fois : la première visite (cache froid) et la deuxième (cache chaud) racontent deux histoires différentes, les deux comptent.
Quand ouvrir un ticket Datacampus
Si vous avez déroulé la checklist, que le front est propre, que le cache tourne, que PHP est à jour, et que le TTFB origine reste élevé — c'est l'heure du ticket. On regarde côté infra :
- Charge CPU de la VM sur la journée (graphes dans votre espace client).
- I/O wait et latence Ceph.
- Voisins bruyants sur un mutualisé, le cas échéant.
- Apache event ou PHP-FPM saturés (queue en attente).
Ouvrir un ticket sur le ServiceDesk avec : l'URL concernée, un horodatage de lenteur observé, un screenshot du waterfall WebPageTest si vous en avez un. Ça nous fait gagner 20 minutes.