# Combien coûte vraiment un plugin de sondage en direct sur une page à fort trafic

> Mesures avant/après l'ajout d'un module de sondage qui interroge le serveur toutes les cinq secondes, sur un article ayant reçu un pic de visites soudain.

- Auteur : WordPress Développement
- Publié le : 2024-09-21
- Mis à jour le : 2024-09-21
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/cout-plugin-sondage-direct-page-trafic/

## L’essentiel

- Un rafraîchissement toutes les cinq secondes multiplie vite les requêtes serveur
- Le coût grimpe de façon linéaire avec le nombre de visiteurs simultanés
- Un intervalle plus long ou un comptage différé change tout

Un article sur un sujet d'actualité locale a reçu, en l'espace de deux heures, un pic de visite dix fois supérieur à sa moyenne habituelle, à la suite d'un partage massif sur les réseaux sociaux. Un module de sondage en direct, installé sur cet article pour permettre aux lecteurs de voter sur une question liée au sujet, interrogeait le serveur toutes les cinq secondes pour rafraîchir le nombre de votes affiché en temps réel.

Mesurer précisément ce que ce module a coûté pendant ce pic de trafic permet de comprendre à quel point un intervalle de rafraîchissement court, anodin en conditions normales, peut devenir un facteur de charge significatif dès que le nombre de visiteurs simultanés grimpe.

## Le calcul brut du volume de requêtes

Un rafraîchissement toutes les cinq secondes représente douze requêtes par minute et par visiteur resté sur la page, soit sept cent vingt requêtes par heure pour un seul visiteur qui garde l'onglet ouvert. Avec plusieurs centaines de visiteurs simultanés pendant le pic observé, ce chiffre s'est traduit par plusieurs centaines de milliers de requêtes vers le point d'entrée `admin-ajax.php` en l'espace de deux heures, un volume largement supérieur à celui généré par la simple consultation de l'article lui-même.

```
// Extrait simplifié du script JavaScript du module de sondage
setInterval( function () {
    fetch( ajaxurl + '?action=rafraichir_votes&sondage;_id=42' )
        .then( function ( reponse ) { return reponse.json(); } )
        .then( afficherResultats );
}, 5000 );
```

## Ce que chaque requête coûtait côté serveur

Chaque appel à `admin-ajax.php`, même pour une donnée aussi simple qu'un compteur de votes, charge l'intégralité du contexte d'exécution de WordPress avant d'exécuter l'action demandée. Sur ce site, la fonction associée exécutait en plus une requête SQL directe pour recompter les votes en temps réel plutôt que de s'appuyer sur une valeur mise en cache, cumulant le poids du chargement de WordPress et celui d'une requête de comptage à chaque appel.

> L'essentiel à retenir : Un rafraîchissement toutes les cinq secondes multiplie vite les requêtes serveur ; Le coût grimpe de façon linéaire avec le nombre de visiteurs simultanés ; Un intervalle plus long ou un comptage différé change tout

## La mesure avant correctif

| Indicateur | Valeur mesurée pendant le pic |
| --- | --- |
| Requêtes admin-ajax par minute (pic) | environ 3 200 |
| Temps de réponse moyen de ces requêtes | 180 ms |
| Charge CPU serveur attribuable au module | environ 35 % du total |
| Temps de génération de l'article lui-même | inchangé, servi par le cache de page |

Ce tableau illustre un point important : l'article lui-même restait rapide, servi depuis le cache de page. Le coût réel provenait entièrement du sondage, un mécanisme dynamique par nature, qui ne pouvait pas bénéficier de ce même cache de page.

## Les correctifs appliqués

1. Allongement de l'intervalle de rafraîchissement de cinq à trente secondes, réduisant le volume de requêtes d'un facteur six sans dégrader significativement l'expérience perçue par les votants.
2. Mise en cache du résultat du comptage de votes via un transient de courte durée (dix secondes), pour que plusieurs requêtes rapprochées de visiteurs différents ne déclenchent qu'un seul comptage réel en base de données.
3. Ajout d'une limite basse de rafraîchissement quand l'onglet du navigateur n'est plus actif, en s'appuyant sur l'API de visibilité de la page, pour arrêter les appels des visiteurs ayant changé d'onglet sans fermer la page.

## Le résultat après correctif

Avec ces trois ajustements combinés, un pic de trafic comparable observé quelques semaines plus tard sur un autre article a généré une charge CPU attribuable au module inférieure à 6 %, pour un nombre de visiteurs simultanés similaire. Le sondage restait fonctionnellement identique du point de vue du visiteur, avec un affichage qui se met à jour de façon perceptiblement fluide, tout en réduisant considérablement le coût serveur associé.

## En résumé

Un module de sondage ou de compteur en direct, anodin en conditions de trafic normal, peut devenir un facteur de charge dominant dès qu'un pic de visiteurs simultanés survient. Allonger l'intervalle de rafraîchissement et mettre en cache le résultat sous-jacent, même pour quelques secondes, suffit souvent à absorber un pic sans dégrader l'expérience proposée aux visiteurs.