Server lag is frustrating partly because "lag" gets used for two completely different problems, and the fixes do not overlap. So this checklist starts by working out what you actually have, then walks the fixes in the order that finds the most improvement for the least effort. Work down it in order. Do not skip to the hardware step, because it is almost never the first answer.

First, tell low TPS from high ping

These feel similar to a player and have nothing in common underneath.

  • Low TPS means the server cannot finish its work in time. The world runs in slow motion for everyone: mobs stutter, blocks break slowly, redstone drags. This is a server-side workload problem, and it is what most of this checklist is about.
  • High ping means the server is keeping up fine, but packets are slow getting to and from a player. That player rubber-bands and takes hits late while everyone else is smooth. This is a network problem, often that player's own connection or the distance to the server.

The quick test: if everyone is affected at once, suspect TPS. If it is one player while others are fine, suspect ping. We dig into the causes of both in what causes Minecraft server lag. The rest of this checklist is about TPS.

1. Measure before you touch anything

You cannot fix what you have not measured, and guessing usually costs you an evening.

  • Run /tps to see whether you are actually below 20. Then watch MSPT, the milliseconds each tick takes. Under 50 you have headroom; creeping toward and over 50 is where TPS starts to fall.
  • Install the spark profiler. A spark profile tells you which part of the tick is eating the time, whether that is entities, a specific plugin, chunk loading or something else. This one tool will save you more time than every other step combined.

Take a profile while the lag is happening, not after. The spike is the evidence.

2. View distance and simulation distance

These two settings are the biggest single lever on server workload, and they are separate.

  • View distance controls how many chunks are sent to players. Higher means more to load and keep track of.
  • Simulation distance controls how far out the server actually ticks entities, redstone and crop growth. This is the expensive one.

Dropping simulation distance from 10 to 6, and view distance to something sensible, often recovers a struggling server on its own. Players rarely notice the difference; the tick certainly does.

3. Entity and mob caps

Entities are one of the most common ways a tick fills up. Every mob, item frame, armour stand and dropped item is work.

  • Check your mob caps and lower them if they are high.
  • Look for entity build-up: item farms spewing drops, huge animal pens from breeding, thousands of items on the floor. A spark profile shows this clearly.
  • Use Paper's per-type entity settings to thin out or limit the worst offenders.

4. Hoppers and redstone hotspots

Hoppers and redstone are quiet tick killers because a single busy build can dominate the whole server.

  • Track down large hopper arrays and complex redstone contraptions. A big automated farm or a laggy clock can eat more tick time than every player combined.
  • Paper's hopper settings help, but sometimes the fix is asking a player to redesign a build. A spark profile will name the chunk.

5. Pre-generate your world

A lot of lag happens at the edges of the map, where the server generates new terrain on demand while players explore. Generation is expensive and it happens right in the path of the tick.

Pre-generate your world out to your border with a plugin like Chunky before you open to players, and set a world border so generation is bounded. Once the chunks exist, the server only loads them, which is far cheaper than making them.

6. Audit plugins one at a time

Plugins are the most common source of mystery lag, and the only reliable way to find a bad one is patiently.

  • Use your spark profile to see which plugins show up in the tick.
  • If you need to confirm, remove or disable suspects one at a time and watch MSPT after each. Change one thing, then measure. Changing five at once tells you nothing.
  • Watch for plugins doing heavy work on the main thread, running frequent database queries, or scanning large areas on a timer.

7. Choose the right server software

If you are still on Vanilla or Spigot, moving to Paper is a straight upgrade in performance and configuration, and every plugin comes with you. Purpur builds on Paper with extra settings, some of which, like villager lobotomize, save real tick time. The full trade-off is in Paper vs Purpur, and the settings by tier are in the SMP tuning guide.

8. Tune the JVM and heap

Once the workload is under control, how Java is configured decides whether garbage collection pauses show up as stutters. Give the server a sensible heap for its plan, not everything you have, and use a tuned flag set so GC pauses stay short. We walk through the whole thing in Aikar's flags and JVM tuning.

9. Only now, look at hardware

If you have measured, tuned the settings, thinned the entities, pre-generated the world, audited the plugins and sorted the JVM, and the tick is still over budget, then it is a hardware question. Because the tick is single-thread bound, what matters is per-core clock and cache, not core count. Which chip to want, and why, is covered in choosing a CPU for Minecraft.

Hardware is last for a reason. A faster chip papers over a lot, but it cannot outrun a runaway hopper array or a plugin scanning the whole world every tick. Fix the workload first, and the hardware you have usually turns out to be enough.

In the spirit of the list, one admission about our side of it. The tuning we do underneath is overkill for most of what runs on it, and it will not save you from a runaway hopper array either. What a well-tuned host does is take itself off the list of suspects, so you reach step nine and find nothing waiting there.

If you would rather start from a box that is not fighting you, or want a second pair of eyes on a spark profile, come and ask.

Browse game hosting