Before you can fix Minecraft server lag, you need to know which lag you actually have. Two totally different problems both get called "lag" and they share nothing. One is your server struggling to finish its work on time. The other is the network path between you and the box. Chase the wrong one and you'll burn an afternoon. I've watched someone throw more RAM at a server three times before realizing the problem was a single player on hotel wifi.
So let's split them apart, find the real culprit, and go through the fixes in the order that actually moves the needle. Most of these are free config edits you can do in about five minutes.
TPS vs ping: know which one is broken
TPS means ticks per second. A healthy server runs at exactly 20 TPS, which is one tick every 50 milliseconds. When the server can't finish all its work inside that 50ms window, the tick runs long, TPS drops, and the whole world slows down. Mobs shuffle in slow motion. Redstone drags. Furnaces smelt at half speed. That's server lag, and it hits everyone at once.
Ping is a different animal. It's just how long a packet takes to travel between your PC and the server. Bad ping gives you rubber-banding, blocks that pop back after you mine them, hits that never register. Your server can be humming along at a flat 20 TPS while one player on a saturated connection swears the whole thing is broken.
Type /tps in the console or in-game. Paper and most forks report three numbers, the 1, 5, and 15 minute averages. Sitting near 20.0? Your server's fine and you've got a network problem: check that player's connection, the route to your host, or whether you're running off a home line that's already maxed on uploads. Dropping to 15, 12, or lower? Now there's real work to do, so keep reading.
Diagnose first with spark, never guess
Resist the urge to start yanking plugins at random. Profile the server and let it tell you exactly where the milliseconds are going. The tool I reach for every single time is spark. Paper's built-in timings will do in a pinch, but spark gives you a proper sampling profiler and a report that's actually readable.
Drop in the spark plugin (there's a spark-standalone build for Fabric and Forge), then work through this:
- Profile while the lag is happening, not before. An idle server tells you nothing, so either reproduce the lag or wait until it kicks in.
- Run /spark profiler to start a sampling session, let it collect for 60 to 90 seconds under real load, then stop it.
- Open the link it hands you and read the flame graph from the widest bars down. The widest bar is where your CPU time is going, full stop.
- For a fast snapshot, /spark tps and /spark healthreport are gold. The health report flags GC pauses and your average MSPT (milliseconds per tick) in one shot.
MSPT is the number I watch above all others. An average tick at 35 or 40ms means you've got headroom. Spikes to 55 or 70ms are exactly where your TPS losses come from. Spark usually points a finger straight at the offender: one plugin, entity ticking, a chunk load. Trust the profiler over your gut, every time.
The usual culprits, ranked by how often they cause it
View distance and simulation distance
Here's the number one fix, and hardly anyone sets it right. In server.properties, view-distance controls how many chunks the server sends to clients, while simulation-distance controls how far out entities and redstone actually tick. Simulation distance is the expensive one. Plenty of people run both at 10 purely out of habit. Drop simulation-distance to 6 and view-distance to 8. On a busy server that single change can hand you back several TPS, because you're ticking far fewer chunks full of mobs and machines. Nobody notices 8 chunks of view. Everybody notices the smoothness.
Hoppers and redstone
Hoppers are quietly vicious. Every hopper polls for items to pull, constantly, whether it moves anything or not. A big storage room or an item sorter with a few hundred hoppers eats ticks alive. In paper-world-defaults.yml, raise ticks-per.hopper-check from 1 to 4 and you've cut that polling to a quarter. Redstone clocks nobody turned off, observer loops, huge flying machines: spark will name the chunk, and the fix is usually a polite word with the player who built the lag.
Entity cramming and mob farms
Thousands of mobs crushed into a farm is a classic ticker. Set max-entity-cramming to something like 24 in the gamerules so overcrowded mobs take damage and thin themselves out. In spigot.yml, the per-type spawn limits do a lot of heavy lifting. Pulling the monster limit down from 70 to around 50 trims how many mobs the server has to tick every cycle, and honestly your players won't feel the difference in normal play.
One badly written plugin
A single sloppy plugin can tank an otherwise healthy server on its own. Spark will surface it in the flame graph. The common pattern is heavy work on the main thread: a live map renderer, an economy or logging plugin hitting a database synchronously, anything doing per-tick block scans across loaded chunks. If it's the widest bar and it isn't essential, cut it or swap in a maintained alternative.
Paper config tuning that's genuinely worth it
If you're still on Spigot or plain Vanilla, that's your biggest single upgrade. Paper (and Purpur, which builds on top of it) fixes hundreds of vanilla inefficiencies straight out of the box, and switching often beats any config change you could make. We spell out the differences between the flavors on the Minecraft Paper server page if you want to see how they stack up.
Once you're on Paper, a handful of defaults are worth changing:
- merge-radius: bump item merge to 3.5 and xp merge to 4.0 so dropped items and orbs clump instead of ticking one by one. Mob grinders love this.
- mob-spawner-tick-rate: raising it from 1 to 2 roughly halves spawner overhead with no visible change to players.
- alt-item-despawn-rate: make cobblestone and netherrack despawn faster so long mining sessions don't carpet the ground with item entities.
- update-pathfinding-on-block-update: turning this off stops mobs from recalculating paths on every nearby block change, which quietly helps near farms.
Do not paste someone's entire config off a forum and call it tuning. Change one value, watch MSPT in spark, keep what helps, revert what doesn't. A carefully tuned Paper server on modest hardware will outrun a sloppy one with twice the resources, and that's not close.
Pre-generate your chunks
Building brand new terrain is one of the most expensive things a server ever does. When a player sprints off into land nobody's visited, the server generates every chunk on the fly, and MSPT spikes hard for the duration. The cure is to generate the world ahead of time with Chunky.
Run /chunky radius 5000, then /chunky start, and let it grind through the map overnight while the server's empty. A 5000 block radius covers a genuinely huge play area. Once it's all on disk, players roaming that region cause almost no generation lag because the chunks already exist. Do this the day you launch, before people spread out, and you skip the stutter that otherwise hits every time someone stumbles into a new biome.
When it's the box, not the config
Minecraft's main tick loop runs on essentially one CPU thread, so single-core clock speed matters far more than core count. A server stuck on slow, oversold shared hardware will lag no matter how spotless your config is. Undersized RAM causes long garbage collection pauses that show up as rhythmic TPS drops, and spark's health report catches exactly these. Not sure whether memory is the bottleneck? Our guide on how much RAM a Minecraft server needs sizes it honestly against your player count and modpack.
Running off a home PC is a fine way to learn. You're also tying up your machine, eating your upload bandwidth, and sitting with zero DDoS protection the day someone decides to be a nuisance. Managed Minecraft server hosting puts you on fast single-thread hardware in Frankfurt, London, or Gravelines, so European players get low ping and your TPS stays pinned at 20 without you babysitting it.
Work the list top to bottom: TPS versus ping, profile with spark, cut simulation distance, tame hoppers and mobs, get onto Paper, pre-generate. Nine times in ten you'll fix Minecraft server lag long before you spend a euro. And if you've done all of it and the numbers still won't hold, that's the hardware under you talking, not anything you did wrong.