The fastest way to stop server lag is to measure it first, then change things in order: run Spark to find the actual bottleneck, switch to Paper (or Purpur) with Aikar's JVM flags, drop your view and simulation distances, and pre-generate chunks with Chunky. If hardware or network latency turns out to be the ceiling, that's when managed hosting from a provider like Nexonixhost becomes the practical fix rather than another config tweak.
TL;DR:
- Running Spark during lag episodes reveals whether entities, plugins, or chunk generation are the primary causes, guiding targeted fixes.
- Switching to Paper or Purpur with Aikar's JVM flags often yields significant performance improvements without hardware upgrades.
- Lowering view distance and simulation distance reduces server load, especially when combined with pregeneration of chunks during off-hours assessments.
- If MSPT exceeds 40 milliseconds under load despite tuning, upgrading to infrastructure built for gaming workloads is typically necessary.
- Regular monitoring, scheduled restarts, and maintaining a detailed change log help sustain optimal server performance over time.
Table of Contents
- Fix Minecraft Server Lag: The Priority Checklist
- How Do You Measure Minecraft TPS Lag?
- Tune Your Server Software and JVM Flags
- Why Are Entities and Plugins Causing TPS Drops?
- Pre-Generate Chunks to Stop Exploration Spikes
- Hardware and Network Checklist Before You Upgrade
- Keep Lag From Coming Back
- When Config Fixes Aren't Enough
- Managed Hosting Built for Performance-Sensitive Servers
- Sources
- FAQ
Fix Minecraft Server Lag: The Priority Checklist
When your server is actively chugging and players are complaining in chat, don't start changing five things at once. Work through this order.
- Run
/tpsand/ping, and note MSPT. This gives you a baseline before you touch anything. - Fire up Spark while the lag is happening. A profile taken during a calm moment tells you nothing.
- Drop view-distance to 6 and simulation-distance to 4-6 temporarily. This alone often buys back several TPS.
- Switch the server jar to Paper or Purpur if you're still running vanilla or Spigot.
- Apply Aikar's JVM flags, setting Xms equal to Xmx so the JVM isn't constantly resizing the heap.
- Disable or throttle known heavy features (automated mob farms, long hopper chains, villager breeders) while you isolate the cause.
Pro Tip: Change one item on this list at a time and re-check TPS after each step. If you flip four settings at once and lag disappears, you'll never know which one actually fixed it.
How Do You Measure Minecraft TPS Lag?
TPS (ticks per second) tells you how many times the game loop completes per second, with 20 being the target. MSPT (milliseconds per tick) is the more useful number, because it tells you how much headroom you actually have. According to SetupMC's breakdown of TPS and MSPT, keeping MSPT under a certain low threshold gives you room to sustain 20 TPS; once it climbs higher, the server physically cannot keep up and players will feel it.
Start with the basics:
/tpsfor a rolling average over 1, 5, and 15 minutes/pingto rule out network latency versus server-side tick lag- Paper's built in health commands to spot slow plugins or entities
Then bring in Spark's profiler. Run /spark profiler start, let it capture 2 to 5 minutes of realistic load, then stop it with /spark profiler stop and open the flame graph. Look for wide bars under EntityTick, PluginTask, or ChunkGen. Whichever one dominates the graph is where your lag actually lives, not where you assumed it lived.
Tune Your Server Software and JVM Flags
Vanilla and Spigot were never built for large populated worlds. Paper and Purpur ship with async chunk loading, smarter entity activation ranges, and dozens of performance patches that Mojang's base server doesn't have, which is why switching to Paper is one of the single highest-impact changes you can make without touching hardware. Purpur builds on Paper with even more configurable mob and world behavior, useful if you need granular control over specific gameplay mechanics.
For JVM tuning, follow Aikar's flags with two rules that matter more than the flags themselves: set Xms equal to Xmx so the JVM never pauses to resize the heap mid-game, and don't over-allocate RAM you don't need, since a bloated heap means longer garbage collection pauses.
A server given 16GB of heap when it only needs 6GB doesn't run faster. It runs slower, because the JVM now has more memory to scan every time garbage collection kicks in.
In server.properties, check view-distance, simulation-distance, and network-compression-threshold. In Paper's paper-world-defaults.yml and spigot.yml, tune entity-activation-range and hopper-check intervals to cut wasted tick cycles on entities players can't even see.
- Lower
view-distancebefore touching anything else client-facing - Reduce
simulation-distanceseparately, since it governs redstone, mobs, and crop growth, not rendering - Raise
network-compression-thresholdslightly on bandwidth-constrained connections
Why Are Entities and Plugins Causing TPS Drops?
Entities are usually the biggest tick consumer on a populated survival server, and Spark makes that obvious the moment you open a flame graph and see EntityTick or tileEntityTick eating a disproportionate slice of your budget. Long hopper chains and unchecked entity counts are the usual suspects behind that pattern.
- Locate mob farms and item-accumulation zones. AFK farms that stack hundreds of mobs or dropped items in one chunk are a classic TPS killer.
- Check villager hotspots. Breeder rooms with dozens of villagers packed into a few blocks tick constantly even when nobody's nearby.
- Audit your plugins with Spark. If
PluginTaskdominates the graph, disable suspect plugins one at a time and re-test. - Adjust config values directly: lower
max-entity-collisions, shorten item despawn time, and widenhopper-checkintervals so hoppers aren't scanning every single tick.
Pro Tip: Before banning a plugin outright, check if a lighter alternative exists that does the same job. Half of "bad plugin" lag comes from outdated code nobody's updated in two years, not from the feature itself.
Pre-Generate Chunks to Stop Exploration Spikes
New chunk generation is one of the most predictable lag spikes on any growing server, because the CPU has to build terrain in real time the moment a player walks somewhere new. Pre-generating with the Chunky plugin eliminates that spike entirely by doing the work before anyone shows up.
- Set a world border first, so Chunky knows the exact area to fill
- Run
/chunky radius 5000(or your target size) during off-hours, not during peak play - Expect heavy disk I/O for hours on larger radii, so schedule it overnight or on a maintenance day
- Prefer SSD or NVMe storage for this task specifically, since generation is I/O-bound as much as CPU-bound
Hardware and Network Checklist Before You Upgrade
Minecraft's main tick loop still runs largely on a single thread, so a CPU with a higher clock speed usually beats one with more cores but a lower clock. Selfhosting.sh's performance guidance points to the same conclusion: prioritize clock speed and fast storage over raw core count for the game loop itself.
| Resource | What matters most | Common mistake |
|---|---|---|
| CPU | High single-thread clock speed | Buying more cores instead of faster ones |
| RAM | Sized to player count, not maxed out | Over-allocating heap, triggering longer GC pauses |
| Storage | SSD/NVMe for chunk I/O | Running on spinning HDDs |
| Network | Low latency to your player base | Chasing bandwidth over ping |
If Spark shows your bottleneck isn't entities or plugins but raw tick time under load with nothing obvious in the flame graph, that's usually your signal the hardware itself is undersized.
Keep Lag From Coming Back
Fixing lag once doesn't mean it stays fixed. Set up ongoing monitoring so a new plugin, a growing farm, or a slow memory leak gets caught early instead of three weeks later when players start leaving.
- Set alerts for TPS and MSPT thresholds, not just a manual check when someone complains.
- Test every change under real load, one variable at a time, the same way you diagnosed the original problem.
- Schedule regular restarts to clear memory buildup and reset transient state before it becomes visible lag.
- Document every config change so you can roll back cleanly if something regresses.
- Automate pregeneration and restarts for off-peak hours so maintenance never collides with your busiest sessions.
Pro Tip: Keep a simple changelog, even a text file, listing what you changed and when. Six months from now you won't remember why hopper-check is set to 3 instead of the default.
When Config Fixes Aren't Enough
Most lag is solvable with profiling and configuration. Spark tells you where the tick time goes, Paper and Aikar's flags recover a meaningful chunk of it, and pregeneration with Chunky removes an entire category of spikes. But if your flame graph keeps showing clean code with no obvious hot path, and TPS still sags under normal player counts, that's not a config problem anymore. That's a sign the CPU clock speed, RAM headroom, or network path to your players is the actual ceiling, and no amount of hopper-check tuning will get you past it. That's usually when server owners start looking at infrastructure built specifically for low-latency, high-workload gaming rather than general-purpose hosting, with protections like DDoS mitigation and support that understands what a flame graph is.
— Conal
Managed Hosting Built for Performance-Sensitive Servers
Profiling and config work will solve most lag problems, and you should always exhaust those steps first. But if Spark keeps pointing to raw tick time with nothing suspicious in the plugin list, the fastest way forward often isn't another setting. It's infrastructure that was built for exactly this kind of workload from the start.
A hosting provider runs high-clock-speed processors suited to Minecraft's single-thread-heavy tick loop, backed by DDoS protection so a stress attack doesn't masquerade as a chunk-generation bug. Users get full file and root access, so nothing about their Paper build, plugin list, or paper-world-defaults.yml settings is locked away. Personal backups and continuous support help prevent a bad plugin update or a failed migration from turning into a lost weekend. If you've already run Spark, applied Aikar's flags, and pregenerated your world, and TPS still sags under load, check current Nexonixhost plans and see whether a move to purpose-built gaming infrastructure closes the gap your config file can't.
Sources
FAQ
How Can I Fix Lag on My Minecraft Server?
Run Spark to profile the actual bottleneck, switch to Paper or Purpur with Aikar's JVM flags, lower your view and simulation distances, and pre-generate chunks with Chunky. Change one thing at a time and verify with /tps and MSPT before moving to the next fix.
How Do I Make a Minecraft Server Run Smoother?
Beyond the initial fixes, keep MSPT under 40 milliseconds, audit plugins regularly with Spark, and schedule restarts to clear memory buildup. If those steps max out and TPS still drops, the CPU clock speed or network path is likely the real limit, and hosting built for gaming workloads, like Nexonixhost, becomes the next logical step.
Why Is Minecraft Laggy Even Though My PC Is Good?
A powerful client PC doesn't fix server-side lag, since TPS and MSPT are governed by the server's CPU, entity load, and plugin behavior, not the player's hardware. Run /ping to separate network latency from actual tick lag on the server itself.
Is Minecraft 1.21 Laggy?
Any version can run poorly on unoptimized vanilla software with default settings; version number alone isn't the cause. The fix is the same regardless of version: profile with Spark, run Paper or Purpur, and tune JVM flags and distances rather than assuming a specific update is to blame.