Understanding Minecraft Server TPS: Why Your World Lags and How to Fix It

Minecraft server TPS measures how many game ticks complete every second, and the target value is 20. When a single tick takes longer than 50 milliseconds to process, the server falls behind, and players feel it as rubber-banding, delayed block breaks, or mobs that freeze mid-attack. This guide breaks down what actually slows a tick, how to read a timings or spark report, and which world and plugin settings bring the number back to 20.

Minecraft server TPS: what the number actually tracks

The Minecraft server TPS value counts how many times the main game loop finishes in one second. Redstone, block updates, entity movement, and player actions are all processed inside that loop, tick after tick. The engine targets 20 ticks per second, which gives each tick a 50 millisecond budget before it starts eating into the next one.

When a tick takes 80 milliseconds instead of 50, the server does not skip ticks, it queues them. TPS then reads as 20 divided by the real tick duration, so a 100 millisecond average tick shows up as roughly 10 on the /tps command. This is why a heavy single tick spikes MSPT (milliseconds per tick) before TPS visibly drops.

TPS reading	What it means in practice
20	Full tick budget, no lag felt by players
15 to 19	Minor tick lag, usually recoverable with tuning
10 to 14	Visible lag, mob AI and redstone slow down
Below 10	Heavy lag, the watchdog thread may kill the process

Vanilla and most fork software run the whole simulation on one main thread, even on a multi-core CPU. A faster clock speed on the host machine, such as a Ryzen 9 7950X3D, reduces per-tick time, but it cannot remove the single-thread ceiling on its own. Anyone building a new world from scratch can look at Minecraft server hosting built around this kind of CPU before layering on the settings covered below.

Common causes of tick lag on a survival or modded world

Chunk loading is the first suspect on any large world. A high view-distance forces the server to keep more chunks active, and every active chunk runs block ticks, fluid updates, and entity AI. Players spread far apart multiply this cost instead of sharing it.

Entity count is the second suspect. Automatic mob farms, item duplication glitches, dropped item piles, and unchecked villager breeding all add pathfinding and collision checks that pile up on the main thread. A single overloaded farm can cost more tick time than the rest of the world combined.

Redstone and hopper density

Redstone clocks that fire every tick, and hopper chains moving items between dozens of containers, both run on the main thread with no shortcut. A build that looked harmless in creative mode can quietly consume several milliseconds per tick once it runs continuously in survival.

Plugin and garbage collection pauses

Plugins that run heavy logic synchronously, such as database lookups or file writes inside an event handler, block the tick until they finish. Insufficient heap memory triggers frequent garbage collection, which pauses the whole JVM and shows up as a sudden TPS drop rather than a gradual one.

Reading a timings or spark report without guessing

Guessing which plugin or feature causes lag wastes hours. A profiler shows exactly where tick time goes, ranked by method and by plugin, instead of relying on trial and error.

/timings on
/timings paste
/timings report

The generated report breaks total tick time into categories: tile entity ticking, entity ticking, chunk generation, and plugin scheduled tasks. A category taking an unusually high percentage of total time points directly at the fix needed, whether that means fewer active hoppers or a plugin that needs disabling.

Using spark for modern Paper builds

Spark gives a live, per-thread profile and is the tool documented by Paper itself for tracking down tick lag on current versions.

/spark profiler start --timeout 60
/spark tps
/spark profiler stop

Look for methods with a high percentage of "self time" rather than total time. High self time under an entity or tile entity class usually means a specific mob type or machine is the real bottleneck, not the plugin that spawned it.

World and chunk settings that stabilize TPS

View-distance and simulation-distance are the two settings with the largest direct effect on tick time. Lowering simulation-distance keeps entity AI and redstone active only near players, while view-distance only controls how far chunks render and load.

# server.properties
view-distance=8
simulation-distance=6
max-tick-time=60000

On Paper, paper-world-defaults.yml exposes finer control over random tick speed and how far chunks stay ticking when no player is near.

# paper-world-defaults.yml
chunks:
  no-tick-view-distance: 4
entities:
  spawning:
    per-player-mob-spawns: true

Pre-generating the world

On-the-fly chunk generation causes visible stutters the first time players explore new terrain. Running a pre-generation plugin such as Chunky ahead of launch moves that cost to a maintenance window instead of live gameplay, and keeps TPS flat for new players.

Entity, mob and plugin tuning for consistent ticks

Spigot's entity activation range controls how far from a player an entity keeps running full AI logic instead of a cheaper, dormant state. Lowering it for animals and miscellaneous entities cuts wasted computation in farms and villages without affecting nearby gameplay.

# spigot.yml
entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 48
  misc: 8
tick-inactive-villagers: false

Hopper transfer speed and mob caps in the same file matter almost as much. Raising hopper transfer intervals slightly, and capping ambient or monster counts per chunk, reduces the number of block and entity ticks without noticeably changing how a farm feels to use.

Plugin housekeeping closes the loop. Removing unused plugins, checking that scheduled tasks run asynchronously where the API allows it, and restarting the process on a regular schedule all prevent slow memory growth from turning into garbage collection pauses. Console access through NexusPanel makes it easy to watch TPS live while testing each change.

Anyone running the world on a self-managed machine can cross-check available RAM and CPU load the same way through a Linux VPS, and the full catalog of supported titles is listed under All our game servers for reference.

Conclusion

A stable Minecraft server TPS comes from fixing the single-thread bottleneck, not from adding hardware first. Run a spark or timings report before changing anything, tune view-distance, entity activation range and mob caps based on what it shows, and only then judge whether more CPU headroom is actually needed.

FAQ

Does adding more RAM increase Minecraft server TPS?

More RAM mainly prevents long garbage collection pauses caused by a full heap, which stops sudden TPS drops during heavy play. It does not raise the single-thread ceiling of the tick loop itself, so a world already limited by entity count or redstone density will not gain TPS from RAM alone.

Why does /tps show 20 but the server still feels laggy?

The /tps command usually averages recent ticks, so brief spikes above 50 milliseconds can hide inside a rolling average that still rounds to 20. Checking MSPT directly, or running a short spark profile during the laggy moment, reveals spikes that a plain TPS reading smooths over.

Can too many plugins lower TPS even when nothing seems to be happening?

Yes, because many plugins register repeating scheduled tasks that run every tick or every few ticks regardless of player activity. Each idle-looking plugin still adds a small, constant cost, and a large plugin list can add up to a measurable TPS loss even on an empty world.