Le site est celui d’un site d’annonces immobilières avec un catalogue de biens accumulé depuis 2016, soit environ 50 000 images stockées localement dans wp-content/uploads, représentant 340 Go d’espace disque sur un serveur mutualisé infogéré facturé notamment au volume de stockage. La migration vers un stockage objet S3, réalisée avec une extension d’offloading standard, a été motivée d’abord par une contrainte d’espace disque et de coût d’hébergement, et seulement ensuite par un espoir vague d’amélioration de performance générale du site.
C’est justement ce deuxième point qui mérite d’être détaillé, car il est souvent mal compris : migrer sa médiathèque vers S3 n’améliore pas mécaniquement le temps de réponse des pages, et peut même le dégrader si la migration s’arrête là.
Ce que la migration change pour le TTFB des pages HTML
Le TTFB (Time To First Byte) mesure le temps que met le serveur à commencer à envoyer la réponse HTML de la page, avant même que le navigateur ne commence à télécharger les images qu’elle contient. Sur ce site, le TTFB moyen des pages de fiche bien, mesuré avant et après migration dans des conditions comparables (cache de page identique, même heure de la journée), est resté quasiment inchangé : 210 millisecondes avant, 205 millisecondes après. Ce résultat n’a rien de surprenant une fois qu’on comprend ce que fait réellement une extension d’offloading : elle remplace les URL des images dans le contenu généré par des URL pointant vers S3 (ou vers un CDN devant S3), mais ne change rien à la manière dont la page HTML elle-même est générée côté serveur.
Où se cache le vrai gain observé
Le gain réel de cette migration se mesure ailleurs que sur le TTFB :
- Espace disque libéré : de 340 Go à environ 4 Go restants (fichiers de thème, extensions, base de données), ce qui a permis de redescendre d’un palier d’hébergement plus coûteux.
- Temps de sauvegarde quotidienne : la sauvegarde complète du site, qui prenait auparavant près de deux heures, s’exécute désormais en quelques minutes puisque les 340 Go d’images ne sont plus inclus dans la sauvegarde applicative (S3 gérant sa propre durabilité et ses propres sauvegardes).
- Charge disque du serveur d’origine : les opérations de lecture de fichiers statiques par le serveur web ont diminué, ce qui a un effet mesurable mais marginal sur la charge générale, bien plus faible que ce que l’intuition suggérerait.
Le piège : un ralentissement du chargement des images sans CDN devant S3
Sur ce projet, la première mise en production a été faite sans CDN devant le bucket S3, avec des images servies directement depuis l’URL S3 régionale. Le résultat a été contre-intuitif pour l’équipe : le temps de chargement complet des pages de fiche bien (incluant les images, mesuré en LCP) a légèrement augmenté, de 2,1 à 2,4 secondes en moyenne, parce que la latence brute d’un bucket S3 dans une région donnée, sans réseau de diffusion de contenu à proximité géographique du visiteur, peut dépasser celle d’un serveur d’origine bien configuré avec un cache HTTP local.
# Avant : image servie directement depuis le serveur d'origine (Europe de l'Ouest)
https://annonces.example.com/wp-content/uploads/2024/11/bien-1234.jpg
# Après migration sans CDN : latence accrue pour les visiteurs loin de la région S3
https://mon-bucket.s3.eu-west-3.amazonaws.com/2024/11/bien-1234.jpg
Le correctif a consisté à placer un CDN devant le bucket, ce qui a ramené le LCP moyen à 1,9 seconde, sous la valeur initiale, grâce à la mise en cache en périphérie des images les plus consultées. Ce point de configuration n’est pas traité en détail ici puisqu’il constitue un chantier séparé de mise en place réseau, mais il est déterminant pour ne pas transformer une migration bénéfique en régression.
Ce qu’il faut retenir sur les attentes
| Métrique | Avant migration | Après migration (sans CDN) |
|---|---|---|
| Espace disque utilisé | 340 Go | 4 Go |
| Durée de sauvegarde | ~2 h | ~8 min |
| TTFB pages HTML | 210 ms | 205 ms |
| LCP fiche bien | 2,1 s | 2,4 s |
Notion : ce que S3 fait vraiment, et ce qu’il ne fait pas
S3 est un service de stockage objet, pas un service de diffusion optimisée par géographie. Il durcit la disponibilité et la durabilité des fichiers (réplication interne chez le fournisseur cloud), il décharge le serveur d’origine de la gestion physique du stockage, mais il ne réduit en rien la latence perçue par un visiteur situé loin de sa région, ni le temps de génération des pages HTML qui n’a jamais dépendu du stockage des images.
Le stockage objet résout un problème d’espace et de résilience, pas un problème de latence perçue ; confondre les deux mène à des attentes de performance qu’aucune migration de ce type ne peut tenir seule.
Hors périmètre
La configuration détaillée d’un CDN devant un bucket S3 (choix du fournisseur, règles de cache, invalidation) n’est pas traitée ici et mériterait un article à part entière, tant les options varient selon le fournisseur cloud et les contraintes budgétaires du projet.
En résumé
La migration de la médiathèque vers S3 a résolu un vrai problème, l’espace disque et le temps de sauvegarde, mais n’a rien changé au TTFB des pages HTML et a temporairement dégradé le LCP tant qu’aucun CDN n’était en place devant le bucket. Le vrai gain de performance perceptible par les visiteurs n’est arrivé qu’après cette étape complémentaire, ce qui invite à ne jamais présenter l’offloading seul comme une optimisation de vitesse.
