Paris, Zurich ou Francfort : la distance en millisecondes
Ou : la lumière va vite, les câbles beaucoup moins droit.
La réponse courte : la localisation du serveur n’est pas, en elle-même, un critère de classement décisif. Dans sa documentation sur la gestion des sites multirégionaux, Google la décrit comme un signal possible du public visé, mais pas un signal définitif, puisque beaucoup de sites passent par des CDN, des réseaux de serveurs relais. Ce qui compte pour le visiteur, et donc pour le référencement par le biais de la vitesse, c’est la latence : le temps d’un aller-retour entre son appareil et le serveur. C’est l’un des leviers de la vitesse d’un hébergeur, et le plus facile à anticiper.
Pour un public belge, français ou suisse, un serveur à Paris, Strasbourg, Zurich, Genève ou Francfort fait à peu près le même effet : de 5 à 30 millisecondes par aller-retour selon les paires de villes. Un serveur en Amérique du Nord, en revanche, en ajoute 80 à 95 à chaque aller-retour, et un premier affichage en demande plusieurs.
Pour qui : un site dont les visiteurs sont en Belgique, en France ou en Suisse, et qui veut un serveur à quelques millisecondes d’eux.
À partir de : 5,75 € par mois hors taxes pour l’hébergement web Infomaniak, facturés à l’année (relevé du 12 novembre 2026).
Pour démarrer : choisir l’hébergement web Infomaniak, servi depuis des centres de données situés en Suisse, puis mesurer la latence depuis le pays de vos visiteurs pendant l’essai.
Localisation du serveur et SEO : ce que coûte vraiment la distance
La société WonderNetwork publie le temps d’aller-retour moyen entre ses propres serveurs, ville par ville. Ce ne sont pas les centres de données des hébergeurs, ni des mesures faites par ce site, mais ce sont des chiffres publics et datés.
| Trajet | Distance à vol d’oiseau | Aller-retour moyen |
|---|---|---|
| Bruxelles, Amsterdam | 163 km | 5,1 ms |
| Genève, Zurich | 226 km | 5,3 ms |
| Genève, Strasbourg | 291 km | 7,5 ms |
| Bruxelles, Francfort | 317 km | 10,4 ms |
| Bruxelles, Paris | 262 km | 15,0 ms |
| Paris, Francfort | 477 km | 16,2 ms |
| Bruxelles, Zurich | 492 km | 18,7 ms |
| Bruxelles, Genève | 532 km | 22,5 ms |
| Paris, Zurich | 489 km | 23,2 ms |
| Bruxelles, Helsinki | 1 637 km | 33,1 ms |
| Paris, Montréal | 5 504 km | 83,6 ms |
| Bruxelles, Montréal | 5 535 km | 92,6 ms |
Source : les relevés de ping de WonderNetwork depuis Bruxelles, Paris et Genève, consultés le 12 novembre 2026.
Le tableau contient sa propre leçon. Depuis Bruxelles, Francfort, à 317 km, répond plus vite que Paris, à 262 km. Les câbles et les points d’interconnexion entre réseaux ne suivent pas la carte routière ; deux villes proches peuvent être mal reliées, deux villes éloignées très bien.
La physique donne le plancher. Dans une fibre optique, la lumière parcourt environ 200 000 kilomètres par seconde, la valeur de référence qu’utilise WonderNetwork. Un aller-retour de 1 000 kilomètres coûte donc au minimum 10 millisecondes (calcul : 2 000 km divisés par 200 000 km/s). Sur les trajets du tableau, les temps mesurés valent de moins de deux à plus de cinq fois ce plancher, d’après le rapport à la vitesse de la lumière que publie WonderNetwork pour chaque paire de villes : les paquets font des détours et traversent des routeurs.
Ce qui transforme quelques millisecondes en temps perceptible, c’est leur multiplication. Avant le premier octet d’une page HTTPS, une nouvelle connexion demande au moins trois allers-retours : la connexion TCP, la négociation TLS 1.3, puis la requête. Le calcul, sur les moyennes du tableau :
| Visiteur | Serveur | Trois allers-retours |
|---|---|---|
| Bruxelles | Paris | environ 45 ms |
| Bruxelles | Francfort | environ 31 ms |
| Paris | Zurich | environ 70 ms |
| Paris | Montréal | environ 250 ms |
À cela s’ajoutent la résolution DNS et le temps de calcul du serveur. Pour un public européen, la différence entre deux villes du continent reste sous le dixième de seconde ; pour un visiteur de l’autre côté de l’Atlantique, la distance pèse autant que le serveur.
Trois conseils en découlent :
- Choisissez le centre de données d’après la majorité de vos visiteurs, pas d’après le siège de l’hébergeur. Le pays de l’hébergeur, pour le droit applicable, est une autre question.
- Mesurez la latence vous-même :
pingvers l’adresse du serveur, ou la variabletime_connectdecurl, qui vaut à peu près un aller-retour. - Si votre public est réparti sur deux continents, la localisation ne suffit plus : il faut rapprocher les copies, pas le serveur.
Rapprocher les copies plutôt que le serveur
Un CDN garde des copies des fichiers sur des relais proches des visiteurs lointains. Pour un public concentré à quelques centaines de kilomètres du serveur, le gain est mince ; pour un public partagé entre l’Europe et le Canada, il change l’affichage. Les cas sont triés dans un CDN pour un public lointain.
Trois allers-retours avant le premier octet
La latence ne se voit jamais seule : elle se lit dans le TTFB, le délai avant le premier octet, à côté du temps de calcul du serveur. La commande qui sépare les deux, et les seuils à viser, sont dans le temps avant le premier octet.
Économiser un aller-retour
Avec QUIC, HTTP/3 fusionne la connexion et le chiffrement, et retire un aller-retour à chaque nouvelle connexion. Plus le serveur est loin, plus l’économie compte, comme le montre le gain réel de HTTP/3.