How to Reduce Lag on a Minecraft Server

First, work out which kind of lag you actually have

“The server is lagging” can mean three different things, and they need three different fixes. Lowering view distance will not help a player whose Wi-Fi is dropping packets, and a faster router will not help a server drowning in villagers. Spend two minutes sorting the symptom before you change a single setting.

Client lag is the player’s own computer struggling to draw the world. The picture stutters and the frame counter on the debug screen (F3 on Java) drops, but mobs, chat and block breaking still respond on time. Other players do not notice anything. Shaders, high render distance and big resource packs are the usual causes, and nothing on the server will fix it.

Network lag is the delay between a player and the server. Their ping in the player list is high or jumps around, actions take a moment to register, and other players may look like they are teleporting. It usually affects one player or one location, not everyone, and it is about distance, the player’s connection or the server’s upload, not about how busy the world is.

Server lag, also called tick lag or TPS lag, is the server failing to finish its work in time. Everyone feels it at the same moment: blocks reappear after being broken, mobs freeze and then jump, doors open late, and the day-night cycle, crops and furnaces all slow down because they run on ticks rather than real time. This is the kind of lag the rest of this guide is mainly about.

Java players can check both numbers in-game. Recent versions of the debug screen can show a tick-time graph (for operators on a server) and a ping graph with minimum, average and maximum ping, so a player can tell in a few seconds whether their own frames, their connection or the server is the problem.

Why Minecraft servers lag: the 50 ms tick budget

A Minecraft server runs its world in fixed steps called ticks. It aims for 20 ticks per second, so each tick has a budget of 50 milliseconds. In that window the server moves every loaded mob, item and minecart, runs redstone and hoppers, grows crops, spreads fire and water, processes player actions, and handles chunks that are loading, generating or saving.

If the work is done in 30 ms, the server simply waits for the next slot and players see a perfect 20 TPS. If a tick takes longer than 50 ms, the next one starts late and the server falls behind. That is why TPS is a poor early warning: it stays at 20 all the way up to the limit and only drops once the server is already overloaded. MSPT (milliseconds per tick) shows how much of the budget is used, which is why every serious tool reports it.

The key detail is that the tick runs on one main thread. The server can use other cores for jobs such as networking, chunk work and garbage collection, but the update of the world itself happens on one core, one tick after another. That is why single-core CPU speed matters more than the number of cores, and why a server can lag badly while its total CPU use looks low.

When the server falls far enough behind, the console prints a warning in the form Can't keep up! Is the server overloaded? Running ...ms or ... ticks behind. An occasional one during start-up or a big world save is normal. A steady stream of them during play means the tick is regularly over budget. In the extreme case, the vanilla watchdog stops the server when a single tick runs longer than max-tick-time, which defaults to 60000 ms (60 seconds).

Measure before you change anything

Guessing is the most expensive way to fix lag. A few commands tell you within minutes whether the server is behind, and a profile tells you why. Run them while the lag is actually happening: a report from a quiet server looks healthy and teaches you nothing.

Reading a spark report

/spark tps gives TPS and MSPT over recent time windows plus CPU use. /spark health adds memory and disk, and /spark health show --memory prints the memory detail straight into the console. For the cause, PaperMC recommends /spark profiler start --timeout 600: it samples the server for 10 minutes and then gives you a link to a report. Open the main server thread in that report and expand the largest branches. The names you find there are plain enough to act on: entity ticking, block entity ticking (hoppers, furnaces and other blocks with data), chunk generation or loading, a named plugin, or a named mod.

If the server is mostly fine but freezes for a moment every so often, an average hides the problem. spark’s own advice is to catch the spikes first with /spark tickmonitor --threshold-tick 50, which reports any tick slower than 50 ms, and then profile only the bad ticks with /spark profiler start --only-ticks-over 150 (pick a threshold below the length of your spikes). The report then contains nothing but the laggy ticks, and the culprit stands out.

Paper also ships Timings, but it has been unmaintained for years, is switched off by default in 1.21 and has been deprecated in favour of spark. Use spark.

Find the cause with this triage

