Reduce lag on your Minecraft server

"Lag" means three different things in Minecraft, and only one of them is the server's fault. Work out which one you have before changing anything, then go through the fixes below roughly in order: the first ones cost nothing and help almost every server.

Server lag, ping or FPS?

The server runs the game in ticks, 20 times per second when all is well. That is the TPS, ticks per second. Each tick has 50 milliseconds to finish; when ticks take longer, TPS drops below 20 and the whole world slows down.

Our servers are in Bucharest, so players far from Romania will always have a higher ping, and no server setting changes that. FPS is drawn entirely on the player's machine; their own render distance or a client mod like Sodium helps there, not anything on the server.

To check TPS, type these in the panel's Console page:

tps
mspt

tps works on Paper, Purpur and Spigot and shows the average over the last 1, 5 and 15 minutes. mspt is a Paper command that shows how many milliseconds a tick takes; steadily under 50 means the server keeps up. If TPS is a solid 20 while players complain, the problem is ping or FPS. Otherwise, write the numbers down before you change anything, so you can tell whether each fix below actually helped.

Run Paper or Purpur

The server software matters more than any single setting. Paper is a fork of Spigot that fixes many slow parts of vanilla Minecraft and runs the same Bukkit and Spigot plugins, so for a plugin server there is rarely a reason to stay on Spigot. Purpur builds on Paper and adds extra gameplay options in purpur.yml. Either is the right choice for most survival servers.

Vanilla has no plugins and none of these improvements. Folia splits the world across many CPU cores, which does little on a plan with one or two cores, and most plugins do not support it. On Fabric, server-side mods such as Lithium and FerriteCore do a similar job to Paper's changes.

You can switch on the Versions page in the panel. Take a backup first and read the version guide, because changing software touches the whole server.

Lower view-distance and simulation-distance

These two settings in server.properties decide how much of the world the server keeps loaded around each player. simulation-distance is the expensive one: inside it, mobs move, crops grow and redstone runs. view-distance only controls how far players can see. Both default to 10, and the work grows with the square of the distance, so small reductions save a lot.

A sensible starting point on a small plan is a simulation-distance of about 6 and a view-distance of about 8. Change them on the Configs page, restart, and compare your TPS with the numbers you wrote down. Go lower only if you still need to. The server.properties guide shows where both settings live.

Pre-generate the world with Chunky

Generating new terrain is one of the heaviest things a server does. Every time someone explores, especially flying with an elytra, the server builds new chunks while also running the game. Pre-generating the world removes that cost: you generate an area once, while nobody is playing, and later exploration only loads chunks that already exist.

Install the Chunky plugin, for example from the Plugin Manager, and restart. Then set a world border, tell Chunky to fill it, and start the job from the console:

worldborder set 6000
chunky worldborder
chunky start

worldborder set 6000 makes a square 6,000 blocks wide, centred on the coordinates 0, 0. chunky pause and chunky continue stop and resume the job. Start with a modest size: a bigger border takes much longer and uses more disk space. The job only runs while the server is on, so keep the panel open and renew on time, as the renewal guide explains. The world border keeps players inside the pre-generated area.

Profile with spark

When TPS is low and you do not know why, spark tells you. Recent Paper builds include it, so the spark command is already there; on other servers, install spark as a plugin or mod. Start a profile while the lag is happening, let it run for a few minutes, then stop it:

spark profiler start
spark profiler stop

spark answers with a link to a report. Open it and look at what takes the most time inside the server tick: a plugin's name, a type of entity, hoppers or another block entity. That tells you what to fix instead of guessing. spark health gives a quick summary of TPS, tick times, memory and CPU.

Entity farms and redstone

Most heavy lag on survival servers comes from things players build. The usual suspects:

• Mob farms that collect hundreds of mobs without killing them.
• Item piles from farms nobody empties. Thousands of dropped items on the ground cost real time every tick.
• Villager halls. Villagers have expensive pathfinding, and a trading hall with dozens of them adds up.
• Hopper chains and redstone clocks that run constantly, even when nothing needs them.

Talk to the builders first: adding a kill chamber, an off switch or a lid on a farm is usually enough. Paper and Spigot also have settings for this, such as entity-activation-range in spigot.yml and spawn-limits in bukkit.yml, both editable on the Configs page. Change one value at a time and measure again afterwards.

Read the panel's resource graphs

The Console page shows three graphs: CPU Usage, Memory Usage and Inbound / Outbound network traffic. The CPU limit is shown as a percentage, where 100% is one core: 125% on Lite, 150% on Turbo and 180% on Max.

• CPU sitting at the limit while TPS is low means the server needs more processing time than the plan has. Profile with spark first; a single farm or plugin is often the cause.
• Memory near the top is normal for Java on its own. Torchlite gives Java a heap of the plan's RAM minus a fixed reserve for everything Java keeps outside the heap (1088 MB on Lite for Paper), and Java fills it before it cleans up. When nobody is online it hands unused memory back after a few minutes. It only becomes a problem when the console shows OutOfMemoryError or the server crashes.
• Network traffic rarely explains lag on a small server.

Once the server has been running for more than five minutes, the panel also shows a Low on resources banner whenever CPU, memory or disk goes above 95% of the limit.

When to pick a bigger plan

Move up only after the free fixes: Paper or Purpur, shorter distances, a pre-generated world and a spark profile with nothing obvious left to fix. If CPU still sits at the limit with only a few players online, or the console keeps reporting OutOfMemoryError, the server needs more room.

For Paper, Purpur, Spigot, Fabric and Folia, the plans are Lite and Turbo. Turbo has twice the RAM of Lite and 1.5 cores instead of 1.25, but it asks for renewal every 40 minutes instead of 50. Forge and NeoForge run only on Max. The plan is picked when a server is created, so moving up means creating a new server on the bigger plan and copying your world and plugins over with SFTP.

Common problems

TPS is 20 but players still rubber-band

The server is keeping up, so the problem is the network. Ask the affected player to try a wired connection or another network. Players far from Bucharest will always have more ping than those nearby.

The lag starts whenever someone explores

That is new terrain being generated. Pre-generate with Chunky and set a world border so exploration stays inside the generated area.

Lag spikes every few minutes

Regular spikes often line up with world saves or with a plugin's scheduled task. Run a spark profile that covers several spikes; the report shows what runs during them.