Chapitre #5 de la série AWS WordPress — retour d’expérience sur la performance après les expériences d’architecture #1 à #4.
Depuis des années, les discussions sur la performance WordPress tournent autour des mêmes sujets :
- des VPS plus rapides,
- des plugins de cache,
- Redis,
- LiteSpeed,
- Kubernetes,
- des architectures « headless »,
- ou simplement « plus de CPU ».
Et si tout cela compte, mon expérience de WordPress sur AWS m’a appris autre chose :
Les problèmes de performance sont souvent des problèmes d’entropie avant d’être des problèmes de calcul.
Dans mon cas, je n’ai pas augmenté de façon spectaculaire la performance intrinsèque de l’infrastructure elle-même. J’ai progressivement retiré du travail inutile à l’instance EC2.
Le résultat a été étonnamment efficace, non parce que le serveur est devenu plus puissant, mais parce qu’il a cessé de gaspiller des ressources à servir du bruit.
1. L’objectif initial
L’objectif de départ était relativement simple :
- héberger WordPress de façon sécurisée,
- maîtriser les coûts,
- absorber les pics de trafic,
- éviter le surdimensionnement,
- et expérimenter des patterns architecturaux natifs AWS.
À l’époque, la stack a progressivement évolué vers quelque chose comme ceci :
Ce qui est intéressant, c’est que la plupart des optimisations ne visaient pas à accélérer WordPress lui-même, mais à réduire la quantité de travail inutile qui lui parvenait.
2. Le mythe de la « performance WordPress »
Une idée reçue courante veut que la performance WordPress repose surtout sur :
- la vitesse d’exécution PHP,
- le tuning de la base de données,
- les plugins,
- la puissance du serveur.
Mais en pratique, une grande part de la charge infrastructure provient souvent de :
- bots,
- crawlers,
- tentatives de brute force,
- transformations d’images,
- cache misses,
- requêtes mal formées,
- scanners,
- sondes sur l’administration,
- abus de XML-RPC,
- et autres formes de « bruit de fond d’Internet ».
En d’autres termes :
Le serveur est souvent occupé à servir des choses qui n’auraient jamais dû l’atteindre.
Cette prise de conscience a changé ma façon d’aborder l’optimisation.
3. Le trou du lapin de l’optimisation d’images
Comme beaucoup, j’ai d’abord voulu optimiser les images dynamiquement.
L’idée était élégante :
- stocker les images originales dans S3,
- générer des variantes WebP à la demande,
- mettre le résultat en cache,
- servir les assets optimisés via CloudFront.
L’architecture ressemblait grossièrement à ceci :
Techniquement, ça fonctionnait. En pratique, les choses se sont compliquées.
L’enfer des URL WordPress
Un défi inattendu venait de WordPress lui-même.
WordPress génère les URL d’images dynamiquement via plusieurs mécanismes :
- src
- srcset
- miniatures
- variantes responsive
- plugins
- blocs de l’éditeur
- images à la une
J’ai donc fini par écrire un plugin WordPress sur mesure, chargé de réécrire les URL d’images vers le pipeline d’optimisation.
/wp-content/uploads/image.jpg
Devenait :
https://cdn.example.com/image.jpg?w=800&format=webp
Le problème, c’est que WordPress adore générer des variantes automatiquement.
Si seul src est réécrit mais pas srcset, les navigateurs peuvent encore récupérer les JPEG originaux.
Cela a mené à une longue série d’expérimentations autour de :
- la normalisation des URL,
- les stratégies de clés de cache,
- la gestion des query strings,
- les variantes d’images responsive,
- la fragmentation du cache CDN.
Ironiquement, l’optimisation d’images est rapidement devenue l’une des parties les plus complexes de la stack.
Quand CloudFront et CloudFlare ont empiré les choses
Un moment particulièrement instructif : la performance s’est dégradée de façon inattendue après l’introduction de CloudFront dans le flux de traitement d’images.
Cela paraît contre-intuitif.
Les CDN sont censés améliorer la performance, et c’est généralement le cas.
Mais les architectures sont des systèmes, pas de la magie.
Ce qui s’est probablement produit, c’est une combinaison de :
- amplification des cache misses,
- fragmentation liée aux query strings,
- cold starts Lambda,
- trop de variantes générées,
- latence de fetch vers l’origine,
- surcharge d’initialisation Sharp,
- clés de cache incohérentes.
Le résultat :
l’infrastructure passait plus de temps à générer et synchroniser des variantes d’images qu’à servir efficacement les utilisateurs.
C’était une leçon importante :
Les architectures serverless déplacent parfois la complexité plutôt que de l’éliminer.
Et c’était encore pire avec CloudFlare, une fois hors de l’écosystème AWS.
4. L’ennemi invisible : les bots
La prise de conscience la plus marquante est venue plus tard : une part énorme du trafic n’était pas du trafic humain légitime. L’instance EC2 recevait en permanence :
- des scans WordPress,
- des tentatives de brute force sur
/wp-login.php, - des abus de XML-RPC,
- des crawlers SEO,
- des scanners de vulnérabilités,
- de faux bots,
- du bruit aléatoire d’Internet.
Et chaque requête qui atteint PHP a un coût :
- réveils CPU,
- workers PHP,
- requêtes MySQL,
- pression mémoire,
- accès disque,
- surcharge réseau.
À un moment, j’ai compris :
Je n’avais pas d’abord besoin d’un serveur plus puissant, mais de moins de requêtes inutiles.
5. Le WAF comme outil de performance
C’est là qu’AWS WAF s’est révélé étonnamment efficace.
La plupart des discussions présentent les WAF comme de purs contrôles de sécurité. En pratique, un WAF peut aussi agir comme couche d’optimisation de performance en filtrant le trafic malveillant ou inutile au edge :
- moins de requêtes atteignaient PHP,
- moins de workers se réveillaient,
- moins de requêtes base de données étaient exécutées,
- moins de bande passante était consommée,
- et l’instance EC2 restait réactive pour les vrais utilisateurs.
L’architecture a progressivement basculé vers cette philosophie :
L’EC2 n’est pas soudainement devenu plus puissant : il a simplement cessé de gaspiller des ressources.
6. Le « honeypot » Cognito
L’une des expériences les plus atypiques consistait à protéger l’interface d’administration WordPress derrière AWS Cognito.
Non parce que Cognito sécurisait WordPress par magie, mais parce que cela réduisait la visibilité et l’accessibilité de la surface d’administration elle-même.
Conceptuellement :
L’effet intéressant n’était pas seulement l’authentification, mais la réduction du trafic.
La plupart des attaques automatisées n’atteignaient plus WordPress : le point d’accès admin était devenu effectivement « moins visible ».
Encore une fois :
l’optimisation venait de la réduction du travail inutile avant qu’il n’atteigne les ressources de calcul.
Conclusion : la vraie leçon
Au fil du temps, l’architecture a moins évolué autour de « rendre WordPress plus rapide » que autour de :
- réduire l’entropie,
- filtrer le bruit,
- externaliser les opérations coûteuses,
- minimiser l’exécution PHP inutile,
- et protéger les ressources de calcul.
Cela a changé radicalement l’économie du système.
Une instance EC2 relativement modeste pouvait absorber des charges qui auraient sinon exigé une infrastructure bien plus large.
Non parce que l’application est devenue intrinsèquement plus rapide.
Mais parce que l’infrastructure est devenue plus sélective sur ce qui méritait du temps de calcul.
Et avec du recul, la plus grande optimisation n’était pas le cache, c’était de comprendre que :
La performance consiste souvent à protéger les systèmes du travail inutile avant d’optimiser le travail lui-même.