« load average: 4.82, 4.15, 3.90 » sur un serveur qui, la semaine précédente, tournait tranquillement autour de 0,8. Le tableau de bord d’hébergement d’un cabinet de conseil ne montrait pourtant aucune hausse de trafic, aucune campagne publicitaire, aucun pic d’audience. Le nombre de visites journalières était resté strictement stable. Seule la consommation CPU avait décollé, du jour au lendemain, sans corrélation apparente avec un événement identifiable.
La compression de réponse HTTP réduit la taille des données transmises au navigateur en les passant par un algorithme comme gzip ou brotli avant l’envoi. Cette opération, si elle allège le réseau, coûte du temps de calcul processeur : plus le taux de compression visé est élevé, plus l’opération est coûteuse. Une compression appliquée une fois sur une réponse déjà compressée n’apporte quasiment aucun gain supplémentaire, mais paie deux fois le prix en calcul.
Le symptôme : une charge qui ne colle pas avec le trafic
Le premier réflexe a consisté à croiser les journaux d’accès avec la charge du serveur, minute par minute. Aucune requête suspecte, aucun robot mal identifié, aucune montée en charge légitime ne correspondait aux pics observés. Le nombre de processus PHP-FPM actifs restait dans une fourchette normale. Le suspect s’est révélé ailleurs : la commande top, lancée pendant un pic, montrait un processus nginx consommant une part de CPU disproportionnée par rapport au nombre de connexions qu’il traitait.
Le diagnostic : deux couches de compression superposées
La configuration du serveur web activait la compression gzip au niveau du bloc server :
gzip on;
gzip_comp_level 6;
gzip_types text/html text/css application/javascript application/json;Une extension de performance installée deux semaines plus tôt, dans le but justement d’améliorer les temps de chargement, embarquait de son côté sa propre logique de compression PHP, activée par défaut à l’installation, via ob_start( 'ob_gzhandler' ) placé tôt dans le cycle de chargement de WordPress. Résultat : la réponse HTML était compressée une première fois par PHP via cette extension, puis nginx, ignorant que le contenu était déjà compressé, tentait de le recompresser une seconde fois avant de l’envoyer au navigateur.
Cette double compression n’était pas seulement un gaspillage de calcul : elle produisait parfois une réponse corrompue, gzip refusant de compresser un flux déjà compressé sans le détecter systématiquement, ce qui explique certains rendus de page occasionnellement tronqués signalés par deux utilisateurs dans les jours précédents.
Le correctif : une seule couche, choisie consciemment
Le choix s’est porté sur la compression côté serveur web, plus efficace et moins coûteuse en ressources PHP puisqu’elle s’exécute en C plutôt qu’en PHP interprété. La désactivation de la compression applicative de l’extension a consisté à retirer l’option correspondante dans ses réglages, sans désinstaller l’extension elle-même dont les autres fonctionnalités restaient utiles :
// Dans les réglages de l'extension, la case "Compression GZIP"
// a été décochée ; en dur, cela revient à ne plus appeler :
// ob_start( 'ob_gzhandler' );La charge CPU est revenue à son niveau habituel dans l’heure suivant le changement, confirmée par une comparaison des relevés load average avant et après intervention.
Comment repérer une double compression avant qu’elle ne pèse
- Inspecter l’en-tête de réponse
Content-Encodingvia les outils de développement du navigateur : une seule valeur doit apparaître, jamais deux couches successives. - Vérifier, dans la configuration du serveur web, si la compression est déjà activée avant d’installer une extension qui promet de l’activer à son tour.
- Surveiller la charge CPU juste après l’installation de toute extension de performance, période où ce type de conflit apparaît le plus souvent.
Une extension qui promet d’accélérer le site ne fait pas toujours l’inventaire de ce que le serveur fait déjà : la prudence consiste à vérifier avant d’empiler.
Prévention pour la suite
L’équipe a ajouté une étape systématique à sa procédure d’installation d’extension : vérifier l’en-tête Content-Encoding de la page d’accueil avant et après activation, et comparer la charge CPU sur les trente minutes suivantes. Un contrôle simple, qui aurait permis de repérer le conflit dès son apparition plutôt que deux semaines plus tard.
En résumé
La charge CPU anormale ne venait ni d’un pic de trafic ni d’une attaque, mais d’un gaspillage silencieux : deux couches de compression appliquées à la même réponse, l’une par le serveur web, l’autre par une extension récemment installée. Retirer l’une des deux a suffi à ramener la charge à la normale, sans toucher au reste de la configuration.
