Every server owner eventually types "how to fix minecraft server lag" into a search engine at 1 a.m. while players complain in Discord. What they find is a decade of cargo-culted advice: allocate more RAM (usually wrong), install six "optimization" plugins (mostly obsolete), reduce view distance to 3 (players hate it, and it might not even be your problem). This guide does it properly: first diagnose which lag you have — there are three kinds and they have nothing to do with each other — then apply the fixes that actually move the needle, in order of impact.
Step 0: Which of the three lags do you have?
"Lag" is three unrelated problems wearing the same trench coat:
| Type | What players say | The telltale | Fixed by |
|---|---|---|---|
| TPS lag (server tick) | "Mobs freeze, crops won't grow, blocks reappear" | Everyone lags at the same time; /tps below 20 | This guide |
| Network lag (ping) | "I take hits from nowhere, PvP feels off" | Only some players affected; TPS is a clean 20 | Server location/routing — config can't help |
| Client lag (FPS) | "My game stutters" | One player affected; their FPS counter is low | Their settings, not your server |
The server only controls the first row. Run /tps (any Paper-family server): 20.0 TPS means the server is healthy and your "lag" is rows two or three — stop here and check ping and client FPS before touching a single config. Below ~19.5 sustained, keep reading. The finer metric is MSPT (milliseconds per tick, /mspt): the server has a 50 ms budget per tick, so MSPT under 50 is healthy, and MSPT hovering near 40+ is your early warning before TPS visibly drops.
Step 1: Profile with spark — never guess
spark ships built into modern Paper. One command tells you exactly what's eating your ticks:
/spark profiler start --timeout 120After two minutes it prints a link to a flame graph — a visual breakdown of where every millisecond went. You don't need to be a developer to read it: look at the widest bars. In practice, almost every lagging server's profile is dominated by one of five culprits: entities (mob farms, item piles), chunk loading/generation (someone's on an elytra), hoppers, redstone clocks, or a single misbehaving plugin. The profile tells you which section of this guide you actually need — apply fixes blind and you'll "optimize" things that were never the problem.
Step 2: The seven changes that actually matter
Ordered by real-world impact on a typical Paper survival server. (Running Spigot? Switching to Paper is the optimization — see our server software comparison.)
1. Split view distance from simulation distance
The single best trade in server administration, in server.properties:
view-distance=8
simulation-distance=5View distance is how far players see; simulation distance is how far the server ticks mobs, crops, and redstone. Ticking is expensive, sending chunks is cheap — so players keep long sightlines while your tick loop only works a 5-chunk radius. Most servers ship both at 10 and burn CPU simulating chunks nobody is standing in.
2. Pre-generate your world
Chunk generation is among the most expensive things a server does, and it happens live every time someone flies toward fresh terrain. Set a world border (e.g. /worldborder set 20000), then pre-generate everything inside it with the Chunky plugin:
/chunky radius 10000
/chunky startLet it run overnight. Exploration afterward costs almost nothing — the chunks are already on disk. This one change is why "the server dies every time someone goes elytra flying" stops happening. Do the nether too (radius ÷ 8).
3. Cap the mob farms
Entities are the #1 profiler result on survival servers, and it's rarely "too many players' pets" — it's one person's 4,000-entity raid farm. In bukkit.yml, lower ambient spawn caps (monsters: 45 instead of 70 is barely noticeable in normal play), and in Paper's config/paper-world-defaults.yml, turn on merge-radius for items/XP and despawn-ranges tuning. For persistent overbuilt farms, per-chunk entity limits let the server quietly cap hostile mobs per chunk instead of you moderating builds by hand.
4. Slow the hoppers
Every hopper checks for items above it and containers around it, every 8 ticks, forever — and storage-hall builds use thousands. In spigot.yml, raising ticks-per: hopper-check from 8 to 16 halves that cost with minimal gameplay impact; item-transfer cooldowns in Paper's config compound the saving. Big sorting systems still work, just marginally slower.
5. Audit your plugins with the same profiler
A single badly written plugin — usually one doing database writes on the main thread, or scanning every online player every tick — can cost more than all vanilla systems combined. Your spark profile names it directly under its package name. Test by removing the suspect on a staging copy; don't accumulate 40 plugins and wonder. (Backup before plugin surgery: a backup that actually restores.)
6. Fix your JVM flags and heap size
Rhythmic freezes every few minutes with clean MSPT between them are garbage-collection pauses, not tick lag — that's a memory configuration problem, covered in depth in our server RAM guide (short version: Aikar's flags, -Xms=-Xmx, and don't over-allocate).
7. Accept when it's the host
If your profile shows nothing egregious, MSPT is high anyway, and it's worst at peak hours across all activities — you're on an oversold shared vCPU, and no config flag fixes a neighbor mining crypto on your core. Minecraft's main loop is single-threaded: per-core speed is everything. The jump from budget shared hosting to a modest dedicated-core VPS is the biggest hardware win available; our 2026 cost guide shows it's cheaper than most people assume.
The 10-minute checklist
/tps— 20.0? It's not server lag. Check ping/client first./spark profiler start --timeout 120— read the widest bars.view-distance=8,simulation-distance=5, restart.- World border + Chunky pre-gen overnight.
- Entities in profile? Lower spawn caps, cap the mega-farms.
- A plugin in the profile? Test without it on a copy.
- Rhythmic freezes? GC tuning → RAM guide.
- Still bad at peak? The host is the bottleneck.
Why this is worth the evening it takes
Performance is a retention feature. In our analysis of 366 live servers, two-thirds of online servers had 20 or fewer players — and a first-time visitor who rubber-bands through their first five minutes becomes one of the leavers, not one of the 20. A smooth server converts visitors; everything else in server promotion multiplies from there.
Server running smoothly? Put it in front of players — add it to the list for free and let them find you.