On a récupéré un WooCommerce de 4 000 produits qui perdait 40 points de LCP chaque nuit entre 2h52 et 3h04. Le monitoring serveur montrait une consommation CPU à 98%, des IO wait à 70%, et un TTFB qui bondissait de 180ms à 3,2 secondes pile à ce moment-là. Le coupable n’était pas une attaque, ni un script malveillant, ni un pic de trafic. C’était une sauvegarde BackWPup configurée avec les réglages par défaut, déclenchée par le pseudo-cron WordPress.
Je te montre pourquoi le problème est structurel, ce que j’ai changé dans la config, et comment tu peux vérifier en deux minutes si ton propre site subit la même punition silencieuse.
La sauvegarde n’est pas un processus de fond magique
Beaucoup de devs et d’administrateurs WordPress pensent qu’un plugin de backup comme BackWPup tourne « en arrière-plan ». Sauf que sur un hébergement mutualisé ou un VPS sans process manager dédié, chaque cycle de sauvegarde consomme de la RAM, du CPU, des entrées/sorties disque et verrouille des tables MySQL, le tout dans le même espace que les requêtes PHP qui servent tes visiteurs.
Quand BackWPup compresse un dump de base de 800 Mo à la volée, le serveur ne fait pas la différence entre cette tâche et une requête légitime. Résultat : la file d’attente PHP s’allonge, le TTFB grimpe, et l’utilisateur qui arrive à ce moment-là attend. Le pire, c’est que ce visiteur peut être Googlebot. Et un Googlebot qui subit un TTFB de 4 secondes, c’est une crawlabilité dégradée, parfois un abandon de la requête, et à terme un signal de lenteur qui pèse sur l’exploration.
J’insiste sur un point : dans l’onglet Réseau des DevTools, tu vois le TTFB comme un indicateur serveur. Un TTFB élevé ne touche pas que le LCP. Il retarde le parsing HTML, donc le chargement des ressources critiques, donc potentiellement tous les jalons de Core Web Vitals. Si tu veux creuser la mécanique complète, j’ai détaillé chaque métrique dans mon article sur l’optimisation des Core Web Vitals.
Le piège du pseudo-cron WordPress
WordPress n’a pas de vrai cron système. Il simule un planificateur en déclenchant les tâches planifiées sur la première visite qui suit l’échéance. Si ta sauvegarde est programmée toutes les 6 heures via wp_schedule_event, c’est un visiteur aléatoire, ou toi-même en ouvrant l’admin, qui écope de la charge de lancer BackWPup.
Le code est sans appel : dans wp-cron.php, le déclenchement est synchrone. Si le job de backup met 90 secondes à s’exécuter, le processus PHP qui sert la page reste bloqué jusqu’à la fin du job, à moins d’avoir un timeout agressif. Tu obtiens alors une erreur 504 ou une page blanche. J’ai vu un site perdre 12 000 URLs dans l’index en une semaine parce que le Googlebot tombait régulièrement sur ces timeouts lors du crawl nocturne. La Search Console remontait des pics d’erreurs « indisponible » calqués sur l’heure du cron.
⚠️ Attention : sur un hébergement mutualisé, désactiver le pseudo-cron en définissant
DISABLE_WP_CRONàtruedans wp-config.php puis appelerwp-cron.phpvia une vraie tâche CRON serveur toutes les minutes est la première chose à faire. Mais ça ne règle pas le problème si BackWPup reste déclenché pendant une visite. Il faut en plus déplacer le déclenchement.
Les trois paramètres BackWPup qui transforment une sauvegarde en test de charge
Je ne te fais pas un tutoriel sur l’installation. Tu sais cliquer sur « Ajouter un nouveau ». En revanche, les onglets avancés contiennent trois leviers que presque personne ne touche et qui changent tout.
Compression et segmentation
Par défaut, BackWPup crée une archive unique, souvent en Tar GZip. L’opération de compression est CPU-intensive. Si ta base fait 500 Mo, la compression peut prendre 30 à 60 secondes à 100% d’un cœur. Le réglage « Nombre de fichiers par archive » permet de segmenter en volumes de 50 ou 100 Mo. Le process libère le CPU par intermittence, ce qui laisse respirer les autres processus. Sur un VPS 2 cœurs, c’est la différence entre un site qui rame et un site qui reste fluide.
Throttling des requêtes base de données
L’option « Pause entre les tables » dans l’onglet « Base de données » accepte une valeur en millisecondes. Même 200ms entre chaque table dumpée suffisent à réduire la pression sur le SGBD. Le temps total de sauvegarde augmente, mais l’impact sur les requêtes concurrentes s’effondre. C’est exactement le même principe que le throttling des re-rendus en front : mieux vaut étaler la charge que bloquer le thread principal. Une logique qu’on retrouve quand on compare Claude Code et Cursor IDE sur des projets lourds : c’est rarement l’outil le plus rapide en pic qui donne le meilleur confort, c’est celui qui ne gèle pas l’interface.
Exclusion des tables inutiles
BackWPup sauvegarde par défaut toutes les tables. Y compris les tables de logs, de sessions, de stats temporaires qui peuvent représenter 30 à 40% du volume total. Sauvegarder ces tables n’a aucun intérêt et alourdit le dump. Dans l’onglet « Base de données », exclure les préfixes de type wp_actionscheduler, wp_woocommerce_sessions, wp_wf_logs divise souvent par deux le temps de backup.
Mesure réelle : ce que les logs PHP et MySQL révèlent
On arrête de spéculer. Connecte-toi en SSH et lance cette commande pendant une sauvegarde manuelle :
watch -n 1 "mysqladmin proc stat | grep -E 'Sleep|Query|Locked' ; uptime"Si tu vois des locks qui durent plus d’une seconde ou une charge système (load average) qui dépasse 2 fois ton nombre de cœurs, ta config actuelle étrangle le serveur.
Côté PHP, active les slow logs avec un seuil à 5 secondes :
slowlog = /var/log/php-slow.log
request_slowlog_timeout = 5sAprès une sauvegarde nocturne, regarde les entrées. Tu trouveras probablement des scripts backwpup ou wp-cron.php avec des temps d’exécution de 30 à 90 secondes. C’est la preuve que des visiteurs ont été impactés. Sur un site avec un fort trafic administratif en journée, j’ai déjà relevé 80 slow logs en une seule backup.
La solution immédiate : forcer BackWPup à ne se lancer que via une vraie tâche CRON, pas via le pseudo-cron web.
Le vrai cron serveur : la seule architecture qui protège le TTFB
D’abord, désactive le déclenchement par visite :
define('DISABLE_WP_CRON', true);Ensuite, programme une tâche système qui appelle le cron WordPress et déclenche BackWPup dans la foulée, à une heure de faible trafic vérifiée dans Analytics :
# /etc/cron.d/wp-backup
30 3 * * * www-data /usr/bin/php /var/www/html/wp-cron.php > /dev/null 2>&1
0 4 * * * www-data /usr/bin/php /var/www/html/wp-content/plugins/backwpup/inc/cron.php > /dev/null 2>&1Le job de backup n’est plus jamais exécuté par un visiteur. Même si la sauvegarde sature le serveur, personne ne le subit, sauf un éventuel Googlebot nocturne. Dans ce cas, un ajustement du throttle règle le problème.
Enfin, déplace les archives hors du serveur web. BackWPup propose l’envoi vers S3, Google Drive, ou un stockage externe. Garder des zip de 2 Go dans wp-content/uploads/backwpup-* offre une surface inutile aux scanners de vulnérabilités et peut déclencher des alertes dans Search Console si les fichiers sont crawlés. Googlebot n’a pas à perdre du temps sur un blob de 2 Go.
Sauvegarde et crawl budget : l’angle mort
Une erreur 500 ou 503 intermittente ne fait pas que dégrader le LCP. Si Googlebot tombe sur une indisponibilité pendant sa fenêtre de crawl, il réduit sa fréquence de visite. Sur un site e-commerce où 30% des fiches produits sont mises à jour chaque semaine, ce délai de recrawl coûte des positions. La Search Console ne te dit pas « ton serveur était saturé par la backup », elle te montre juste une courbe de pages explorées qui s’effondre.
J’ai vérifié ça sur un client dont les pages produits utilisent une gestion d’état complexe côté front et dépendent d’endpoints API REST. Quand le serveur était en backup, l’API répondait en 8 secondes, le rendu serveur expirait, Googlebot repartait avec une coquille vide, et l’indexation conditionnelle ne s’activait pas. Le diagnostic a pris trois jours.
Surveiller les logs serveur pour corréler les erreurs 5xx avec les plages horaires de backup, c’est la première chose à faire si tu observes une baisse inexpliquée de l’exploration.
Questions fréquentes
BackWPup est-il moins performant qu’UpdraftPlus ou Duplicator ?
La question n’est pas le plugin, elle est le profil de charge. BackWPup, comme les autres, compresse et dump. La différence principale tient aux options de throttling et à la capacité à exclure finement les tables. Ce qui compte, c’est la config, pas le logo du plugin.
Est-ce que la désactivation du cron WordPress casse les autres tâches planifiées ?
Non, si tu appelles wp-cron.php via un cron système toutes les minutes. Toutes les tâches planifiées continuent de s’exécuter, mais plus jamais sur le dos d’une visite. Si l’appel système est oublié, en revanche, tu perds les mises à jour programmées, les publications futures et le nettoyage des sessions : c’est une panne silencieuse qui peut coûter cher.
