How to Optimize Chunk Loading on Your Minecraft Server

How Chunk Loading Works

The Minecraft world is divided into 16x16 block columns called chunks. Each chunk extends from the bottom of the world (Y -64 in modern versions) to the build limit (Y 320) and is further divided into 16-block-tall sub-chunk sections. The server only keeps a limited number of chunks loaded in memory at any time, specifically, the chunks within each player's view distance plus a buffer zone for entity processing.

When a player moves into new territory, the server has to either load existing chunks from disk (if the area has been visited before) or generate brand-new chunks (if it has not). Both operations are expensive. Chunk generation involves running the terrain generator, populating structures, applying biome features, and lighting calculations. Chunk loading from disk means reading region files, decompressing NBT data, and parsing entities and tile entities. On a busy server with many players exploring simultaneously, chunk operations can easily become the dominant source of lag.

Paper's Async Chunk System

Paper introduced asynchronous chunk loading several years ago, and it has been refined significantly over time. In vanilla Minecraft and Spigot, chunk loading happens on the main server thread, the same thread that processes ticks, handles player actions, and updates entities. If a chunk takes 15 ms to load, that is 15 ms stolen from the tick budget (50 ms for 20 TPS). Load three chunks in one tick and you have already blown your budget.

Paper moves chunk loading and generation off the main thread. When a chunk needs to be loaded, Paper queues the I/O operation on a separate thread pool, and the chunk is integrated into the world once it is ready. This means chunk loading no longer directly causes TPS drops. The main thread keeps ticking smoothly while disk I/O happens in the background.

Paper 1.21+ includes an experimental rewritten chunk system (the "Moonrise" chunk system) that further improves parallelism and reduces the overhead of chunk management. If you are on a recent Paper build, you benefit from this automatically.

Key Configuration Settings

Paper exposes several chunk-related settings that let you tune the balance between loading speed and server load. These live in config/paper-world-defaults.yml (or per-world overrides):

chunk-loading.autoconfig-send-distance

When set to true (the default), Paper automatically calculates the optimal send distance based on your configured view distance. This usually results in a send distance slightly lower than the view distance, which reduces bandwidth without noticeably affecting the player experience. If you set this to false, you can manually specify the send distance.

chunk-loading.max-concurrent-sends

Controls how many chunks the server sends to a player per tick. A higher value means players see chunks load faster when they teleport or first join, but it increases bandwidth usage and can cause lag spikes on slower connections. The default of 2 is conservative. If your server has good network throughput and players complain about slow chunk loading after teleporting, try 4-6.

max-auto-save-chunks-per-tick

Limits how many chunks are saved to disk per tick during auto-save. A high value causes periodic lag spikes every time the auto-save fires (default interval is 6000 ticks / 5 minutes). Setting this to 8-12 spreads the save load across more ticks, reducing spikes at the cost of slightly longer total save time. This is one of the most impactful performance settings for servers with large loaded areas.

Pre-Generation with Chunky

The single most effective optimization for chunk loading is not loading chunks at all, it is having them already generated. Chunky is a plugin that pre-generates chunks in a configured radius around spawn (or any point). Once chunks are pre-generated, players exploring that area only need to load them from disk (fast) instead of generating them from scratch (slow).

# Install Chunky (drop jar in plugins/, restart)

# Set the world and radius (in blocks)
/chunky world world
/chunky radius 5000
/chunky shape circle

# Start pre-generation
/chunky start

# Monitor progress
/chunky progress

# Pause if needed (resumes where it left off)
/chunky pause

Pre-generating a 5000-block radius generates roughly 300,000 chunks and can take several hours depending on your hardware. Run it before your server opens to players, ideally overnight. The generated chunks are stored in region files on disk, so this is a one-time cost unless you reset the world.

For new servers, pre-generation is close to mandatory. Without it, the first few players to explore the world will cause constant chunk generation lag that affects everyone. With it, the world feels snappy from day one.

Storage Performance, NVMe vs SSD vs HDD

Chunk loading is fundamentally an I/O operation. The server reads region files from disk, decompresses them, and loads the data into memory. The speed of your storage directly affects how fast this happens:

Storage Type	Sequential Read	Random Read (4K)	Chunk Loading Impact
HDD (7200 RPM)	~150 MB/s	~0.5 MB/s	Severe lag during exploration
SATA SSD	~550 MB/s	~40 MB/s	Acceptable for most servers
NVMe SSD	~3500 MB/s	~500 MB/s	Nearly instant chunk loads

The critical metric is random read performance, not sequential. Region files are read in small chunks from different locations on disk, making random I/O the bottleneck. An NVMe drive handles random reads roughly 1000x faster than a hard drive. If your server runs on an HDD, upgrading to an SSD or NVMe is the single biggest performance improvement you can make for chunk loading.

Region File Format

Understanding the region file format helps you troubleshoot chunk issues. Minecraft stores chunks in region files (.mca files) inside the region/ folder of each world. Each region file contains 32x32 chunks (a 512x512 block area). The file format uses a header that maps chunk coordinates to byte offsets within the file, allowing the server to seek directly to any chunk without reading the entire file.

Corrupted region files (from crashes or disk failures) can cause specific areas of the world to fail to load. If players report a specific area causing crashes, you can use tools like MCA Selector (a standalone Java app) to inspect, repair, or delete individual chunks within a region file.

Entity Loading as a Separate Cost

When a chunk loads, entities (mobs, item frames, armor stands, dropped items) are loaded separately from the terrain. On servers with high entity counts, mob farms, large builds with many item frames, areas where players have dropped items, entity loading can be more expensive than the terrain itself. Paper's entity-per-chunk-save-limit setting caps how many entities of each type are saved per chunk, preventing pathological cases where one chunk has 500 chickens in it.

View Distance vs Send Distance

In Paper, view-distance controls how many chunks around each player are fully ticked (entities update, redstone fires, crops grow). send-distance (or simulation-distance in newer versions) controls how many chunks are visible to the client but not fully ticked. This lets you give players a large visible horizon without the processing cost of ticking all those chunks.

A common configuration for medium-sized servers:

# server.properties
view-distance=7

# paper-world-defaults.yml
simulation-distance: 5

Players see 7 chunks in every direction but only the closest 5 are fully simulated. This reduces ticking load by roughly 50% compared to ticking all 7 chunks, with minimal noticeable impact for players.

For broader performance tuning beyond chunk loading, see our complete optimization guide and RAM usage guide. If you are still on Spigot, consider switching to Paper for the async chunk system alone.

Need better performance? Astroworld Hosting runs NVMe SSD, up to 96 GB RAM, and DDoS protection on every plan. See features , plans from €6.39/mo.