Fonctionnalités Tarifs Régions Support Blog ⚡ Audit gratuit Essai gratuit Connexion EN
← Retour au blog

Black Friday et ventes flash WooCommerce : le piège du cache froid

Le Black Friday amène votre pic de trafic juste après que vos changements de prix ont purgé le cache. Voici comment préparer WooCommerce : quoi préchauffer, à quel moment, et comment le vérifier avant le lancement.

Black Friday et ventes flash WooCommerce : le piège du cache froid

Le Black Friday (le 27 novembre en 2026) envoie un pic de visiteurs vers votre boutique au moment précis où votre cache est le plus froid : vous venez de modifier prix et stocks, ce qui a purgé exactement les pages que les gens s'apprêtent à visiter. Préchauffer ces pages automatiquement avant le lancement fait la différence entre un lancement rapide et un serveur qui plie. Voici comment le mettre en place sur WooCommerce, pour le Black Friday comme pour n'importe quelle vente flash.

Le pire moment pour avoir un cache froid

Black Friday, ventes flash, un produit mis en avant dans une newsletter : ces événements ont un point commun : un pic soudain de trafic. Et un autre : votre cache est presque certainement froid.

Pourquoi ? Parce que vous venez de mettre à jour les prix, les niveaux de stock ou les bannières promotionnelles, et que les plugins de cache branchés sur WooCommerce purgent les pages concernées à l'enregistrement. Vos pages produits, vos pages catégories et parfois votre page d'accueil sont froides au moment exact où les visiteurs arrivent.

Le résultat est bien connu : chargements lents, taux de conversion en berne, et parfois un serveur qui plie sous une charge qu'il aurait absorbée sans problème si le cache avait été chaud.

Ce qui est purgé, et quand

WooCommerce ne gère pas lui-même de cache de pages : c'est votre plugin de cache, votre hébergeur ou votre CDN qui réagit à ses événements. Le périmètre exact dépend donc de votre configuration, mais les déclencheurs habituels sont les suivants :

  • Enregistrement d'un produit : la fiche produit, souvent ses catégories, parfois la page boutique et la page d'accueil
  • Changements de prix en masse : la même chose, multipliée par le nombre de produits modifiés
  • Changements de stock : selon le réglage, chaque commande peut purger la fiche du produit vendu
  • Purges globales : un changement de thème ou de menu, une mise à jour d'extension ou le bouton « vider le cache » peuvent tout effacer d'un coup

Ne le supposez pas, mesurez-le : modifiez un produit de test, puis regardez quelles pages repassent en MISS dans leurs en-têtes de cache. Pour une vente, vous changez généralement les prix juste avant le lancement : une bonne partie de votre catalogue est donc froide au moment où la vente démarre.

La solution naïve : le préchauffage manuel

Beaucoup d'équipes règlent cela en ouvrant un navigateur et en cliquant sur leurs pages les plus importantes avant la vente. Ça marche, une fois. Cela préchauffe le cache desktop pour un seul user-agent depuis un seul emplacement. Les visiteurs mobiles, Googlebot et les utilisateurs servis par d'autres nœuds edge du CDN tombent toujours sur des pages froides.

La bonne solution : le préchauffage automatisé multi-variantes

Un préchauffage pré-vente digne de ce nom doit couvrir :

  1. Toutes les URLs concernées : pas seulement la page d'accueil, mais la page boutique et chaque page produit et catégorie touchée par la vente
  2. Plusieurs user-agents : Chrome desktop, Safari mobile, Googlebot
  3. Plusieurs régions : si vous avez un CDN ou du trafic international, car chaque point de présence garde son propre cache

Avec CacheBoost, vous pouvez déclencher cela via l'API depuis votre script de lancement de vente, avec une clé disposant du scope boosts:write :

curl -X POST https://api.cache-boost.com/v1/boosts/{boost_id}/run \
  -H "Authorization: Bearer cb_live_..." \
  -H "Content-Type: application/json"

Tant qu'un run de ce boost est en cours, l'API refuse d'en lancer un autre (réponse 409). Terminez donc vos modifications de prix avant de lancer le préchauffage, sinon les pages purgées après le passage du run resteront froides.

Vous pouvez aussi utiliser le plugin WordPress, qui couvre deux cas :

  • Mode Smart : à chaque enregistrement d'un produit, il préchauffe sa fiche et ses catégories. La page boutique et la page d'accueil n'en font pas forcément partie.
  • Mode Full : il lance un boost complet lors d'une purge globale, par exemple un vidage complet de WP Rocket, W3 Total Cache, LiteSpeed ou WP Super Cache, un changement de thème ou de menu, ou une mise à jour d'extension.

