To reduce chunk loading lag on a Minecraft server, pre-generate your world with Chunky, lower view and simulation distance, use Paper or Purpur for async chunk loading, and make sure your server runs on an SSD. These changes target the root causes of chunk lag rather than masking symptoms.
Chunk loading is one of the most common sources of lag spikes on Minecraft servers. Every time a player explores new territory, teleports, or flies with an elytra, the server has to load or generate chunks on the fly. When it can't keep up, TPS drops, players rubber-band, and the entire server stutters.
How Chunk Loading Works
Minecraft's world is divided into 16x16 block columns called chunks. The server only keeps chunks near active players loaded in memory. As players move, new chunks need to be loaded and old ones unloaded.
There are two very different operations happening here:
Loading existing chunks means reading previously saved chunk data from disk into memory. This is relatively fast, especially on an SSD. The data already exists, the server just needs to read it.
Generating new chunks means calculating terrain, caves, biomes, structures, ore placement, and decoration from scratch. This is far more expensive because the server runs the full world generation pipeline, which involves noise calculations, structure placement, feature decoration, and lighting. A single new chunk can take 10-50x longer to process than loading a saved one.
Both operations compete for the server's tick budget. Every tick must complete within 50 milliseconds to maintain 20 TPS. When chunk work pushes a tick past that window, TPS drops and players feel the lag.
What Causes Chunk Loading Lag
Live Chunk Generation
The biggest source of chunk lag is generating terrain in real time. When players explore areas nobody has visited before, the server has to build that terrain from nothing while simultaneously running mob AI, processing redstone, handling player actions, and everything else that happens in a tick.
On vanilla and Spigot servers, chunk generation runs on the main thread, meaning it directly competes with all other game logic for CPU time. One player exploring in a new direction can tank the TPS for everyone.
CPU Bottleneck
Chunk generation is CPU-intensive work. It relies heavily on single-thread performance because the world generation pipeline processes sequentially. A server with plenty of RAM but a weak CPU will struggle with chunk generation regardless of how much memory you throw at it.
Disk I/O Bottleneck
Loading saved chunks requires reading data from storage. On a traditional hard drive (HDD), this involves physical seek time that adds latency to every chunk load. An SSD eliminates mechanical delays, and an NVMe SSD pushes read speeds even higher. The difference is measurable: loading a batch of chunks from an HDD can take 5-10x longer than from an NVMe drive.
Disk I/O also matters during autosaves. When the server writes chunk data to disk, slow storage creates lag spikes. Paper's max-auto-save-chunks-per-tick setting helps spread this load, but fast storage is the real fix.
Teleport Lag
When a player teleports, the server needs to load every chunk within their view distance at the destination instantly. A view distance of 10 means loading up to 441 chunks at once (a 21x21 area). If those chunks haven't been generated yet, the server has to generate all of them simultaneously, causing a massive spike.
This is why teleporting to unexplored areas is one of the worst lag triggers on a server.
Elytra Flight Spikes
Elytra flight lets players move faster than the server can comfortably generate terrain. At full speed, a player crosses chunk boundaries every few seconds, forcing the server to constantly load or generate new chunks ahead of them. Multiple players flying in different directions multiplies this load.
View and Simulation Distance
View distance controls how many chunks are sent to each player. Simulation distance controls how many chunks are actively ticked. Both increase the number of chunks the server manages per player.
At a view distance of 10, each player needs 441 chunks loaded. At 8, that drops to 289. At 6, just 169. The relationship is quadratic, meaning small reductions have outsized impact. For detailed settings, see our view and simulation distance guide.
Multiple Players Exploring
Each player exploring in a different direction creates a separate stream of chunk generation work. Five players heading in five directions generates five times the chunk load compared to five players staying in one area. This is why servers with exploration-heavy gameplay need more aggressive optimization than servers where players stay near their bases.
Pre-Generating Your World
Pre-generation is the single most effective fix for chunk loading lag. Instead of generating terrain on the fly during gameplay, you generate it ahead of time when players aren't online (or when you don't mind temporary TPS loss).
How It Works
The Chunky plugin generates chunks within a specified radius from a center point and saves them to disk. Once generated, those chunks only need to be loaded (fast) instead of generated (slow) when players reach them.
Basic Chunky Commands
/chunky radius 5000
/chunky start
This generates all chunks within a 5,000-block radius of your current position. For most servers, a radius of 3,000-5,000 blocks covers the main play area. Larger servers or exploration-focused communities may want 8,000-10,000.
When to Pre-Generate
- Before opening a new server to players
- After a world reset before letting players back in
- After adding worldgen mods that change terrain generation
- Around common teleport destinations like spawn, warps, and player bases
For step-by-step installation and usage, see our Chunky pre-generation guide.
Pre-Generation Limitations
Pre-generation only helps with areas that have been generated. If players explore beyond the pre-generated border, they hit live generation again. Consider setting a world border at your pre-generated radius to prevent this, or pre-generate a large enough area that players rarely reach the edge.
Optimizing Server Settings
View Distance and Simulation Distance
Lowering these two values is the fastest way to reduce chunk load without installing anything.
| Setting | Default | Recommended | Effect |
|---|---|---|---|
| view-distance | 10 | 7-8 | Fewer chunks loaded per player |
| simulation-distance | 10 | 4-5 | Fewer chunks actively ticked |
Set these in server.properties. Keep view distance a few chunks higher than simulation distance so players can see further than the server ticks. For a complete breakdown, see our best server settings guide.
Use Paper or Purpur
This matters more for chunk loading than almost any other performance concern. Paper moves chunk loading and generation to separate threads (async chunk loading), meaning chunk work no longer blocks the main game thread as heavily. Vanilla and Spigot do all chunk work on the main thread.
Switching from Spigot to Paper can dramatically reduce chunk-related TPS drops without changing a single setting. See our server software comparison for migration details.
Paper Chunk Settings
In paper-world-defaults.yml, these settings directly affect chunk performance:
chunks:
max-auto-save-chunks-per-tick: 8
delay-chunk-unloads-by: 10s
- max-auto-save-chunks-per-tick: Limits how many chunks are saved per tick during autosaves. Lower values spread disk writes over more ticks, preventing autosave lag spikes.
- delay-chunk-unloads-by: Keeps recently unloaded chunks in memory briefly. If a player backtracks, the chunk doesn't need to be reloaded from disk.
Hardware and Hosting Considerations
CPU
Chunk generation is CPU-bound. A faster single-core CPU generates chunks quicker, leaving more headroom in the tick budget. If your server constantly generates new terrain (exploration servers, SMP with active players), CPU matters more than anything else. See our CPU guide for what to look for.
Storage
The difference between storage types for chunk loading:
- HDD: Slow seek times, noticeable delays loading saved chunks, autosave lag spikes
- SATA SSD: Fast enough for most servers, eliminates mechanical delays
- NVMe SSD: Best performance, handles heavy chunk I/O without breaking a sweat
If your server runs on an HDD and you're experiencing chunk lag, upgrading to an SSD is one of the most impactful hardware changes you can make.
RAM
RAM doesn't directly affect chunk generation speed, but having enough RAM means the server can keep more chunks cached in memory instead of reading them from disk repeatedly. If your server is constantly loading and unloading the same chunks, more RAM helps. See our RAM guide for allocation recommendations.
Quick Fixes for Common Scenarios
| Problem | Fix |
|---|---|
| Lag when players teleport | Pre-generate around all warp/teleport destinations |
| Lag when new players join | Pre-generate a large area around spawn |
| Lag during elytra flight | Lower view distance to 6-7, pre-generate travel corridors |
| Lag when exploring new areas | Pre-generate a large radius, set a world border |
| Lag spikes every few minutes | Lower max-auto-save-chunks-per-tick, upgrade to SSD |
| Lag with many players spread out | Lower simulation distance, use Paper for async chunks |
For entity-related lag (mobs, items, villagers), see our entity lag guide. For a broader optimization approach, check our performance plugins guide.
Looking for hosting with NVMe storage and CPUs built for Minecraft? Check out Minecraft Server Hosting with hardware optimized for smooth chunk loading and lag-free gameplay.
Frequently Asked Questions
What is chunk loading lag?
Chunk loading lag happens when the server can't load or generate chunks fast enough to keep up with player movement. It causes TPS drops, rubber-banding, and visible delays as terrain appears. It's most noticeable during teleportation, elytra flight, or when multiple players explore in different directions.
Does pre-generating chunks fix lag?
Pre-generation eliminates generation lag for any area that's been pre-generated. Loading a saved chunk is dramatically faster than generating a new one. It's the single most effective fix for chunk-related lag on most servers.
How much of my world should I pre-generate?
A radius of 3,000-5,000 blocks covers most casual SMP servers. Exploration-heavy servers or larger communities may want 8,000-10,000 blocks. Consider setting a world border at your pre-generated radius to prevent players from hitting live generation.
Does view distance affect chunk loading lag?
Yes, significantly. View distance determines how many chunks each player needs loaded. Reducing from 10 to 8 cuts the loaded chunks per player by about 35%. This is one of the easiest and most impactful changes you can make.
Will an SSD fix chunk loading lag?
An SSD fixes lag caused by slow disk reads when loading saved chunks and lag spikes during autosaves. It won't fix lag from generating new chunks, which is CPU-bound. If your server is on an HDD, upgrading to an SSD helps with loading, but pre-generation is still needed for generation lag.
Does Paper handle chunk loading better than Spigot?
Yes. Paper moves chunk loading and generation to separate threads, so chunk work doesn't block the main game loop as directly. This is one of the biggest reasons to use Paper over Spigot for servers where chunk loading is a concern.
