Why your Minecraft server lags, and how to actually fix it

Your server feels sluggish. Blocks break and reappear, mobs slide around, and someone in chat is yelling that the whole thing is broken. Before you blame the host or buy more RAM, it helps to know what kind of lag you're actually dealing with, because three very different problems all get called "lag" and they have completely different fixes.

TPS, FPS and ping are not the same thing

This is the part most people skip, and it's why so many "fixes" do nothing. There are three separate numbers, and only one of them lives on the server.

TPS is ticks per second. The server tries to run 20 ticks every second, and each tick is one step of the world: mobs move, crops grow, redstone fires, hoppers move items. A healthy server sits at 20 TPS. If it drops to 15 or 10, time on the server slows down for everyone. That's true server lag, and it's the only one of the three you can fix from the server side.

FPS is frames per second, and it happens on the player's computer. If someone has a weak laptop, high render distance, and 40 shaders running, their game will stutter even when your server is at a perfect 20 TPS. You can't fix their FPS from the panel. No amount of RAM on the server helps a player whose GPU is the bottleneck.

Ping is the round trip time between the player and the server, measured in milliseconds. High ping shows up as rubber banding: you walk forward, then snap back. That's usually distance or a bad connection, not the server being overloaded. A player in Australia connecting to a server in Germany will have high ping no matter how good the hardware is.

So before you change anything, figure out which one is broken. If only one player lags, it's almost always their FPS or their ping. If everyone lags at the same time, it's TPS, and that's the rest of this article.

What actually drops your TPS

Server lag is the server failing to finish all its work inside the 50 milliseconds it has per tick. When a tick runs long, the next one starts late, and TPS falls. Here are the usual culprits, roughly in the order we see them cause trouble.

View distance and simulation distance set too high

These two settings in server.properties do more damage than anything else, and the defaults on a lot of setups are higher than they should be. View distance controls how many chunks the server sends to each player. Simulation distance controls how far out the world is actually ticking: mobs, crops, redstone, all of it.

The catch is that simulation distance scales badly. Going from 6 to 10 doesn't add a little load, it adds a lot, because the area being ticked grows with the square of the radius. A server that runs fine with 5 players at distance 6 can choke at distance 12.

Sensible starting values for most community servers:

view-distance=8
simulation-distance=6

If you're tight on resources or running a big player count, drop simulation distance to 4 or even 3. Honestly, most players never notice the difference between sim distance 4 and 10, because mob farms and redstone near them still work fine. View distance you can keep a touch higher since it's cheaper than simulation.

Too many mobs, hoppers and entities

Entities are expensive. Every mob, item frame, armor stand, and dropped item is something the server has to think about every tick. A few common things pile up fast:

• Giant mob farms that keep hundreds of entities loaded.
• Big animal pens where players bred 200 cows and forgot about them.
• Item elevators and sorting systems built from long hopper chains.
• Dropped items that never despawn because they're sitting in a chunk that's always loaded.

Hoppers are a quiet killer. Each one checks for items above it constantly. A sorting system with 60 hoppers is 60 little checks every tick, forever. Paper lets you tune this in paper-world-defaults.yml (older builds used paper.yml). Look for the hopper and entity sections. You can cap how many entities spawn per chunk and slow down hopper checks slightly without players noticing.

For mob limits, the spigot.yml file controls spawn caps. Lowering the monster and animal caps a bit can give you back a surprising amount of headroom on a busy world.

Heavy or badly written plugins

One bad plugin can wreck an otherwise healthy server. Things that scan the whole world, log everything to disk, or run a task every single tick are the usual offenders. Some chunk pregenerators, dynamic map renderers, and overly aggressive anti cheat plugins are common examples.

A quick warning: more plugins is not better. Every plugin you add is more work per tick and more memory used. We've seen people install 80 plugins on a 2 GB server and then wonder why it crawls. If you're not actively using a plugin, remove it.

Not enough RAM, or the wrong amount

Low RAM causes a specific, ugly kind of lag: the server runs fine for a while, then freezes for half a second, then runs fine again. That's garbage collection. The Java machine pauses everything to clean up memory, and if it's starved for RAM it does this constantly.

