Pourquoi la latence compte pour les serveurs de jeu et l'expérience joueur

Ce que la latence fait réellement à un jeu multijoueur

La latence est le délai entre le moment où un joueur fait quelque chose et celui où le monde du jeu y réagit. Appuyez sur la détente, et il s'écoule un instant avant que le serveur ne confirme le tir, ne décide s'il a touché, et n'informe tous les autres clients de ce qui s'est passé. Gardez cet écart petit et constant, et le jeu paraît précis : les tirs touchent là où vous visez, les mouvements sont nets, les autres joueurs se déplacent avec fluidité. Laissez-le grandir ou fluctuer, et le même jeu paraît mou, injuste ou cassé, alors même que rien n'a réellement échoué sur aucune machine.

La chose la plus utile à comprendre est que le ping ne raconte pas toute l'histoire. Le ping mesure une seule étape du trajet, l'aller-retour réseau. Ce que ressent un joueur est une chaîne plus longue qui inclut aussi la fréquence à laquelle le serveur met à jour le monde, la façon dont le client masque le délai, et la stabilité ou l'instabilité de la connexion. Un serveur peut afficher un excellent ping et paraître quand même exécrable, et un serveur à deux mille kilomètres peut très bien convenir pour le bon genre de jeu.

Pour un hébergeur, la réponse tient en une ligne : placez le serveur près de vos joueurs, sur du matériel qui tient son tick rate sous charge. Tout ce qui suit explique pourquoi ces deux facteurs dominent, et ce que vous pouvez ou ne pouvez pas faire pour le reste.

Cet article vient compléter notre guide sur l'hébergement de serveurs de jeu en bare metal et notre analyse plus approfondie des performances de jeu en bare metal face à la virtualisation. Ici, l'angle est plus précis : d'où vient le délai, et comment il atteint le joueur.

L'anatomie d'un aller-retour

Quand un joueur clique, le délai qu'il ressent est la somme de plusieurs étapes, dont seule une partie relève du réseau. En suivant une entrée de la souris jusqu'à l'écran :

1. Échantillonnage de l'entrée. Le client interroge la souris et le clavier selon son propre cycle. Votre clic peut patienter une image ou deux avant même que la boucle de jeu ne le lise. À 120 fps, cela représente quelques millisecondes ; à 30 fps, plus de 30.
2. Envoi client. Le client assemble l'entrée et l'envoie. Les clients regroupent aussi les envois selon leur propre cadence, ce qui peut ajouter une brève attente avant que le paquet ne parte.
3. Dernier kilomètre. Le paquet traverse la connexion du joueur lui-même : Wi-Fi, routeur domestique, réseau d'accès, jusqu'au premier vrai saut. C'est là que naît une grande partie de la latence côté particulier, et l'essentiel du jitter.
4. Transit et peering. Le paquet traverse un ou plusieurs réseaux pour atteindre celui du serveur. La rapidité du trajet dépend du peering : un chemin bien peeré passe la main à un point d'échange internet dans la même région, un chemin mal peeré fait d'abord un détour par un autre pays.
5. File d'attente serveur. Le paquet arrive et attend d'être lu par le processus de jeu.
6. Alignement sur le tick. C'est l'étape que l'on oublie. Le serveur n'agit pas sur votre entrée dès son arrivée. Il agit au prochain tick de simulation. Si le serveur effectue 20 ticks par seconde, votre entrée peut attendre jusqu'à 50 ms avant le prochain tick, avant qu'il ne se passe quoi que ce soit, peu importe la rapidité du réseau.
7. Traitement. Le tick exécute la simulation : il applique votre entrée, résout les impacts, déplace les entités et détermine le nouvel état du monde. Si le serveur est surchargé et qu'un tick dépasse son budget, cette étape s'allonge et tous les joueurs le ressentent en même temps.
8. Trajet retour. Le serveur renvoie l'état mis à jour, et tout le trajet réseau se répète en sens inverse avant que votre écran n'affiche le résultat.

Le ping mesure, en gros, les étapes trois, quatre et huit, et rien d'autre. C'est pourquoi le ping est nécessaire mais pas suffisant. Deux serveurs avec un ping identique de 30 ms peuvent se ressentir différemment parce que les étapes un, deux, six et sept diffèrent. L'alignement sur le tick, en particulier, est invisible pour le ping et souvent plus important que le délai réseau sur un jeu à faible tick rate.

