Les pics de trafic ne sont pas réservés aux sites d’entreprise. Même une modeste boutique WooCommerce peut voir son trafic tripler à la suite d’une publicité, d’un envoi d’e-mails ou d’une promotion saisonnière bien ciblés.

Prenons l’exemple du Black Friday. Selon NPR, les consommateurs américains ont dépensé 10,8 milliards de dollars en ligne en une seule journée en 2024, et même les plus petites boutiques ont ressenti les effets d’entraînement. Une campagne qui ne génère habituellement que quelques centaines de visites peut soudainement pousser des milliers de personnes à passer commande.

En tant que client Kinsta, vous n’avez pas besoin de changer de niveau d’hébergement à chaque fois que cela se produit. Ce guide présente trois options efficaces : l’utilisation d’un module de performance PHP, l’optimisation de la mise en cache et la réduction de la charge de la base de données.

1. Utiliser le module de performance PHP

La plupart des pics de trafic submergent les sites parce que PHP atteint sa capacité de traitement des requêtes. Lorsque trop de pages non mises en cache ou d’actions de paiement sont effectuées en même temps, les fils de discussion s’empilent et les visiteurs commencent à voir des erreurs, des ralentissements ou des paniers abandonnés.

Le module de performance PHP
Le module de performance PHP

C’est là que le module de performance PHP de Kinsta peut s’avérer très utile. Au lieu de mettre à niveau l’ensemble de votre plan d’hébergement, vous pouvez temporairement augmenter le nombre de threads PHP et l’allocation de mémoire lors des pics d’activité. Vous payez donc les ressources supplémentaires lorsque vous en avez besoin, et rien de plus.

Ajoutez plus de threads et de mémoire avec le module de performance PHP.
Ajoutez plus de threads et de mémoire avec le module de performance PHP.

Prenons l’exemple d’une petite boutique WooCommerce qui organise une vente flash de 48 heures. Leur campagne d’e-mailing triple le trafic pendant la nuit, et tandis que la mise en cache absorbe la plupart des visites de pages de produits, les demandes de paiement augmentent.

Sans threads PHP supplémentaires, les paniers stagnent et les commandes échouent. Des études montrent qu’un acheteur en ligne sur trois abandonne son panier si les pages se chargent trop lentement, ce qui peut se traduire par des milliers de dollars de ventes perdues. En activant le module de performance PHP la veille de la vente, la boutique s’assure que les commandes se déroulent sans encombre, puis le désactive par la suite afin d’éviter de payer pour la capacité inutilisée.

Vous pouvez supprimer le module de performance PHP lorsque les périodes de forte activité sont terminées.
Vous pouvez supprimer le module de performance PHP lorsque les périodes de forte activité sont terminées.

2. Optimiser la mise en cache avant de toucher à votre plan

Avant d’augmenter les ressources, assurez-vous que la mise en cache fait le gros du travail. La mise en cache sert des versions pré-construites de vos pages afin que les visiteurs ne sollicitent pas PHP à chaque requête. Lorsqu’elle est configurée correctement, la majorité des visites de pages de produits et de catégories ne touchent jamais le serveur.

Le problème est que les magasins nuisent souvent à leur propre mise en cache sans s’en rendre compte. Les extensions ou les thèmes peuvent forcer les en-têtes « no-cache », les pages de panier et de paiement peuvent contourner la mise en cache inutilement, ou les réglages CDN peuvent être mal configurés. Chacun de ces problèmes consomme les ressources de PHP et ralentit votre boutique.

Un exemple permet d’illustrer rapidement ce concept. Supposons qu’une petite boutique de vêtements organise des soldes d’été et constate un pic soudain de navigation. Les pages des produits devraient être mises en cache, mais parce que leur thème a ajouté des en-têtes « no-cache », chaque requête d’un visiteur frappe PHP.

