Réduire le lag sur son serveur Minecraft : le guide

Rien de plus frustrant qu’un serveur qui saccade quand tu construis avec tes potes ou que la mob farm crache 200 zombies. La bonne nouvelle : 90 % du lag vient de réglages qu’on peut corriger sans être admin système. Encore faut-il comprendre d’où il vient.

Dans ce tuto, on va décortiquer les causes réelles du lag, puis appliquer les optimisations qui marchent vraiment : le bon logiciel serveur, les distances de vue, la RAM, les entités, la pré-génération des chunks et les outils de diagnostic. Objectif : viser un TPS collé à 20.

1. TPS ou ping : d’où vient vraiment le lag ?
2. Paper et les bons réglages de distance
3. RAM (flags Aikar), entités et pré-génération
4. Diagnostiquer avec Spark et bien s’héberger
5. FAQ

TPS ou ping : d’où vient vraiment le lag ?

Avant de bricoler quoi que ce soit, il faut savoir de quel lag on parle. Il en existe deux totalement différents, et les confondre te fait perdre des heures à optimiser le mauvais côté.

Le TPS : la santé du serveur

Le TPS (Ticks Per Second) est le rythme cardiaque de ton serveur. Minecraft calcule le monde 20 fois par seconde : c’est le 20 TPS idéal. Chaque tick, le serveur met à jour les mobs, la redstone, les blocs, la physique. Si un tick prend plus de 50 ms à calculer, le serveur n’arrive plus à suivre et le TPS chute. En dessous de 18-19 TPS, tout le monde ressent la latence : blocs qui reviennent, mobs qui glissent, coups qui ne portent pas. C’est un problème de CPU du serveur, pas de ta connexion.

Le ping : ta connexion réseau

Le ping (latence réseau), mesuré en millisecondes, c’est le temps qu’un paquet met à faire l’aller-retour entre ton PC et le serveur. Un ping élevé te donne du rubber-banding (tu recules après avoir avancé) même si le serveur tourne à 20 TPS parfaits. Ça dépend de la distance géographique au datacenter, de ta box et du routage. Un joueur français sur un serveur hébergé aux États-Unis aura toujours 120+ ms, quoi qu’on fasse côté serveur.

Paper et les bons réglages de distance

Passe sur Paper

Si tu tournes encore sous le serveur Vanilla officiel ou sous Spigot, le premier gain est gratuit : migre vers Paper. C’est un fork optimisé de Spigot qui réécrit des pans entiers du moteur pour économiser du CPU, tout en restant 100 % compatible plugins Bukkit/Spigot. Sur une même machine, Paper encaisse facilement 2 à 3 fois plus de joueurs et d’entités que le Vanilla avant de lagger. Pour les gros serveurs, Purpur (fork de Paper) ajoute encore plus d’options de configuration. La migration est simple : tu remplaces le .jar et tu gardes ton dossier de monde.

Règle la view-distance et la simulation-distance

Deux réglages dans server.properties pèsent énormément sur le CPU :

• view-distance : le nombre de chunks envoyés au client autour de chaque joueur (le rendu visuel). Par défaut 10. Passe-la à 6-8 : le joueur voit un peu moins loin, mais le serveur charge beaucoup moins de terrain.
• simulation-distance : le rayon en chunks où le monde est réellement calculé (mobs, cultures, redstone). C’est le vrai gros consommateur. La baisser à 4-6 soulage énormément le CPU sans que les joueurs le remarquent, car les entités lointaines ne servent à rien.

RAM (flags Aikar), entités et pré-génération

Alloue la bonne RAM avec les flags Aikar

Erreur classique : balancer 16 Go de RAM à un serveur de 5 joueurs en croyant que « plus = mieux ». Faux. Trop de RAM allonge les pauses du Garbage Collector de Java, qui gèlent le serveur d’un coup. La bonne quantité pour un serveur moddé/plugins de taille moyenne, c’est 4 à 8 Go, pas plus.

Le vrai levier, ce sont les flags Aikar : un jeu d’options de démarrage JVM optimisées pour Minecraft (générables sur flags.sh). Elles configurent le Garbage Collector G1GC pour lisser les pauses au lieu de les concentrer. Un serveur avec 6 Go bien réglés via les flags Aikar tourne mieux qu’un serveur avec 12 Go mal configurés. Utilise Java 17 ou 21 selon ta version de Minecraft.

Limite les entités et les mobs