Once you have MSPT and a profile, the cause usually falls into one of a handful of buckets. Work down the chart: each answer points at the section of this guide that fixes it.

Fix 1: bring simulation and view distance back to sensible values

These two settings in server.properties decide how much of the world the server has to handle for each player, so they change the load faster than anything else. Both default to 10 chunks on Java and both are measured as a radius around each player.

Simulation distance is how far from a player mobs and other living entities are updated. It is a CPU setting: every extra ring of chunks means more mobs, farms and machines that tick on the main thread. The radius grows the area as a square, so a simulation distance of 10 covers 441 chunks per player (21 × 21) while 6 covers 169 (13 × 13), well under half the work. If your profile is dominated by entity ticking, try 8 or even 6 before anything else.

View distance is how much of the world the server sends to each player. It mostly costs memory and bandwidth rather than tick time, because chunks outside the simulation distance are loaded and sent but not ticked. Keep it at or above the simulation distance; dropping it helps most when chunk loading and sending show up in the profile, or when players exploring in different directions push memory up.

On Paper you can override both per world in the spigot.yml world settings, so you can, for example, give the Nether and the End a lower simulation distance than the Overworld. Players can still choose a shorter render distance in their own settings, but never a longer one than the server allows.

The trade-off is real: farms, furnaces and crops only run when they are inside a player’s simulation distance. A mob farm designed around the default may slow down or stop when you lower it, so tell your players before you change it.

On Bedrock the equivalents are tick-distance (default 4, allowed 4 to 12) and view-distance (default 32). Bedrock’s default tick distance is already low, and every step up adds a whole ring of ticking chunks around each player, so raise it only as far as your farms really need.

Our guide to how much RAM a Minecraft server needs shows how many chunks each distance loads and what that does to memory.

Fix 2: cut entity lag from mobs, items and villagers

Entities are anything that moves or has its own logic: mobs, villagers, dropped items, experience orbs, arrows, minecarts, boats, armour stands and item frames. Each one needs movement, collision checks and often pathfinding AI every tick. A few hundred spread across a world are fine. Hundreds packed into a few chunks, which is exactly what animal pens, mob farms and villager trading halls do, are the most common single cause of tick lag.

Find where they are

On Paper, /paper entity list lists the entities that are currently ticking and can be filtered by type, and the spark profile shows how much time entity ticking takes and where. If one type dominates, you have found the problem. Common offenders are breeding pens with hundreds of cows or chickens, item farms whose output nobody collects, villager halls with dozens of villagers searching for beds and workstations, and minecart or boat piles left behind by builds.

Clear the build-up

Dropped items despawn after 6000 ticks (five minutes), but a farm that drops faster than they despawn keeps a permanent pile. Collect the output with hoppers into chests, or clear it with /kill @e[type=minecraft:item] as an operator. Cap breeding pens, move villagers that are not trading into a small number of tidy, bed-and-workstation-complete blocks, and remove abandoned minecarts. A friendly rule for the server, such as a mob cap per pen, prevents the problem coming back.

Tune entity settings on Paper and Spigot

Spigot-based servers (Spigot, Paper, Purpur) only fully tick entities that are close to a player. The distance is set per entity group in spigot.yml under entity-activation-range. Outside that range, entities are mostly idle and are woken up briefly at intervals, which saves a lot of work with little visible difference.

The defaults are already a good balance. If entity ticking still dominates your profile, lowering animals and monsters a little is a reasonable test, but go carefully: mob farms rely on mobs moving while players are nearby, and too short a range can make farms slow or break. Other settings worth knowing:

Change one setting at a time, restart, and compare MSPT under similar load. If nothing improved, put it back.

Fix 3: tame redstone clocks, hoppers and big machines

Redstone dust is expensive. Every change in power sends block updates to its neighbours, and a big contraption can trigger thousands of updates in one tick. Clocks that run all the time, even when nobody is near, are the worst case, because they burn tick time around the clock. In the profile this shows up as block ticking, redstone or neighbour updates in one area.