Les temps de chargement dépassent les trois secondes, et les clients commencent à rebondir. Après avoir corrigé les en-têtes et confirmé les réponses « HIT » dans leur CDN, le même niveau de trafic a à peine un impact sur PHP, ce qui laisse des ressources disponibles pour les véritables activités de panier et de paiement.

Pour appliquer ce principe à votre boutique, effectuez une rapide vérification de la mise en cache :

  • Vérifiez vos principaux contournements de cache pour détecter les sauts inutiles.
  • Testez dans un navigateur privé ou incognito pour voir ce que les nouveaux visiteurs ressentent.
  • Confirmez que les en-têtes de mise en cache fonctionnent et recherchez les réponses « HIT » au lieu des réponses d’origine.

Couches de mise en cache dans Kinsta

Kinsta gère automatiquement plusieurs couches de mise en cache, mais vous pouvez affiner ou effacer chacune d’entre elles dans MyKinsta :

Mise en cache au niveau du serveur

La mise en cache des pages au niveau du serveur de Kinsta stocke les pages HTML complètes sur le serveur afin que PHP n’ait pas besoin de les reconstruire à chaque visite. Il est activé par défaut sur tous les sites.

server caching

Vous pouvez également vider ce cache en allant dans MyKinsta > WordPress Sites > sitename > Caching > Server Caching et en cliquant sur Clear cache.

Paramètres de mise en cache dans MyKinsta
Ajustez les réglages de mise en cache du serveur dans MyKinsta.

Mise en cache edge

La mise en cache edge pousse ces mêmes pages pré-construites vers le réseau mondial de Cloudflare, les servant à partir du centre de données le plus proche de chaque visiteur. Vous pouvez l’activer ou le désactiver sous Sites WordPress > Cache edge dans MyKinsta.

Vous pouvez activer ou désactiver le cache edge dans MyKinsta.
Vous pouvez activer ou désactiver le cache edge dans MyKinsta.

Cela réduit considérablement la latence et enlève encore plus de charge à votre serveur d’origine.

Cache CDN

Le CDN intégré de Kinsta met en cache les fichiers statiques, tels que les images, CSS et JavaScript, à la périphérie.

Les réglages de mise en cache CDN peuvent également être ajustés dans MyKinsta.
Les réglages de mise en cache CDN peuvent également être ajustés dans MyKinsta.

Vous pouvez configurer l’optimisation des images et exclure des fichiers spécifiques.

Vider les caches manuellement

Pour tout effacer en une fois (serveur, edge et CDN), cliquez sur Vider tous les caches sous MyKinsta > Cache, ou utilisez la commande WP-CLI wp kinsta cache purge –all.

Vous pouvez vider tous les caches en une seule fois dans MyKinsta.
Vous pouvez vider tous les caches en une seule fois dans MyKinsta.

3. Réduire la charge inutile sur la base de données

Même si PHP et la mise en cache sont en bon état, votre base de données peut encore faire baisser les performances. Chaque filtre de produit, page de catégorie ou requête de recherche ajoute à la charge de travail, et pendant les périodes de fort trafic, cette pression se multiplie rapidement.

Imaginez, par exemple, une boutique d’articles ménagers proposant des centaines de produits en promotion pendant le week-end. Les pages de catégories chargent tous les articles en même temps et chaque option de filtre déclenche de lourdes requêtes de base de données.

À mesure que le trafic augmente, les pages se bloquent et les acheteurs frustrés quittent la boutique les uns après les autres. Cependant, en paginant correctement les résultats des produits et en supprimant les filtres inutilisés, la boutique peut réduire considérablement la charge de sa base de données. Les demandes de paiement restent rapides, même lorsque le trafic atteint des sommets.