Une modification de prix produit par produit ne déclenche donc pas de préchauffage complet. Pour un événement comme le Black Friday, gardez un run complet explicite dans votre plan de lancement.

Bien chronométrer votre préchauffage

Commencez par une répétition générale, plusieurs jours avant l'événement : lancez le boost de la vente et notez sa durée dans l'historique des exécutions. Elle varie fortement selon le nombre d'URLs, de variantes et de régions, et selon la vitesse de votre origine : de quelques minutes à plus de vingt minutes d'un site à l'autre.

Ensuite, la séquence type :

  1. Avant T-0, avec une marge d'au moins deux fois la durée mesurée : mise à jour des prix et des stocks dans WooCommerce (cela vide le cache), puis plus aucune modification
  2. Juste après : le préchauffage CacheBoost démarre (appel API ou hook du plugin)
  3. Avant T-0 : vérifiez que le run est terminé et contrôlez quelques URLs depuis une autre région
  4. T-0 : la vente démarre. Les pages sont déjà chaudes, les visiteurs obtiennent des réponses en cache

Vérifiez aussi votre TTL : il doit dépasser largement l'écart entre la fin du run et le pic de trafic, sinon les pages préchauffées auront expiré avant l'arrivée des visiteurs.

Le cas des promotions programmées

Si vous utilisez les dates de promotion de WooCommerce, le prix bascule tout seul. Les versions récentes le font à l'heure prévue, produit par produit ; les plus anciennes passaient par une tâche quotidienne, parfois décalée. Dans les deux cas, vous ne pouvez pas préchauffer un prix qui n'est pas encore en ligne. Vous avez deux options :

  • Appliquer les prix un peu avant l'annonce : le trafic vient surtout de votre newsletter ou de vos publicités. Mettez les prix à jour, préchauffez, puis envoyez l'annonce à T-0. C'est l'option la plus sûre pour le cache, si quelques visiteurs peuvent voir les prix en avance.
  • Garder la programmation et lancer un boost juste après la bascule : par exemple avec une expression cron ou un appel API planifié. Les premiers visiteurs peuvent alors tomber sur des pages froides pendant le run.

Dans le second cas, testez d'abord sur un seul produit. Tous les plugins de cache ne réagissent pas de la même façon à cette bascule automatique : assurez-vous que la page est bien purgée, sinon l'ancien prix reste affiché jusqu'à l'expiration du cache.

Gérer le stock pendant la vente

Une fois la vente lancée, les commandes affluent. Chaque commande modifie les niveaux de stock, ce qui peut déclencher des purges de cache. Vous avez deux options :

  • Définir un TTL de cache élevé et limiter les purges liées au stock : si vos chiffres de stock n'apparaissent pas sur la page (ou que vous tolérez un léger délai), c'est le choix le plus simple, surtout à fort volume.
  • Activer le préchauffage sur changement de stock dans le plugin CacheBoost (désactivé par défaut) : chaque modification de stock déclenche un préchauffage ciblé de la fiche concernée. Les URLs sont regroupées à l'échelle d'une commande, mais pas entre commandes : 50 commandes peuvent donc donner jusqu'à 50 appels API. Réservez ce réglage aux volumes modérés. À fort volume, préférez un boost planifié à intervalle régulier sur les pages de la vente.

Surveiller l'événement

Pendant un événement à fort trafic, gardez un œil sur :

  • Le taux de cache hit dans votre dashboard CDN ou Varnish : une chute soudaine indique que les pages sont purgées plus vite qu'elles ne sont préchauffées
  • L'historique des exécutions CacheBoost : vérifiez que les préchauffages se terminent avec succès
  • Le TTFB via un outil de real-user monitoring : un TTFB qui monte pendant l'événement est souvent le premier signal d'un problème de cache froid

Le préchauffage ne remplace pas le dimensionnement du serveur : le panier, le paiement et le compte client ne sont pas servis depuis le cache et sollicitent toujours votre origine. Mais en servant les pages de catalogue depuis le cache, il laisse cette capacité aux visiteurs qui achètent. Faites votre répétition générale dès maintenant : c'est le meilleur moment pour découvrir ce qui reste froid, tant qu'il n'y a pas encore de clients sur le site.

Cet article est aussi disponible en English.