Rough guide for how much to give a vanilla style Paper server:

But here's the thing people get wrong: throwing huge amounts of RAM at a server can make pauses worse, not better, because the cleanup job gets bigger. More RAM is not a TPS fix. It only helps if you were genuinely running out. If your TPS is low but memory use is comfortable, RAM is not your problem.

The single thread CPU wall

This is the one nobody warns new owners about. The core of Minecraft's world ticking runs on a single thread. That means the speed of one CPU core matters far more than how many cores you have. A 16 core server with weak single core speed will tick worse than a 4 core server with a fast modern chip.

So if your TPS is low and you've already trimmed view distance, entities, and plugins, the bottleneck might just be raw single core performance. This is why "more cores" rarely helps a single Minecraft world, and why the clock speed and generation of the host's CPU matter so much. When you're picking a host, this is worth asking about directly.

Measure first, then change one thing at a time

Guessing is how people waste a weekend. Use the tools instead.

/tps and /mspt

On Paper, type /tps in game or the console. You'll get three numbers for the last 1, 5, and 15 minutes. 20 is perfect. Anything above 19 is basically fine. Below 18 and players start to feel it.

Even better is /mspt, which shows milliseconds per tick. You have 50 ms per tick to work with. If the average is sitting at 45 ms, you're on the edge and any spike will drop your TPS. If it's at 20 ms, you have plenty of room.

spark, the tool worth installing

If you only add one diagnostic plugin, make it spark. It's the modern replacement for the old timings system and it's genuinely good. Run a profile like this:

/spark profiler --timeout 120

Let it run while the server is laggy, and it'll hand you a web link showing exactly which plugin, or which part of the game, is eating your tick time. It will literally name the method that's slow. This turns "the server is laggy" into "this one plugin's scheduled task is using 30 percent of the tick," which you can act on.

spark also has /spark health for a quick TPS and memory snapshot, and /spark tps if you want a cleaner read than the built in command. Older guides mention timings, and on Spigot you can still run /timings report, but Paper has moved to spark and it's the better tool now.

A practical config to start from

Here's a reasonable baseline for server.properties on a small to mid sized survival server. Adjust from here based on what spark tells you, not based on vibes.

view-distance=8
simulation-distance=6
max-players=20
network-compression-threshold=256
entity-broadcast-range-percentage=100

In Paper's world config, the changes worth making early are capping spawns and easing off hopper checks. The exact keys move around between versions, so search the file rather than copying blindly, but the idea is: lower the entity spawn limits per chunk, and consider raising the hopper transfer cooldown a tick or two if you have a lot of redstone. Change one value, restart, check /mspt for ten minutes, then decide. If you change five things at once you'll never know which one helped.

When the real fix is better hardware

Sometimes the honest answer is that the box is too weak. You can optimize a lot, but there's a floor. If you've done all of this and you're still dropping ticks, the signs that point to hardware are:

• spark shows the time spread across the whole game evenly, not concentrated in one plugin.
• /mspt stays high even with view and simulation distance turned way down.
• Memory use is fine, so it's not a RAM problem.
• The lag gets worse with more players in a way that trimming settings doesn't fix.

At that point you want a host with strong single core CPU performance and NVMe storage, because chunk loading hits the disk hard and a slow disk causes its own stutter when players explore new areas. This is the kind of thing we built the Bytte.cloud plans around, fast cores and NVMe rather than cramming as many servers as possible onto cheap hardware. But the advice holds wherever you host: for Minecraft, single core speed and disk speed matter more than a big core count.

Where to start tomorrow

If you do nothing else, do this. Install spark and run /tps and /mspt so you actually know your numbers. Drop simulation distance to 6 and view distance to 8. Walk your world and clear out the obvious entity hoarders, the forgotten animal pens and the hopper monsters. Then profile with spark while it's busy and let it tell you what's actually slow. Most lag problems we see come down to two or three settings and one badly behaved plugin, and you can fix all of that in an afternoon without spending a cent.