Voici quelques méthodes simples pour alléger votre base de données :

  • Nettoyez les options chargées automatiquement. Les anciens réglages des extensions et les données inutilisées peuvent s’accumuler dans la table wp_options et ralentir les requêtes. Dans Kinsta, vous pouvez inspecter ces entrées via phpMyAdmin (disponible sous MyKinsta > Sites > Info > Accès de base de données) ou vous connecter via SSH et lancer une requête telle que SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC; pour identifier les grandes options chargées automatiquement.
  • Supprimez les filtres de produits inutilisés. Dans WooCommerce ou dans les réglages de votre extension de filtre, supprimez tous les filtres (couleur, marque, taille, etc.) qui n’influencent pas les conversions. Chaque filtre actif ajoute des requêtes à vos pages d’archives de produits. Utilisez l ‘outil APM de Kinsta pour repérer les requêtes qui augmentent lorsque les acheteurs utilisent des filtres, puis désactivez ceux qui ne valent pas le coût.
  • Paginez les longues boucles. Le chargement de centaines de produits ou d’articles à la fois sollicite inutilement la base de données. Dans votre thème ou vos modèles personnalisés, utilisez WP_Query avec une limite posts_per_page (par exemple, 20 ou 30) et activez la pagination ou les boutons « charger la suite ». Veillez à ce que vos grilles de produits soient légères afin que les pages s’affichent rapidement, même en cas de pic d’activité.
  • Vérifiez les transients et les extensions de recherche. Les outils de recherche mal configurés frappent souvent la base de données plus durement que nécessaire. Les fichiers transitoires se trouvent souvent à l’adresse wp_options et peuvent prendre de l’ampleur au fil du temps. Vous pouvez supprimer ceux qui sont expirés en toute sécurité en utilisant une extension comme WP-Optimize ou directement dans phpMyAdmin avec DELETE FROM wp_options WHERE option_name LIKE '%_transient_%';. Nous vous recommandons de le faire dans notre guide sur l’accélération de WordPress.

Vous vous demandez peut-être maintenant, quand devriez-vous considérer Redis? Seulement si vos outils de surveillance (comme APM) montrent des requêtes identiques répétées ou un temps de base de données par requête constamment élevé. En règle générale, la plupart des boutiques n’ont pas besoin de Redis si la mise en cache et PHP sont correctement réglés. Mais si les revenus projetés à risque l’emportent sur le coût, cela peut valoir la peine de l’activer pour ce mois.

Le nettoyage de la base de données permet de s’assurer que votre boutique ne gaspille pas de ressources, ce qui laisse plus de capacité pour les requêtes qui génèrent réellement des ventes.

Vérifier les performances à l’aide d’outils de surveillance

La mise en place de ces correctifs ne représente que la moitié du travail. Vous devez également vous assurer qu’ils fonctionnent. Des outils comme MyKinsta (en particulier les analyses incluses) et APM permettent de repérer facilement les goulots d’étranglement, qu’il s’agisse de threads PHP qui s’accumulent, de manques de cache ou de requêtes de base de données lentes.

Garder un œil sur les performances de votre site dans MyKinsta.
Garder un œil sur les performances de votre site dans MyKinsta.

En vérifiant ces mesures avant, pendant et après votre campagne, vous êtes sûr de voir exactement où votre site est mis à rude épreuve et de savoir si vos ajustements portent leurs fruits.

Résumé

Vous n’avez pas besoin d’une mise à niveau complète de votre hébergement pour survivre à des ventes importantes ou à des hausses de trafic. Avec une configuration adéquate, les petites boutiques peuvent faire face à une demande soudaine tout aussi efficacement que les grandes entreprises.

La clé est de combiner trois étapes pratiques : utilisez le module de performance PHP pour couvrir les pics temporaires, assurez-vous que la mise en cache fonctionne à plein régime pour que la plupart des visiteurs ne touchent jamais à PHP, et éliminez les contraintes inutiles de la base de données pour que les commandes soient rapides et fiables.

Ensemble, ces correctifs permettent d’éviter les erreurs 500, de réduire les ralentissements et d’aider un plus grand nombre de clients à terminer leur commande. Si vous prévoyez une campagne ou une promotion saisonnière, activez le module de performance PHP à l’avance et associez-le à une mise en cache efficace et à une maintenance régulière de la base de données.

Joel Olawanle Kinsta

Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.