Les entités (mobs, items au sol, cadres, armor stands) sont l’une des premières sources de TPS bas. Une mob farm géante ou un stockage débordant d’items droppés peut effondrer le serveur. Dans bukkit.yml et paper-world-defaults.yml, tu peux plafonner le mob-spawn-range, les limites de spawn par type (monsters, animals) et l’entity-activation-range (distance à laquelle les entités « s’endorment »).

• ClearLagg : plugin qui supprime périodiquement les items au sol et les entités inutiles, avec un compte à rebours annoncé aux joueurs.
• Réduire l’activation-range : les mobs lointains cessent de tourner leur IA tant que personne n’approche.
• Surveiller les chunks à entités : Spark identifie la ferme fautive en un clic.

Pré-génère tes chunks

Générer du nouveau terrain à la volée est l’opération la plus lourde du serveur : c’est ce qui cause le freeze quand un joueur file en Elytra vers l’inconnu. La solution : pré-générer les chunks à l’avance avec un plugin comme Chunky. Tu définis un rayon (par exemple 5000 blocs), tu lances la génération quand personne ne joue, et ensuite l’exploration ne provoque plus aucun à-coup puisque le terrain existe déjà sur le disque.

Diagnostiquer avec Spark et bien s’héberger

Spark : le profileur de référence

Ne devine pas la cause de ton lag, mesure-la. Spark est le profileur incontournable (développé par l’équipe derrière LuckPerms). La commande /spark profiler analyse ce qui consomme le CPU pendant une durée donnée et te sort un rapport web pointant précisément le plugin, la ferme ou la fonction responsable. /spark tps et /spark health te donnent TPS, MSPT (millisecondes par tick) et usage RAM en direct. C’est l’outil qui transforme « ça lag » en « c’est ta redstone du chunk X ».

L’hébergement : le CPU monocœur rapide avant tout

Point souvent ignoré : Minecraft est quasi mono-thread. La simulation du monde tourne principalement sur un seul cœur CPU. Résultat, un processeur avec 32 cœurs lents sera moins bon qu’un CPU à 8 cœurs très rapides. Ce qui compte, c’est la fréquence par cœur et surtout le single-thread performance (score sur des benchmarks comme PassMark single-thread).

• Fuis les offres « illimité » à bas prix : elles entassent des dizaines de serveurs sur de vieux CPU lents, ton TPS en pâtira.
• Vise un CPU récent haute fréquence : Ryzen 7000/9000, Intel récent, souvent vendus comme offres « premium » ou « Ryzen ».
• Choisis un datacenter proche de tes joueurs pour le ping (un serveur en France pour une communauté française).
• Privilégie du stockage NVMe : la lecture/écriture des chunks est plus rapide, moins de micro-freezes.

En combinant Paper, des distances raisonnables, les flags Aikar, un contrôle des entités, la pré-génération et un hébergeur à CPU rapide, tu passes d’un serveur qui saccade à un serveur qui tient les 20 TPS même à plusieurs. Diagnostique d’abord avec Spark, agis ensuite : c’est la méthode qui marche.

FAQ

C’est quoi un bon TPS sur un serveur Minecraft ?

Le TPS maximal est de 20, c’est la valeur cible. Au-dessus de 18, le lag est imperceptible. En dessous de 15, tout le monde ressent des saccades sur la redstone, les combats et les mobs.

Pourquoi mon serveur lag alors que le TPS est à 20 ?

Parce que ton problème est réseau, pas serveur. Un TPS de 20 avec du rubber-banding signifie un ping élevé : hébergeur trop éloigné géographiquement, ta connexion, ou un mod côté client. Rapproche-toi d’un datacenter proche de tes joueurs.

Combien de RAM allouer à mon serveur Minecraft ?

Pour un serveur avec plugins de taille moyenne, 4 à 8 Go suffisent largement. Au-delà, tu risques d’allonger les pauses du Garbage Collector. Ce qui compte le plus, ce sont les flags Aikar bien configurés, pas la quantité brute.

Paper est-il vraiment mieux que Spigot ou Vanilla ?

Oui, très nettement. Paper optimise le moteur en profondeur et gère bien plus d’entités et de joueurs sur le même matériel, tout en restant compatible avec les plugins Spigot. C’est la première optimisation à faire, et elle est gratuite.

Comment savoir quel plugin fait lagger mon serveur ?

Installe Spark et lance la commande /spark profiler. Il analyse la consommation CPU et te génère un rapport web qui pointe précisément le plugin, la ferme à mobs ou le chunk responsable du lag.