Le problème : chaque photo produit est une requête
L’e-commerce de mode vit de la photographie. La seule page d’accueil de cette boutique référence plus de 130 images — des sliders de plus de 300 Ko, des photos produit autour de 50-350 Ko — et les pages catégorie et produit répètent le schéma. Sans CDN, chaque visiteur tire chacun de ces fichiers depuis le serveur d’origine : les mêmes photos, des milliers de fois par jour, en concurrence avec les workers PHP et la bande passante qui devraient servir paniers et paiements.
L’objectif n’avait rien d’exotique : sortir entièrement le trafic d’images répétitif de l’origine, garder le HTML suffisamment frais pour une boutique, et le faire sans toucher au thème WordPress.
La règle images : en cache pour un an, servies en millisecondes
Le cœur de la configuration est une règle de diffusion unique qui matche les extensions d’images (jpg, jpeg, png, gif, webp, svg, ico). Elle met en cache les réponses réussies en périphérie pendant une année entière, ajoute un en-tête CORS pour que les images puissent être intégrées où il faut, et compresse ce qui en bénéficie avec Brotli et gzip.
Un an semble agressif jusqu’à ce qu’on se rappelle comment les images produit changent réellement : elles ne changent pas. Une photo téléversée pour un produit garde son URL jusqu’à la mort du produit ; une refonte téléverse de nouveaux fichiers sous de nouveaux noms. Des TTL longs signifient que la périphérie n’a presque jamais à redemander à l’origine — dans notre échantillonnage, chaque image de la page d’accueil était déjà un HIT. Et pour le cas rare où une image doit changer en place, une purge ciblée efface exactement cette entrée.
La règle HTML : un jour, avec une astuce pour le trafic de campagne
Le HTML reçoit un traitement différent : la page d’accueil est mise en cache pendant un jour — assez long pour que la périphérie absorbe presque tout le trafic anonyme, assez court pour que les changements de merchandising apparaissent le jour même, et une purge gère tout ce qui est urgent.
Le détail qui mérite d’être volé, c’est la normalisation de la query. Le trafic des campagnes sociales arrive avec des paramètres de tracking — chaque clic Facebook porte un fbclid unique. Mis en cache naïvement, chaque clic serait une URL « différente », chaque visiteur de campagne un MISS de cache, et l’origine encaisserait toute la charge du pic publicitaire au pire moment. La règle exclut fbclid de la clé de cache, si bien que dix mille clics de campagne sont une seule entrée de cache. Le paramètre atteint toujours l’analytics ; il cesse simplement de fragmenter le cache.
Ce que nous avons mesuré
Des chiffres du site en production, mesurés à travers l’internet public (ils incluent donc la vraie distance réseau, pas des conditions de labo). Une image en cache répond avec un time-to-first-byte médian d’environ 0,15 seconde. Forcer la périphérie à récupérer le même fichier depuis l’origine met la médiane autour de 0,54 seconde — grosso modo 3,5 fois plus lent. Le HTML de la page d’accueil, servi en HIT de cache avec compression Brotli, commence à arriver en environ 0,27 seconde.
Multipliez cet écart par 130+ images par page vue et l’effet sur la vitesse perçue n’a rien de subtil : le navigateur commence à peindre les photos produit alors qu’une configuration sans cache attendrait encore les premières. Et chaque HIT est une requête que l’origine ne voit jamais — pendant un pic de campagne, le travail de l’origine se réduit à servir les paniers.
Le reste de la pile : Redis et WAF sans effort supplémentaire
Deux pièces de plus tournent à côté du cache, toutes deux activées plutôt que construites. À la couche d’hébergement, un cache objet Redis épaule WordPress, transformant les requêtes base de données répétées — options, menus, métadonnées produit — en lectures mémoire pour les requêtes qui atteignent réellement PHP. En frontal, le preset WAF du compte inspecte le trafic entrant à la même périphérie que celle qui sert le cache, si bien que les schémas d’attaque courants sont filtrés avant même de faire la queue pour l’origine.
Note de bas de page honnête : ce client n’utilise pas notre optimisation d’images WebP/AVIF — les chiffres ci-dessus sont du pur cache et de la compression. Il reste une marge mesurable sur la table (les formats modernes réduisent généralement de façon substantielle le poids des images), ce qui rend le résultat plus transposable, pas moins : voilà ce que fait le cache de périphérie à lui seul.
Quoi copier pour votre propre boutique
Le schéma se transpose à tout site saturé d’images en quatre règles pratiques. Mettez les images en cache par extension avec un TTL long et purgez au changement, plutôt que des TTL courts « par sécurité » — la sécurité, c’est le rôle de la purge. Mettez votre HTML en cache pour des heures ou un jour, pas zéro, et laissez une purge au déploiement gérer la fraîcheur. Normalisez les paramètres de tracking (fbclid, et utm_* là où l’analytics le permet) hors de la clé de cache avant votre prochaine campagne, pas après qu’elle a fait fondre l’origine. Et vérifiez avec des mesures, pas au ressenti : un curl avec un anti-cache contre un curl sans vous dit exactement ce que la périphérie vaut sur vos propres pages.
Questions fréquentes
Un TTL images de 1 an est-il sûr pour l’e-commerce ?
Oui, parce que les URL d’images produit sont stables : les nouveaux produits amènent de nouveaux noms de fichiers. Le cas à risque — remplacer une image à la même URL — est géré par une purge ciblée, qui prend effet en quelques secondes.
Pourquoi ne mettre la page d’accueil en cache qu’un jour quand les images ont un an ?
Le HTML change avec le merchandising — campagnes, prix, produits mis en avant. Un jour signifie que la périphérie absorbe encore presque tout le trafic de lecture, tandis que les changements du jour apparaissent sans que personne n’y pense ; les changements urgents sont à une purge de distance.
Qu’est-ce qu’exclure fbclid de la clé de cache fait concrètement ?
Sans cela, chaque clic publicitaire est une URL unique et donc un MISS de cache — votre trafic payant, le plus cher que vous ayez, atterrit intégralement sur l’origine. Avec, tous les clics partagent une seule entrée en cache. Le paramètre atteint toujours vos scripts d’analytics, inchangé.
WebP/AVIF aurait-il rendu tout cela encore plus rapide ?
Il réduirait encore les tailles de transfert (souvent 30-70 % sur les photos), et c’est exactement pourquoi nous précisons que ce client l’a désactivé — le chiffre de 3,5x, c’est le cache seul. Activer l’optimisation d’images s’empile par-dessus tout ce qui est décrit ici, elle ne le remplace pas.
Dois-je modifier mon thème WordPress pour tout cela ?
Non. Tout ce qui figure dans cette étude de cas — règles de cache, normalisation de la query, compression, WAF, Redis — est configuré à la couche de diffusion et d’hébergement. L’application n’a pas été modifiée.