Start with the builds. Ask players to put clocks on a lever or a daylight sensor so they only run when needed, and replace long dust lines with repeaters or observers where it makes no difference to the design. Hoppers are a quieter cost: each is a block entity that checks for items above it every tick on Spigot and Paper by default (hopper-check: 1), so long hopper chains and hopper floors under farms add up.

Paper gives you two stronger tools. In the world config, redstone-implementation can be changed from VANILLA to ALTERNATE_CURRENT or EIGENCRAFT. Both can greatly reduce the lag caused by redstone dust, but both change how dust behaves, so test technical builds before switching on a server where players rely on exact vanilla redstone. In spigot.yml, hopper-transfer (default 8 ticks between moves) and hopper-check slow hoppers down to save work; raising them reduces lag but also slows every item sorter and farm collection system on the server, so it is a last resort.

Vanilla also has a safety limit, max-chained-neighbor-updates in server.properties (default 1000000), which stops one runaway chain of updates from freezing the server. Leave it at the default unless you know a specific build needs otherwise.

Fix 4: stop chunk generation lag by pre-generating the world

If the server only lags when people explore, fly with elytra or travel fast by boat on ice, it is generating new terrain. A brand-new chunk has to be generated, populated with structures and features, lit and saved before it can be sent, and when several players do this at once in different directions it competes with everything else the server is doing. The profile shows chunk generation or chunk loading near the top.

The fix is to generate the world in advance, when nobody is playing, and stop it growing without limit. Chunky is the widely used tool for this and runs on Paper, Spigot, Fabric, Forge and NeoForge. A simple sequence looks like this:

/worldborder set 10000
/chunky radius 5000
/chunky start

The world border is set as a full width, so 10000 means 5000 blocks in each direction from the centre, which matches the Chunky radius of 5000. /chunky pause and /chunky continue let you spread the job over several quiet periods, and Chunky shows progress and an estimated finish time. Pre-generating uses CPU and disk heavily while it runs and makes the world folder larger, so run it overnight or before launch, and keep backups. Once the area is generated, exploring inside the border only has to load chunks from disk, which is far cheaper than creating them.

Paper also limits how fast each player can load and receive chunks in its global config, for example player-max-chunk-send-rate at 75 chunks per second, which keeps one fast-moving player from swamping the server. The defaults are sensible; pre-generation is the real fix.

Fix 5: run the right server software

The plain vanilla server is the reference version of the game, but it has few performance options. For a public or busy survival server, the server software is often the single biggest improvement you can make.

Paper is a widely used fork of Spigot with many performance improvements, the settings covered above, built-in spark and support for Bukkit plugins. Purpur builds on Paper with extra gameplay options. Both change some vanilla behaviours by default in the name of performance or bug fixes, so technical players who rely on exact vanilla mechanics should check before you switch.

Fabric with Lithium suits groups who want vanilla behaviour. Lithium is a general-purpose optimisation mod that speeds up systems such as physics, mob AI and block ticking with the goal of not changing vanilla mechanics, and it only needs to be on the server; players do not have to install it.

Modded servers on Forge or NeoForge carry the cost of their mods. Machines, chunk loaders and mod mobs tick just like vanilla ones, so a big pack with a busy automation base needs far more CPU time than vanilla. Install the spark mod, profile, and look for one mod or one player’s base dominating the report. Our guide on how to add mods to a Minecraft server covers loaders and versions.

Fix 6: find the plugin or mod that is costing you

One badly written or badly configured add-on can use more of the tick than the whole vanilla world. In a spark profile, plugins and mods appear under their own names on the main thread, so look for any single add-on taking a large share of the tick. Typical offenders are plugins that scan the whole world on a timer, save data on the main thread, run heavy holograms or scoreboards for every player, or hook into every block or move event.

Once you have a suspect, update it first, then check its configuration for intervals and per-player features you can relax. If it is still expensive, replace it with a lighter alternative or remove it. Testing is simple: take the plugin out, restart, and compare MSPT at a similar player count. Avoid running two plugins that do the same job, such as two protection or two anti-cheat systems, since both pay the cost on every event.

Fix 7: rule out memory and garbage-collection pauses

