Comprendre et stabiliser le TPS d'un serveur Minecraft

Minecraft server TPS is the single number that tells you whether your world is running smoothly or grinding through lag: 20 TPS means every tick completes in the expected 50 milliseconds, while anything lower means players are watching mobs teleport, crops freeze and redstone stutter. Understanding what drags your ticks down is the first step toward fixing it.

Understanding Minecraft Server TPS and the Tick Loop

A Minecraft world runs on a tick loop. Every tick, the game updates entities, processes block changes, handles redstone, runs scheduled tasks and flushes network packets to every connected player. Vanilla and Paper both target 20 ticks per second, which gives each tick a 50ms budget. When a tick takes longer than that, the server doesn't crash — it simply falls behind, and Minecraft server TPS drops below 20 to compensate.

The related metric you'll see in console output and monitoring tools is MSPT (milliseconds per tick). If your average MSPT sits comfortably under 50ms, your TPS will read a clean 20.0. Once MSPT creeps past 50ms, TPS starts dropping proportionally: 60ms average MSPT translates to roughly 16-17 TPS, and sustained spikes above 100ms will feel like visible rubber-banding for every player on the map.

TPS drops generally come from one of three sources: entity processing (mobs, item drops, villagers), chunk activity (loading, generation, lighting) or plugin/mod overhead (scheduled tasks, event listeners, database calls). Before changing any setting, you need to know which one is actually responsible — guessing wastes time and often makes things worse by disabling features players actually want.

If you're setting up a fresh world and want a clean baseline before troubleshooting, a properly sized Minecraft server hosting environment with modern CPU cores makes the diagnostic process far easier, since you can isolate configuration issues from raw hardware limits.

Reading Timings Reports and Spark Profiles to Find the Bottleneck

Guesswork is the enemy of good tick performance. Paper and Spigot builds support the /timings command, and most modern networks now rely on the spark profiler, which works on vanilla, Spigot, Paper, Forge and Fabric alike.

Generating a timings report

/timings on
/timings paste

Let the server run for at least 10-15 minutes under normal player load before pasting. The generated report breaks down tick time by plugin, by event handler and by world, so you can see exactly which component eats the most milliseconds per tick.

Running a spark profile

/spark profiler --timeout 300
/spark profiler --stop

Spark gives a more granular sampling profile than timings, including native/JVM method calls, which matters when the slowdown comes from garbage collection pauses rather than plugin logic. You can also run a one-shot health check:

/spark tps
/spark health

What to look for in the report

• High "entity ticking" percentage — usually mob farms, item stacking or villager pathfinding.
• High "chunk loading / generation" time — players spreading out faster than the server can generate or load terrain.
• A single plugin dominating the tick — scoreboard updates, economy plugins doing synchronous database writes, or anti-cheat scanning every packet.
• GC pauses in spark's JVM flame graph — points to memory allocation settings rather than world configuration.

Only once you've identified the dominant cause should you touch configuration files — tuning blind almost always under-fixes the real problem while removing gameplay features for nothing.

World, Entity and Chunk Settings That Restore Stable 20 TPS

Once you know the bottleneck, most fixes live in server.properties, paper-world-defaults.yml and spigot.yml. Here are the levers that move the needle most reliably.

View distance and simulation distance

These two settings are the biggest single factor in chunk-related lag. Simulation distance controls how far entities and redstone are actively processed, while view distance only affects what's sent to the client.

# server.properties
view-distance=8
simulation-distance=6

Dropping simulation distance by even 2 chunks on a populated map can recover several TPS instantly, since fewer chunks run full entity and block ticking.

Entity and mob caps

Uncontrolled mob farms are the most common cause of entity-driven lag. Paper exposes per-category caps in paper-world-defaults.yml:

entities:
  spawning:
    despawn-ranges:
      soft: 32
      hard: 128
  entity-based:
    max-entity-collisions: 8

Also check spigot.yml for global mob limits:

spawn-limits:
  monsters: 50
  animals: 10
  water-animals: 5
  ambient: 5

Lowering these caps on survival worlds with active farms often resolves recurring TPS dips without players noticing any gameplay difference.

Redstone and hopper optimization

Hoppers transferring items every tick across dozens of item-sorting systems are a classic silent killer. Paper lets you throttle hopper transfer speed:

hopper:
  cooldown-when-full: true
  disable-move-event: false

Large redstone clocks also tick constantly even with no player nearby unless simulation distance or chunk unloading handles it — keep an eye on builds using always-on observer loops, since they run every tick regardless of player activity.

Chunk pre-generation

New terrain generation under real-time player pressure is expensive. Pre-generating chunks ahead of exploration (using a plugin like Chunky) shifts that cost to a quiet maintenance window instead of peak hours:

/chunky radius 5000
/chunky start

Run pre-generation overnight or during low-population hours so the CPU spike doesn't compete with live gameplay ticks.

Hardware and Ongoing Maintenance for Consistent Minecraft Server TPS

Configuration tuning has a ceiling. Minecraft's tick loop is single-threaded for world logic, so raw clock speed and per-core performance matter more than core count. Processors with high single-thread frequency, paired with NVMe storage for fast chunk I/O, reduce the baseline MSPT before you even touch a config file — which is exactly why CPU generation and storage type should be part of any serious troubleshooting checklist, not just plugin settings.

A few maintenance habits keep TPS stable over the long run rather than just after a one-time fix:

• Restart on a schedule (daily or every few days) to clear accumulated entity/chunk memory bloat rather than waiting for a crash.
• Keep automatic backups running outside of peak hours, since disk-heavy backup jobs can themselves cause momentary tick spikes.
• Update Paper/Spigot builds regularly — many TPS regressions are fixed upstream before server owners even notice the pattern.
• Audit plugins after every major update; an outdated plugin polling asynchronously can silently become a synchronous bottleneck after a core API change.
• Use a management panel with live console and resource graphs so tick drops are visible in real time instead of discovered from player complaints.

If you manage several worlds or a modded network, a Pterodactyl VPS environment makes it easier to isolate each world's resource usage and restart individual instances without affecting the rest of your setup. For a broader look at performance tuning across other titles, the All our game servers overview and the Fly-Serv blog cover similar diagnostic approaches for other engines.

Stable Minecraft server TPS comes from matching world settings to actual player behavior, not from disabling features at random. Profile first with timings or spark, fix the confirmed bottleneck, then revisit hardware if the ceiling remains. Consistent 20 TPS is achievable on almost any well-configured, well-maintained world.

FAQ

Why does TPS drop only when many players are online?

More players mean more loaded chunks, more entities and more simultaneous events to process per tick. Lower simulation distance and tighter mob caps usually absorb the extra load without removing gameplay content.

Is 19 TPS actually a problem?

A brief dip to 19 TPS is normal during chunk generation or large redstone activity. Persistent readings below 18-19 TPS, or frequent spikes in MSPT above 60ms, indicate a bottleneck worth profiling with timings or spark.

Do mods cause more tick lag than plugins?

Not inherently — both run code during the tick loop. Poorly optimized mods or plugins with synchronous disk/database calls are usually the real cause, which is why profiling the specific component matters more than blaming mods versus plugins as a category.