Un site WordPress à audience internationale, hébergé sur un unique VPS situé en Europe, impose mécaniquement une latence supplémentaire aux visiteurs situés en Amérique du Nord ou en Asie, simplement à cause de la distance physique parcourue par chaque requête. Fly.io propose une approche différente d’un VPS classique : déployer une application conteneurisée simultanément dans plusieurs régions géographiques, avec un routage automatique qui dirige chaque visiteur vers l’instance la plus proche de lui.
Cette approche ne remplace pas la réflexion nécessaire sur l’architecture de la base de données, qui doit rester cohérente entre les régions, mais elle change concrètement la latence perçue côté visiteur pour la partie applicative du site.
Conteneuriser WordPress pour Fly.io
Fly.io déploie une image Docker, ce qui suppose d’avoir un WordPress déjà conteneurisé, avec un Dockerfile proche de celui utilisé pour tout déploiement Docker classique :
FROM wordpress:6.4-php8.2-fpm
COPY wp-content /var/www/html/wp-content
COPY nginx.conf /etc/nginx/conf.d/default.confConfigurer le déploiement multi-région
Le fichier fly.toml, généré et complété via la commande fly launch, définit les régions de déploiement souhaitées :
app = "monsite-wordpress"
primary_region = "cdg"
[http_service]
internal_port = 8080
force_https = true
[[regions]]
regions = ["cdg", "iad", "nrt"]Une fois configuré, une seule commande déploie l’application dans les trois régions déclarées (Paris, Virginie, Tokyo dans cet exemple), chacune recevant une copie fonctionnelle de l’application :
fly deployLe point critique : la base de données
Fly.io déploie l’application dans plusieurs régions, mais une base de données MySQL classique reste, elle, hébergée dans une seule région physique. Chaque instance applicative distante doit alors interroger cette base à travers le réseau, ce qui réintroduit une latence, cette fois côté base de données plutôt que côté rendu de page. Deux stratégies s’offrent à cette contrainte : accepter cette latence résiduelle sur les requêtes de base de données (souvent acceptable si l’essentiel du contenu est mis en cache), ou mettre en place une réplication de lecture régionale, nettement plus complexe à opérer pour WordPress.
Un cache agressif devient indispensable
Pour tirer un vrai bénéfice de ce déploiement multi-région, la majorité des pages doivent être servies depuis un cache de page complet (via une extension de cache ou un cache HTTP en amont), afin de limiter au maximum les allers-retours vers la base de données distante pour chaque visiteur. Sans cette couche de cache, la latence gagnée sur le rendu applicatif est en grande partie compensée par la latence ajoutée sur les requêtes SQL traversant les régions.
Fly.io face à un VPS classique
| Critère | VPS classique unique | Fly.io multi-région |
|---|---|---|
| Latence pour une audience internationale | Élevée pour les régions éloignées | Réduite grâce au routage régional |
| Complexité de la base de données | Simple, une seule instance locale | Complexe si réplication recherchée |
| Coût pour un trafic modeste | Souvent inférieur | Peut dépasser un VPS unique selon le nombre de régions actives |
Un déploiement multi-région n’a de sens que si l’audience est réellement internationale et sensible à la latence. Pour un site à audience majoritairement locale, cette complexité supplémentaire n’apporte aucun bénéfice mesurable.
Les limites à anticiper
- La gestion des médias uploadés doit être centralisée sur un espace de stockage partagé entre régions (compatible S3), sous peine de désynchronisation entre les instances.
- Les mises à jour de plugins ou de contenu via l’administration doivent être pensées pour ne pas créer d’incohérence temporaire entre régions pendant la propagation.
- Le débogage d’un problème spécifique à une région demande des outils de supervision capables de distinguer clairement l’origine géographique de chaque requête.
En résumé
Fly.io permet de rapprocher physiquement un WordPress conteneurisé de ses visiteurs internationaux, à condition d’accepter une réflexion plus poussée sur la gestion de la base de données et des médias que sur un VPS classique unique. Pour un site avec une audience véritablement répartie sur plusieurs continents et un contenu en grande partie cacheable, ce compromis en vaut la peine ; pour un site à audience locale, un VPS classique reste plus simple et souvent plus économique.
