How to Fix Minecraft Server Lag

Quick Summary

Minecraft server lag usually isn’t caused by a single issue—it’s the result of compounding inefficiencies. This guide breaks down how to identify real performance bottlenecks, apply high-impact fixes first, and then scale into deeper optimizations. It also explains how Firecone’s optimized forks, Discord feedback loop, and roadmap-driven development help push performance beyond stock configurations.

What “Lag” Actually Means in Minecraft

Minecraft servers run on a fixed 20 TPS (ticks per second). When the server can’t finish all required work within a tick, TPS drops—and everything slows down.

Lag is not random. In production servers, it consistently comes from the same categories of workload.

The Core Performance Killers

Entities
Mobs, villagers, armor stands, dropped items, and tile entities all tick. Density matters more than total count.

Chunk workload
Generating or ticking too many chunks—especially during exploration—rapidly saturates CPU time.

Automation
Redstone clocks, observers, hoppers, and pathfinding-heavy mechanics amplify per-tick cost.

Every optimization decision should reduce one or more of these costs.

Phase 1: High-Impact Fixes (Do These First)

These changes deliver the largest performance gains with minimal risk.

1. Use a Performance-Oriented Server JAR

Your server software defines what optimizations are even possible.

Recommended hierarchy:

Purpur – Maximum configurability and aggressive optimizations
Paper – Stable, well-supported baseline
Pufferfish – Specialized entity and hopper improvements
Spigot – Minimal optimizations
Vanilla – Only for specific technical use cases

Avoid entirely:

Paid “performance” JARs with unverifiable claims
Forge+Bukkit hybrids (Mohist, Magma)
Unmaintained forks

Upgrade path: Vanilla → Spigot → Paper → Purpur
Each step preserves compatibility while expanding tuning options.

Firecone note:
The Firecone Discord regularly shares optimized and experimental forks tuned for real workloads. These often include patches not yet upstreamed and are announced directly to the community.

2. Reduce View and Simulation Load

View distance is the single most expensive server setting.

view-distance=8
simulation-distance=4

Paper allows further separation using non-ticking chunks:

no-tick-view-distance: 12
entity-broadcast-range-percentage: 100

Practical presets:

Survival (20–30 players): 8 / 4
Creative: 12 / 3
PvP / Minigames: 6 / 6
Large servers: 5 / 3

Reducing view distance from 10 → 8 often yields 20–30% TPS gains under load.

3. Eliminate Live Chunk Generation

Chunk generation during gameplay is one of the most CPU-expensive operations.

Pre-generate worlds using Chunky:

/worldborder set 10000
/chunky radius 5000
/chunky spawn
/chunky pattern concentric
/chunky quiet 300
/chunky start

Rules of thumb:

Generate before launch or off-peak
Pre-generate all dimensions in use
Match world border to generated area

Pre-generated servers routinely see 30–50% higher TPS during exploration-heavy play.

Phase 2: Stabilizing the Tick Loop (JVM + Config)

Once the obvious wins are applied, focus on consistency and long-term stability.

JVM Memory and GC Strategy

Correct JVM configuration reduces GC pauses and TPS jitter.

Baseline rules:

Always set Xms = Xmx
Never exceed ~50% of system RAM
2–4GB: small servers
6–8GB: larger or modded servers
Past ~12GB: diminishing returns

G1GC is recommended for most setups. ZGC can be viable at very high memory sizes on Java 17+.

Paper-Level Optimizations That Matter

From paper-world-defaults.yml, prioritize settings that reduce per-tick work:

Lower mob spawn limits
Reduced entity activation ranges
Slower hopper transfer rates
Alternate redstone implementation
Aggressive item despawn rules

These changes significantly lower tick cost without requiring more hardware.

Always validate farm behavior after changes—performance improvements can alter mechanics.

Phase 3: Plugins, Not Bloat

Plugins are one of the most common self-inflicted lag sources.

Keep Only What Helps

Worth using:

spark – Non-negotiable profiler
Chunky – World pre-generation
EntityLimiter / FarmControl – Prevents lag machines
ClearLag – Only when carefully configured

Avoid plugins that:

Continuously scan all chunks
Log high-frequency events to databases
Update holograms or scoreboards every tick
Run heavy anti-cheat logic without profiling

Profile every plugin. If you can’t measure its cost, it doesn’t belong on a performance-focused server.

Hardware and Location Still Matter

Even perfectly optimized servers hit hardware limits.

Minecraft is largely single-threaded. High clock speed beats core count.

This is why Firecone prioritizes modern high-frequency Ryzen platforms—optimized for Minecraft’s tick loop rather than generic server workloads.

Location matters too:
Hosting near your player base reduces latency and improves perceived smoothness, even when TPS is stable.

Operations: Keeping Performance Over Time

Optimization degrades if you don’t maintain it.

Routine Monitoring

Daily:

/spark tps
/spark gc
/paper entity list

Weekly:

Remove stale player data
Trim unused chunks
Review profiler reports
Test updates before deploying

Automated restarts, backups, and TPS alerts prevent slow performance decay.

Players Are Part of the System

Server rules directly affect TPS.

Guidelines like limiting mob density, banning lag machines, and discouraging infinite redstone loops can dramatically reduce load. Framing these as server health guidelines instead of restrictions leads to far better compliance.

When TPS Drops: A Structured Response

Immediate:

Check TPS
List entities
Clear excess items if needed

Diagnosis:

Run spark profiler
Identify problematic chunks
Inspect redstone and farms

Avoid random config changes under pressure—measure first, then act.

Going Further with Firecone

Performance optimization doesn’t stop at configs.

Optimized and experimental forks are shared via the Firecone Discord
You can request optimizations, report bottlenecks, or describe workloads directly to the team
Infrastructure and performance updates are announced first to the community

Want to see what’s coming next?
Check the Firecone roadmap for upcoming optimization features and infrastructure upgrades:
https://firecone.eu/roadmap

Or follow discussions and announcements on Discord to stay ahead.

Final Thoughts

A smooth Minecraft server is built through efficiency, not brute force. Apply high-impact fixes first, stabilize the tick loop, profile relentlessly, and involve your community.

These techniques scale from small private servers to large public networks. Results will vary—but systematic optimization always pays off.

If you hit a wall, Firecone’s team and community are there to help—through Discord, support, or upcoming roadmap features.

Looking for hosting that works with your optimizations? Firecone gives you full file access, one-click Paper and Purpur installs, and an ecosystem designed around performance. Build once, scale cleanly, and keep TPS where it belongs.