Le tick rate et la latence sont deux horloges différentes

Un serveur simule le monde par étapes discrètes appelées ticks. Le tick rate correspond au nombre de ces étapes exécutées par seconde, et il fixe la granularité de tout ce que fait le serveur. C'est une horloge distincte de la latence réseau, et il faut garder les deux courtes.

L'arithmétique est simple. Minecraft fait tourner son monde à 20 ticks par seconde, un tick toutes les 50 ms, selon le propre modèle de tick du jeu. Donc même sur un serveur situé dans le même bâtiment, une entrée Minecraft peut attendre jusqu'à 50 ms pour le prochain tick, et le timing de la redstone est quantifié par pas de 50 ms. Ce n'est pas du lag causé par un mauvais hébergeur, c'est la conception du jeu.

Les jeux de tir compétitifs tournent bien plus vite car ils ont besoin d'un timing plus fin. Riot a bâti Valorant sur des serveurs à 128 ticks, un tick toutes les 7.8 ms, précisément pour qu'un défenseur ait le temps de réagir à un attaquant qui passe un angle. Counter-Strike 2 a pris une autre voie : ses serveurs tournent à 64 ticks, mais Valve a ajouté un système de subtick qui horodate chaque entrée à la milliseconde près et l'applique au moment exact où elle s'est produite plutôt que de l'arrondir au prochain tick, ce qui doit combler l'essentiel de l'écart avec une véritable sensation de 128 ticks. Que cela y parvienne pleinement reste débattu parmi les joueurs, mais l'intention de conception est claire : réduire le délai d'alignement sur le tick sans doubler la charge de travail du serveur.

Les jeux de survie et bac à sable se situent plus bas et misent sur la configurabilité. Rust et ARK exposent le tick rate comme paramètre serveur, et les instances gérées par la communauté le laissent souvent autour de 30, sacrifiant la réactivité pour préserver de la marge CPU sur les machines qui hébergent de grands mondes. Ce qui compte n'est pas le chiffre exact d'un titre donné, qui change d'un patch à l'autre, mais la tendance générale.

Les tick rates changent d'une version du jeu à l'autre et sont configurables sur les titres autohébergés ; considérez ceci comme un ordre de grandeur, pas une fiche technique. Vérifiez le chiffre actuel pour votre version avant de le citer.

Augmenter le tick rate raccourcit l'attente d'alignement sur le tick, et rien d'autre. Cela ne raccourcit pas le câble. Un serveur à 128 ticks sur le mauvais continent fait quand même attendre l'aller-retour aux joueurs ; un serveur à 20 ticks dans la bonne ville leur fait quand même attendre 50 ms pour le prochain tick. Les deux horloges sont réelles, et un bon hébergeur s'occupe des deux.

Comment le netcode masque le délai, et où l'illusion se brise

Aucun tick rate ni aucun peering ne ramène la latence à zéro, alors les jeux mentent de façon convaincante à la place. Le netcode est l'ensemble des techniques qui masquent le délai au joueur. Quatre d'entre elles comptent le plus.

Prédiction côté client. Plutôt que d'attendre que le serveur confirme votre mouvement, le client l'affiche immédiatement, en prédisant ce que le serveur validera presque certainement. Votre personnage bouge dès que vous appuyez sur avancer. Quand la mise à jour faisant autorité du serveur arrive et concorde, vous ne remarquez rien. Quand elle diverge, le client corrige.

Interpolation des entités. Les positions des autres joueurs arrivent sous forme d'instantanés discrets, espacés selon le tick rate et rendus irréguliers par le réseau. Pour les afficher avec fluidité, le client conserve un petit buffer et les restitue légèrement dans le passé, en interpolant entre les deux dernières positions connues. C'est pourquoi les autres joueurs paraissent fluides même sur une connexion modeste. Cela signifie aussi que vous voyez toujours tout le monde avec un léger retard par rapport à leur position réelle sur le serveur.

Compensation de lag. Quand vous tirez, un jeu à autorité serveur rembobine son propre état de la durée de votre latence pour juger le tir par rapport à l'endroit où se trouvait la cible sur votre écran au moment où vous avez tiré, et non là où elle se trouve maintenant. Riot décrit exactement ce rembobinage dans son article sur le netcode. Sans cela, les joueurs à haut ping ne pourraient jamais toucher une cible en mouvement. Avec, ils obtiennent une chance équitable.