Memory problems look different from tick lag. Instead of a steady slowdown, the server freezes briefly at regular intervals while Java’s garbage collector clears space, or it crashes with an OutOfMemoryError. /spark health show --memory and /spark gc show how full the heap is and how often and how long collections run.

If memory sits near the maximum and collections are frequent, the heap is too small for the world and its add-ons; lower view distance and trim plugins first, then give Java more room. If memory is comfortable and MSPT is still high, more RAM will not help, because the problem is CPU time on the main thread. Our Minecraft RAM guide explains how to size the heap and why it should never be set to your full plan size.

Fixing network lag for players

If the server reports a healthy MSPT but one or two players still complain, look at the connection. /spark ping shows the average ping across all players and /spark ping --player <name> shows one player’s round-trip time, which separates a server problem from a single player’s connection.

Distance is the first factor. Every extra thousand miles adds delay that no setting can remove, so a group based in the UK should play on a server in the UK or nearby in Europe. For a home-hosted server, the host’s upload speed is often the limit: every player receives a constant stream of chunks and entity updates, and a slow upload shared with video calls and streaming will make everyone’s ping jump. Players on Wi-Fi with packet loss will rubber-band even on a perfect server; a wired connection is the fix there.

Two server settings affect bandwidth. entity-broadcast-range-percentage (default 100) controls how far away entities are sent to players; lowering it reduces traffic and client load in mob-heavy areas, at the cost of mobs appearing closer. network-compression-threshold (default 256 bytes) decides which packets are compressed; lower values compress more and use less bandwidth but more CPU, and the default suits almost every server. View distance also has a large effect on bandwidth because it decides how many chunks each player is sent.

When tuning stops helping and an upgrade makes sense

Tuning has limits. If your profile is spread evenly across normal game work, entity counts are reasonable, there are no runaway farms or clocks, the world is pre-generated, and MSPT still sits near or over 50 ms at your normal player count, the server simply needs more CPU time per tick.

Because the tick runs on one thread, the upgrade that helps is a faster CPU core, not more cores or more RAM. On rented hosting, that means a plan or provider known for high single-core performance, or a move off an overcrowded machine where your server competes with many others. On a home server it means a newer CPU or moving the server off a machine that is also running the game client. Also check the disk: worlds stored on slow drives make chunk loading and autosaves visible as lag spikes, and sync-chunk-writes (on by default) trades some speed for crash safety, so it is best left on with fast storage underneath.

If you are comparing providers, our best Minecraft server hosting comparison covers UK locations, plan sizes and which hosts suit vanilla, plugin and modded servers, and our Minecraft dedicated server guide walks through hardware choices if you would rather run it yourself.

Minecraft server lag FAQ

What is a good TPS and MSPT for a Minecraft server?

A healthy server holds 20 TPS. MSPT is the more useful number: anything comfortably under 50 ms means the server is keeping up with room to spare, and the further below 50 the better it handles busy moments. Once MSPT goes above 50, TPS starts to fall and players feel lag.

Does more RAM reduce lag on a Minecraft server?

Only if the server is short of memory, which shows up as frequent garbage-collection freezes or out-of-memory crashes. Most lag is CPU time on the single main thread, spent on entities, redstone and chunks, and extra RAM does nothing for that. Check memory use with spark before paying for a bigger plan.

What simulation distance should I use on a Minecraft server?

The Java default is 10 chunks. Busy survival servers often run 6 to 8, which cuts the ticked area per player by more than half at 6. Lower values make farms and crops work only closer to players, so choose the lowest value your players’ builds still work with.

Why does my Minecraft server lag when players explore?

The server is generating new chunks, which is far more work than loading existing ones. Set a world border and pre-generate the area inside it with a tool such as Chunky while nobody is online, so exploring only loads ready-made terrain.

Is Paper better than vanilla for reducing lag?

For most plugin and survival servers, yes. Paper includes many performance improvements, extra settings for entities, redstone and chunks, and the spark profiler built in. It changes a few vanilla behaviours, so groups who want exact vanilla mechanics often choose Fabric with Lithium instead.

More Minecraft server guides

Our Minecraft host comparison and the guides that sit alongside this lag walkthrough.