How to Optimize Your Minecraft Server to Stop Lag (2026 Guide)

If your Minecraft server chugs the moment three or four players start building, mining, or fighting at once, the problem is rarely “just get more RAM.” Lag on a Minecraft server almost always comes from one of three places: an underpowered CPU choking on single-thread tick calculations, a poorly configured Java runtime, or world data that has been allowed to bloat unchecked for months. This guide walks through all three, in the order that actually moves the needle.

None of this requires you to switch hosts or spend more money. Most of what follows is free, takes under an hour, and applies whether you’re running a small survival world for friends or a public server with 30+ concurrent players.

Why Minecraft Lag Isn’t Really About RAM

Minecraft’s server tick loop runs on a single CPU thread. Every redstone circuit, every mob pathfinding calculation, every chunk that needs to generate, and every block update all queue up on that one thread, 20 times per second. If the thread can’t finish its work within 50 milliseconds, the server “falls behind” — that’s the stutter and rubber-banding players feel as lag.

RAM prevents crashes and garbage collection pauses, but it does nothing to speed up that single thread. This is why a server with 16GB of RAM can still lag badly if the CPU’s single-core clock speed is weak, or if the world is poorly optimized. Fix the CPU-bound bottlenecks first — they’re usually free.

Step 1: Switch to Paper (If You Haven’t Already)

Vanilla and Spigot servers process every entity and chunk exactly as Mojang wrote them, with no shortcuts. Paper is a drop-in replacement server jar that keeps full plugin and gameplay compatibility but rewrites huge parts of the tick loop for performance — smarter entity tracking, async chunk loading, and dozens of configurable optimizations that vanilla doesn’t expose at all.

If you’re still on vanilla or Spigot, this single change typically recovers more performance than any hardware upgrade. Download the latest Paper build for your Minecraft version from papermc.io, swap the jar, and restart — your world, playerdata, and most plugins carry over without modification.

Step 2: Set the Right Java Flags

How you launch the server matters almost as much as the hardware underneath it. The default Java garbage collector was never designed for a real-time application ticking 20 times a second, and it will periodically pause the entire server for garbage collection — this is what causes those random half-second freezes even on a lightly-populated server.

The Aikar’s flags set (maintained by one of the original PaperMC developers) tunes the G1 garbage collector specifically for Minecraft’s memory allocation pattern. Replace your current startup command with this, swapping in your actual RAM allocation:

java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:MaxTenuringThreshold=1 -jar paper.jar nogui

Two things matter here. First, always set -Xms and -Xmx to the same value — letting the heap dynamically resize causes its own pauses. Second, don’t allocate more RAM than the server needs; a common mistake is assigning 12-16GB to a small survival world, which actually makes garbage collection pauses longer because there’s more heap to scan. For most servers under 20 players, 4-8GB is plenty.

Step 3: Tune paper-world-defaults.yml

Paper exposes dozens of settings that trade a small amount of vanilla accuracy for a large amount of performance. Most players never notice the difference; your tick timer will. These live in config/paper-world-defaults.yml (or paper.yml on older Paper versions):

• entity-per-chunk-save-limit — caps how many entities (items, mobs, minecarts) get saved per chunk, preventing item-duping farms or mob grinders from ballooning your world save time.
• mob-spawner-tick-rate — spawners default to ticking every cycle; raising this to 2-4 cuts spawner-related load with no visible gameplay change.
• hopper-transfer / tick settings — hopper-heavy farms are one of the single biggest silent lag sources on survival servers. Slowing hopper tick speed slightly reduces load dramatically on item-sorting builds.
• non-player-arrow-despawn-rate and item-despawn-rate — shorter despawn timers for dropped items and stray arrows keep entity counts from creeping up during busy sessions.

Change these gradually and restart between changes — tuning ten settings at once makes it impossible to tell what actually helped.

Step 4: Diagnose Before You Guess

Don’t tune blind. Paper ships two commands that tell you exactly where tick time is going instead of leaving you guessing:

• /tps — shows your ticks-per-second over the last 1, 5, and 15 minutes. Anything below 19 consistently means the server is falling behind.
• /timings report — generates a full breakdown of exactly which plugins, entities, or world regions are eating tick time, with a shareable link. This is the single most useful diagnostic tool available and takes less than 2 minutes to run.

Run a timings report before making any changes, then run another one after. If a specific plugin or world region shows up consistently at the top, that’s your actual bottleneck — not whatever you assumed it was.

Step 5: Clean Up the World Itself

Worlds that have been played on for months accumulate chunks that were generated once, explored, and never visited again. Every one of those chunks still gets loaded, saved, and processed if an entity or player wanders near it. Two free tools fix this:

• MCA Selector or the Prune-chunks feature in some panels lets you delete chunks the actual playerbase never explored, shrinking world size and load time without touching builds near spawn.
• view-distance and simulation-distance in server.properties — lowering view-distance from the default (often 10) to 6-8 cuts chunk-loading overhead dramatically with minimal visual impact for most players, and simulation-distance controls how far away entities/redstone actually tick, which matters even more for CPU load than view-distance does.

Frequently Asked Questions

Will Aikar’s flags work on any host?

Yes — they’re just Java startup arguments, so they work on any host that lets you edit the start command, including self-managed VPS setups. Managed hosts with a fixed startup script (some budget shared-hosting panels) may not let you edit flags directly; check your panel’s Java/JVM settings section first.

How much view-distance should I actually use?

8 is a reasonable default for most survival servers. Go lower (6) if you’re CPU-constrained and running 15+ players; go higher (10+) only if you have CPU headroom to spare and players specifically complain about pop-in.

Do I need to switch hosts to fix lag?

Usually not. The steps above fix the majority of lag complaints without touching hardware. If you’ve already applied Paper, Aikar’s flags, and world cleanup, and /timings shows the tick time is genuinely CPU-bound with no single culprit, that’s the point where a host with a faster single-core CPU actually helps.

Conclusion

Lag fixes work best in order: switch to Paper if you haven’t, apply proper JVM flags, tune the handful of world-defaults settings that matter, diagnose with /timings instead of guessing, and clean up chunks and view-distance last. Most servers that “need better hosting” actually just need these five steps done properly — try them before spending money on more hardware.