Rollback. Les jeux de combat, qui ne tolèrent aucun délai d'entrée, utilisent le netcode rollback. Le client suppose les prochaines entrées de l'adversaire, simule en avant sans aucun délai, et si l'hypothèse était fausse, il rembobine l'état du jeu jusqu'au point de divergence, le resimule, puis avance rapidement jusqu'au présent. Cette technique a été popularisée par le SDK GGPO et constitue désormais la norme attendue pour les jeux de combat compétitifs. Bien réalisé, le jeu en ligne donne l'impression d'un jeu en local, jusqu'à ce que la connexion se dégrade assez pour que les corrections deviennent visibles.

L'illusion se brise à des endroits prévisibles, et chaque joueur les a déjà ressentis :

• Avantage de l'attaquant qui passe l'angle (peeker's advantage). Le joueur qui contourne un angle voit le défenseur immobile avant que celui-ci ne le voie, parce que l'interpolation et l'aller-retour font que le client du défenseur affiche le passé. Combiné à la compensation de lag, l'attaquant remporte souvent l'échange. Riot cite précisément cette raison pour justifier son choix de serveurs à 128 ticks.
• Le litige du « j'ai tiré le premier ». Vous vous mettez à l'abri, puis mourez un instant plus tard. Sur votre écran, vous étiez en sécurité ; sur l'écran du tireur, rembobiné par la compensation de lag, vous étiez encore exposé au moment où il a tiré. Le serveur a respecté ce qu'il voyait. Personne n'a triché.
• Rubber-banding et téléportations. Quand la prédiction est fausse ou que des mises à jour se perdent, la correction fait sauter votre personnage, ou un autre joueur, à l'endroit où le serveur affirme qu'il devrait être. Cette secousse en arrière, c'est l'illusion qui échoue en temps réel, et elle est presque toujours causée par du packet loss ou une connexion instable plutôt que par le ping brut.

Combien de latence chaque genre peut masquer

Le netcode achète des marges différentes selon les genres, donc il n'existe pas de chiffre unique pour une latence « acceptable ». Le cadre le plus cité est le modèle de Claypool et Claypool datant de 2006, publié dans Communications of the ACM, qui relie la tolérance à la latence d'un jeu à la perspective du joueur et à la précision et l'urgence temporelle de ses actions.

Leur constat, en chiffres ronds : les jeux à la première personne comme les FPS et les jeux de course, où vous contrôlez directement un avatar et agissez dans des délais serrés, commencent à se dégrader autour de 100 ms. Les jeux à la troisième personne avec avatar, comme de nombreux jeux de rôle, restent jouables jusqu'à environ 500 ms car les actions sont moins urgentes. Les jeux omniprésents, où vous commandez des unités depuis une vue aérienne comme dans la stratégie en temps réel, tolèrent le plus ; des travaux ultérieurs sur ce genre situent une limite supérieure utilisable près de 1,000 ms, puisque donner un ordre n'est pas un réflexe.

La lecture pratique de cette recherche, plutôt que les seuils exacts :

• Les jeux de tir et de combat compétitifs sont les moins indulgents. Les joueurs remarquent des dizaines de millisecondes, et la régularité compte autant que la moyenne. C'est le genre où l'emplacement du serveur est quasi non négociable.
• Les MOBA et les RPG d'action se situent entre les deux. Ils masquent davantage de délai grâce à la prédiction et à des entrées moins urgentes, mais le jeu compétitif récompense quand même une latence basse et stable.
• Les MMO et les jeux de stratégie tolèrent le plus. Les jeux au tour par tour et les jeux en temps réel plus lents peuvent répartir les joueurs sur tout un continent tout en restant agréables à jouer.

Prenez ces indications comme des tendances. Les chiffres varient selon le jeu précis, le niveau du joueur et la qualité du netcode. La règle de conception prudente consiste à dimensionner l'emplacement et le matériel du serveur pour l'action la plus sensible à la latence que vos joueurs y effectueront.

Pourquoi le jitter et le packet loss nuisent plus qu'un ping élevé mais stable

La latence, ce n'est pas seulement son niveau, c'est aussi sa régularité. Une connexion qui tient un 80 ms constant se ressent généralement mieux qu'une connexion qui moyenne 50 ms mais varie fortement, et la raison tient au netcode décrit plus haut.

L'interpolation et la prédiction supposent toutes deux un délai à peu près constant. Donnez-leur un ping stable et elles trouvent leur rythme ; la taille du buffer et la cadence des corrections se stabilisent, et le timing du joueur s'y adapte. Le jitter casse cela. Quand l'aller-retour oscille entre 40 ms et 120 ms, le client ne peut pas choisir un buffer à la fois petit et sûr : soit il agrandit le buffer, ajoutant du délai pour tout le monde, soit il le garde serré et subit des instantanés qui arrivent en retard, ce qui se traduit par des saccades.

Le packet loss est encore pire. Une mise à jour perdue n'est pas une image en retard, c'est une image manquante. Le client conserve alors le dernier état connu, ce qui fige un autre joueur en pleine foulée, ou bien extrapole au-delà puis se recale brutalement quand la vérité arrive. Ce recalage brutal, c'est le rubber-banding. Un packet loss constant de 1 à 2 % suffit à rendre un jeu cassé, même avec un ping qui serait autrement excellent.

La leçon de conception pour un hébergeur est qu'un chemin bien peeré au timing stable bat un chemin légèrement plus court qui se congestionne. Une route qui sature occasionnellement un lien et perd des paquets se ressentira plus mal qu'une route un peu plus longue mais qui ne le fait jamais.

La géographie et le routage décident de l'essentiel

Parmi tout ce qu'un hébergeur influence, la distance physique est le facteur le plus important et le moins négociable. La lumière dans une fibre optique voyage à environ deux tiers de sa vitesse dans le vide, soit environ 200 km par milliseconde, ce qui donne la règle empirique utile d'environ 1 ms de délai aller-retour pour 100 km de câble, avant tout surcoût de routage. D'Amsterdam à Francfort, cela représente quelques millisecondes sur le câble ; d'Amsterdam à Sydney, cela ne peut pas descendre sous environ 150 ms dans un sens, quel que soit le prix payé, parce que la planète a cette taille.

Le routage détermine à quel point vous vous rapprochez réellement de ce plancher physique. Deux serveurs situés à la même distance peuvent différer de dizaines de millisecondes selon la façon dont leur trafic est acheminé. Un réseau bien peeré transmet le trafic à d'autres réseaux directement à un point d'échange internet dans la même région, ce qui garde le chemin court. Un réseau mal connecté s'appuie sur du transit qui peut faire passer vos paquets par une ville lointaine avant de rebrousser chemin, ajoutant de la latence et des sauts où les paquets peuvent être perdus ou retardés. C'est pourquoi notre page réseau publie notre peering : le chemin fait partie du produit.

La conclusion pour un hébergeur est sans détour. L'emplacement du serveur domine tous les autres leviers de latence que vous contrôlez, car il fixe le plancher dans lequel le tick rate et le netcode doivent ensuite composer. Une base de joueurs européenne doit être servie depuis un emplacement européen bien connecté, et non routée à travers un océan vers l'endroit où la capacité était la moins chère. C'est pourquoi notre emplacement d'Amsterdam existe comme un choix à part entière : pour les joueurs en Europe, héberger là-bas retire plus de latence ressentie que n'importe quel réglage effectué sur la machine elle-même.

La latence que vous contrôlez en tant qu'hébergeur

La distance et le routage fixent le plancher. Les étapes côté serveur de l'aller-retour sont l'endroit où un hébergeur préserve ce plancher ou le détruit, et c'est la partie que vous exploitez réellement.

Le plus grand risque côté serveur est un tick qui dépasse son budget. Un serveur à 20 ticks dispose de 50 ms pour terminer chaque tick ; un serveur à 64 ticks dispose d'environ 15 ms. Si la simulation ne peut pas se terminer dans ce laps de temps, les ticks glissent, le taux effectif chute, et chaque joueur connecté ressent un délai supplémentaire au même instant. C'est généralement ce que signifie « le serveur lague », par opposition au ping d'un joueur en particulier. C'est un problème de CPU, et les simulations de jeu reposent sur la performance mono-thread, ce qui explique pourquoi des cœurs rapides valent mieux que de nombreux cœurs lents pour cette charge de travail. Nous détaillons cet arbitrage dans l'article sur les performances bare metal face à la VM.

L'hébergement mutualisé en surréservation est la façon la plus courante dont cela tourne mal. Quand un fournisseur entasse trop d'instances sur une seule machine physique, votre processus de jeu se retrouve à concurrencer pour du temps CPU qu'il pensait posséder. Sur des hôtes virtualisés, cela se manifeste par du CPU steal : des cycles que l'hyperviseur donne à un voisin au lieu de vous les laisser. Le steal time se transforme en ticks qui glissent, et les ticks qui glissent se transforment en latence ressentie pour chaque joueur de votre serveur, sans que le réseau n'y soit pour rien. Une machine dédiée élimine entièrement le voisin, ce qui constitue le principal argument de latence en faveur de l'hébergement de serveurs de jeu en bare metal.

Les attaques sont aussi une source de latence, pas seulement de temps d'arrêt. Une attaque DDoS volumétrique qui sature la liaison montante fait grimper la latence et le packet loss pour les joueurs légitimes bien avant de mettre le serveur totalement hors ligne ; le jeu donne l'impression de se noyer dans le jitter. Une mitigation qui nettoie le flot en amont garde le chemin propre, ce qui est un bénéfice de latence autant que de disponibilité.

Le reste relève d'une discipline d'hébergement ordinaire : donner au processus de jeu les cœurs dont il a besoin, garder la boucle de tick dans son budget, et ne pas laisser une tâche de fond ou un colocataire bruyant voler des cycles pendant les heures de pointe.

Bien mesurer la latence

Si vous diagnostiquez un problème de latence, un simple chiffre de ping est l'outil le moins utile, car il réduit tout le trajet à un seul chiffre et masque où se situe réellement le délai.

ping vous donne l'aller-retour vers le serveur et, exécuté un moment, une idée du jitter et du packet loss. Il répond à « à quelle distance, et avec quelle stabilité », et rien sur le chemin emprunté.

ping -c 50 203.0.113.10

mtr combine traceroute et ping : il envoie des pings en continu vers chaque saut du trajet et affiche le packet loss et la latence par saut. C'est ce qui indique où se situe le problème. Si la latence et le packet loss apparaissent au saut 3 et restent élevés jusqu'au serveur, le problème est précoce, proche du joueur. Si tout est propre jusqu'au dernier saut, regardez du côté du serveur. Si un saut intermédiaire affiche de la perte mais que les sauts suivants sont propres, ce saut se contente probablement de limiter le débit de ses propres réponses ICMP, et peut être ignoré.

                             Packets               Pings
 Host                       Loss%   Snt   Avg  Best  Wrst
 1. 203.0.113.1              0.0%    50   0.5   0.3   1.2
 2. 198.51.100.9             0.0%    50   3.4   2.9   9.8
 3. 198.51.100.40            0.0%    50  11.5  10.9  24.6
 4. 192.0.2.50               0.0%    50  18.9  18.3  31.4

Le net graph intégré au jeu est la mesure qui correspond le mieux à ce que ressent le joueur, car il inclut l'alignement sur le tick et le traitement serveur que le ping ne peut pas voir. La plupart des titres compétitifs en exposent un : il affiche la latence client-serveur, le délai d'interpolation, le packet loss, et souvent la performance de tick du serveur lui-même. Quand le ping d'un joueur semble correct mais que le jeu se ressent mal, le net graph révèle généralement le vrai coupable : un buffer d'interpolation étiré ou un serveur dont le tick rate a chuté.

Les chiffres ci-dessus sont donnés à titre illustratif et utilisent des plages d'adresses IP réservées à la documentation. Vos propres valeurs varieront selon l'emplacement, la route et l'heure de la journée ; exécutez les commandes contre votre serveur réel et interprétez la forme du résultat, pas ces chiffres précis.

Déployer sur Serverside

La latence se décide surtout avant même que le premier joueur ne se connecte, selon l'emplacement du serveur et le routage de son réseau. Un serveur de jeu Serverside tourne en bare metal sur notre propre réseau (AS55285), si bien que votre boucle de tick dispose d'une machine entière, sans voisin bruyant qui vole des cycles, et le chemin vers vos joueurs emprunte un routage que nous peerons et publions, plutôt que le transit le moins cher disponible. Une mitigation DDoS permanente se trouve devant l'interface publique, ce qui empêche une attaque de se transformer en jitter pour les joueurs réellement présents. Le provisionnement prend moins d'une minute, vous pouvez donc placer une machine au bon endroit et tester la route avant de vous engager.

Pour une base de joueurs européenne, notre emplacement d'Amsterdam est celui qui retire le plus de latence ressentie, bien peeré vers les points d'échange de la région pour que le temps sur le câble vers les joueurs européens reste proche de son plancher physique. Si vous voulez d'abord voir l'ensemble des emplacements disponibles, commencez par le configurateur de serveurs dédiés et choisissez le site le plus proche des joueurs auxquels vous vous adressez.

Questions fréquentes

Quelle est la différence entre le ping et la latence dans un jeu ?

Le ping est une mesure de la latence : le temps d'aller-retour d'un petit paquet jusqu'au serveur et retour, généralement en ICMP. La latence telle que la ressent un joueur est plus large. Elle inclut le ping, plus le temps d'attente avant l'échantillonnage de votre entrée, le temps que le serveur attend son prochain tick de simulation avant d'agir sur votre paquet, le traitement effectué par ce tick, et le trajet retour. Deux joueurs avec le même ping de 30 ms peuvent ressentir des délais différents si l'un est sur un serveur à 20 ticks et l'autre sur un serveur à 128 ticks, car l'attente du tick fait partie de la latence ressentie et le ping ne la mesure pas.

Un tick rate plus élevé réduit-il la latence ?

Il réduit une composante spécifique de la latence. Un tick rate plus élevé raccourcit l'attente moyenne entre l'échantillonnage du monde par le serveur et l'action sur votre entrée, car les ticks se produisent plus souvent. Un serveur à 20 ticks se met à jour toutes les 50 ms, donc une entrée peut attendre jusqu'à 50 ms avant d'être traitée ; un serveur à 128 ticks se met à jour toutes les 7.8 ms, donc cette attente est bien plus courte. Ce qu'un tick rate plus élevé ne change pas, c'est l'aller-retour réseau. Si le serveur est à 5,000 km, aucun tick rate ne corrige les quelque 50 ms que le paquet passe sur le câble dans chaque sens. Le tick rate et la distance réseau sont deux horloges distinctes, et il faut garder les deux courtes.

Pourquoi est-ce que je perds des combats que je pensais avoir gagnés, même avec un ping bas ?

Généralement la compensation de lag combinée à l'avantage de l'attaquant qui passe l'angle. Les jeux de tir à autorité serveur rembobinent l'état du jeu de la durée de votre latence pour juger un tir, si bien que le joueur en mouvement qui passe un angle est souvent considéré comme ayant tiré le premier, parce que sur son écran il vous a vu avant que votre écran ne le voie. Le serveur respecte ce que chaque client a vu au moment où il a agi. C'est pourquoi celui qui contourne un angle a tendance à remporter l'échange, et pourquoi le défenseur a l'impression d'avoir été tué après s'être remis à l'abri. C'est un arbitrage de conception, pas un bug, et une latence plus basse et plus stable des deux côtés réduit cet écart.

Le jitter ou le packet loss sont-ils pires qu'un ping élevé ?

Pour la plupart des jeux, oui. Un 80 ms stable est prévisible, et le netcode comme le timing du joueur lui-même s'y adaptent. Le jitter, quand l'aller-retour oscille par exemple entre 40 ms et 120 ms, déjoue cette adaptation car le buffer d'interpolation et la prédiction du client ne parviennent pas à se stabiliser sur un délai constant. Le packet loss est pire encore : une mise à jour perdue signifie que le client fige le dernier état connu ou extrapole puis corrige, ce qui correspond au rubber-banding et aux téléportations. Une connexion qui affiche un ping moyen plus élevé mais reste stable se ressent généralement mieux qu'une connexion à moyenne plus basse qui subit des pics et perd des paquets.

À quelle distance un serveur de jeu doit-il se trouver de mes joueurs ?

Assez proche pour que le délai de propagation reste dans la tolérance de votre genre de jeu. La lumière dans la fibre voyage à environ 200 km par milliseconde, donc une règle empirique donne environ 1 ms de délai aller-retour pour 100 km de câble, avant tout surcoût de routage. Un jeu de tir compétitif veut des joueurs à quelques centaines de kilomètres pour un temps sur le câble à un chiffre en millisecondes ; un jeu de stratégie ou un MMO peut s'étendre bien plus largement. Pour une base de joueurs européenne, cela signifie héberger dans un emplacement européen bien peeré plutôt que de tout router à travers un océan, ce qui constitue la décision de latence la plus importante que prend un hébergeur.