Parfois votre site répond en deux secondes. Parfois — même URL, même heure « normale » — la roue tourne pendant une, deux, trois minutes avant qu'une page s'affiche ou time-out. Ce n'est pas de la malchance : c'est un symptôme de saturation, de requête bloquée ou de ressource externe qui ne répond plus. Et tant que le problème est intermittent, il est facile de le minimiser… jusqu'au jour où Googlebot abandonne le crawl ou qu'un client part chez le concurrent.
Chez Apresta, nous diagnostiquons ce type de lenteur extrême chez des e-commerçants et des sites vitrine B2B en Hauts-de-France — souvent après des mois de « ça va, c'est juste un peu lent par moments ». Voici la méthode complète : reconnaître les signaux, identifier les causes, mesurer intelligemment, corriger par priorité et mettre en place une surveillance qui alerte avant la prochaine panne de performance.
Symptômes : reconnaître une lenteur intermittente
Contrairement à un site toujours lent, le pattern intermittent obéit à une logique qu'on peut retrouver. Le chargement est normal le matin et devient une attente de plusieurs minutes en fin de journée — ou l'inverse. La lenteur survient après une campagne email ou pub, signe qu'un pic trafic n'a pas été absorbé. Parfois une seule page est concernée — checkout, recherche — alors que l'accueil reste rapide.
Les timeouts navigateur, les erreurs 504 Gateway Timeout ou 503 Service Unavailable, et la corrélation avec une action admin — import produits, génération PDF, cron — orientent vers le serveur ou la base, pas vers une image mal compressée. Quand tout redevient normal sans intervention puis rechute quelques heures plus tard, vous tenez presque certainly un problème de saturation ou de tâche planifiée mal calée.
Des minutes de chargement, ce n'est pas un problème d'image non compressée. C'est presque toujours serveur, base de données, cron ou dépendance externe.
Causes principales derrière des minutes d'attente
Saturation CPU ou RAM de l'hébergement
Sur un mutualisé bon marché, un voisin consomme les ressources et votre PHP attend. Symptôme classique : lenteur aléatoire, TTFB supérieur à 5 s dans les logs. Le site ne « casse » pas — il suffoque par moments.
Requêtes SQL lentes ou bloquées
WooCommerce sans index, recherche full-text sur 50 000 SKU, plugin de stats qui scanne toute la table wp_postmeta : une seule requête peut verrouiller la base plusieurs minutes. Tant qu'elle tourne, les autres pages attendent leur tour.
Crons et tâches planifiées mal configurées
WordPress wp-cron déclenché à chaque visite, import CSV à 14 h pile, synchronisation ERP toutes les heures sur le même serveur que le site public : collision garantie aux heures de pointe. Un pattern « lent à 12 h et 18 h » oriente souvent vers cron ou pic déjeuner/dîner e-commerce.
APIs tierces, cache absent et disque plein
Paiement, livraison, CRM, Google Fonts, widget avis : si l'API met 60 s à répondre et que votre page attend la réponse en synchrone, l'utilisateur attend aussi. Sans cache page, chaque hit recalcule PHP + SQL ; lors d'un pic, la file d'attente explose. Enfin, un disque plein ou des logs non rotés empêchent MySQL d'écrire — comportements erratiques garantis.
Les attaques ou bots agressifs — scraping catalogue, brute-force wp-login, crawl mal identifié — saturent aussi le serveur avec du trafic junk. Un WAF et du rate limiting limitent ce vecteur.
Diagnostic : mesurer au bon moment
L'intermittent exige traçabilité, pas un seul test PageSpeed un mardi calme. PageSpeed teste une capture ponctuelle, souvent sans votre trafic réel ni vos crons — il ne remplace pas logs serveur et monitoring continu sur 7 jours.
Confirmer que ce n'est pas local
Testez depuis la 4G, pas le Wi-Fi bureau. Croisez avec WebPageTest, UptimeRobot ou Pingdom depuis plusieurs régions. Demandez à un client affecté de tester la même URL : même lenteur des deux côtés confirme un problème serveur.
Corréler heure, trafic et requête lente
Croisez Google Analytics (sessions par heure vs plaintes), les logs serveur (accès, erreurs 5xx, temps de réponse) et les graphiques CPU/RAM de l'hébergeur au moment des incidents. Sur WordPress, Query Monitor ou le profiler PrestaShop en mode dev identifient la page et la requête coupable. Activez temporairement le slow_query_log MySQL avec un seuil de 2 s.
Dans Chrome DevTools → Network, repérez quelle requête bloque : document, XHR ou third-party ?
Mesurer le TTFB isolément
curl -o /dev/null -s -w '%{time_starttransfer}\n' https://votresite.fr/page-lente/Répétez 20 fois sur une heure. Un TTFB supérieur à 3 s de façon répétée signale un problème serveur/back-end, pas front. Vérifiez ensuite les crons : WP Crontrol pour WordPress, tâches modules shipping/ERP pour PrestaShop, crontab -l côté serveur. Déplacez les imports lourds hors heures de pointe (2 h–5 h du matin).
Corrections par priorité
Urgent — site inaccessible ou checkout bloqué
Contactez l'hébergeur pour CPU/RAM, processus bloqués ou disque plein. Activez ou renforcez le cache page immédiatement — LiteSpeed, Varnish, Redis object cache. Désactivez temporairement le plugin suspect (recherche, stats, related products). Augmentez le timeout PHP uniquement le temps du diagnostic — pas comme solution permanente.
Délai de stabilisation avec bon accès : 2 h à 1 jour.
Important — traiter la cause racine
Migrez vers VPS ou hébergement managé si trafic e-commerce supérieur à 500 visites/jour. Indexez les colonnes SQL identifiées en slow log. Externalisez crons WordPress (DISABLE_WP_CRON + cron système réel). Mettez APIs tierces en asynchrone ou cache. Ajoutez un CDN pour les assets statiques — voir CDN, cache et hébergement.
Budget infra + optim SQL PME : 500 à 3 000 € one-shot + possible hausse hébergement 30 à 120 €/mois.
Plus tard — surveillance et prévention
Installez monitoring uptime + alerte SMS (UptimeRobot, Better Stack), un APM léger ou des logs agrégés, et une revue trimestrielle des plugins actifs. Planifiez la montée en charge avant soldes / Black Friday. Voir surveillance et monitoring site web.
Ordres de grandeur : quand une page « minutes » devient critique
Une PME bien hébergée affiche un TTFB normal entre 200 et 600 ms. Le LCP acceptable mobile reste inférieur à 2,5 s — idéal sous 2 s (vitesse sous 2 secondes). Au-delà de 10 s, environ 50 % des visiteurs partent ; au-delà de 60 s, abandon quasi total plus risque de déindexation partielle si Googlebot subit la même chose.
Une page produit qui met 90 s à charger de temps en temps peut coûter plus qu'un mois de SEO perdu sur cette URL.
Prévention pour les PME des Hauts-de-France
Dimensionnez l'hébergement au pic, pas à la moyenne. Activez un cache objet Redis dès WooCommerce ou PrestaShop en production. Sauvegardez avant tout import massif et testez imports et mises à jour en staging — pas en production un lundi matin.
Le scénario classique : boutique lilloise lance les soldes sans cache ni montée de plan hébergeur — le site tient… jusqu'à la première vague d'emails.
Avant chaque période commerciale forte — soldes, fêtes, salon professionnel — refaites un test de charge léger sur la page la plus sollicitée. Un contrat maintenance avec revue perf semestrielle évite les surprises — voir maintenance site web.
FAQ
Pourquoi PageSpeed affiche un bon score alors que le site freeze par moments ?
PageSpeed teste une capture ponctuelle, souvent sans votre trafic réel ni vos crons. Il ne remplace pas logs serveur et monitoring continu sur 7 jours.
Un hébergement mutualisé peut-il suffire pour un e-commerce ?
Oui pour faible trafic (moins de 100 visites/jour) avec cache agressif. Au-delà, les lenteurs intermittentes deviennent fréquentes — VPS ou cloud managé recommandé.
Faut-il changer de CMS si les pages mettent des minutes à charger ?
Rarement. Dans 80 % des dossiers Apresta, l'infrastructure et la config (cache, SQL, crons) sont en cause — pas WordPress ou PrestaShop en eux-mêmes.
Comment savoir si c'est une attaque et non un bug ?
Pic soudain de requêtes sur /wp-login.php, /xmlrpc.php ou filtres répétitifs ; logs avec milliers d'IP distinctes. Solution : WAF, rate limiting, blocage géo si trafic 100 % hors cible.
Combien coûte un audit performance approfondi ?
Audit + plan d'action pour site e-commerce PME : 600 à 1 800 € selon stack et accès. Corrections SQL + cache + hébergement en sus, chiffrées après diagnostic.
Et maintenant ?
Des pages qui mettent des minutes à charger « par moments », ce n'est pas un détail UX — c'est un risque commercial et SEO qui attend le mauvais jour pour se manifester en pleine campagne. Corrélez logs et trafic, mesurez le TTFB sous charge, traitez serveur et SQL avant de toucher aux images, puis installez une surveillance qui vous alerte quand la normale dérape.