If your Minecraft server stutters when players sprint across the map, if mobs freeze in place, or if TPS sags the moment someone loads new terrain, the two settings most often responsible are view distance and simulation distance. They sit right next to each other in server.properties, they sound nearly identical, and yet they govern completely different parts of the game loop. Confusing them is one of the most common reasons a server either lags constantly or feels broken even while running at a comfortable 20 TPS.

This guide exists to help. I run Paper, Purpur, and vanilla servers for survival SMPs, creative plot worlds, and multi-world networks, and I have spent many hours watching Spark reports shift as these two numbers moved up and down. The recommendations below come from that hands-on testing plus the official Paper and Minecraft documentation, so you can tune your own server with evidence instead of guesswork.

By the end you will know exactly what each distance controls, where to set it, which values fit your server type, how to measure the results with TPS, MSPT, and Spark, and how these settings interact with pre-generation and chunk loading. Keep your server’s play style in mind as you read, because what works for a 20-player survival world is not what works for a 500-player network.

The Core Difference: View Distance vs Simulation Distance

Here is the sentence that matters most: view distance controls which chunks are sent to the player’s client, while simulation distance controls which chunks the server actually ticks. They are independent values, and one is not required to match the other. Grasping that split is the key to cutting chunk lag for real instead of shuffling the same problem around.

What View Distance Really Controls

View distance is the radius, in chunks, of the world the server streams to each connected client. A view distance of 10 means the server prepares and sends the chunks within a 10-chunk radius around the player, roughly a 21 by 21 grid of terrain. It is fundamentally about network and client load: how far a player can see, how much terrain the client renders, and how many chunk packets the server has to encode and push down the pipe as players move.

• Radius in chunks of terrain streamed to the client
• Drives bandwidth, packet encoding, and client GPU load
• Decides how far players can visually see the world
• Has no direct effect on mob AI, redstone, or random ticks

What Simulation Distance Really Controls

Simulation distance is the radius, in chunks, of the world the server keeps fully loaded and ticked around each player. Inside this radius the full game simulation runs: mob AI, spawning and despawning, pathfinding, random block ticks like crop growth and leaf decay, redstone updates, fluid flow, and hopper transfers. Outside it, chunks can still exist on disk and even remain visible, but they are effectively frozen.

• Radius in chunks that receive full game ticks
• Governs mob AI, spawning, and despawn mechanics
• Runs random ticks such as crops, saplings, ice, and fire spread
• Processes redstone, fluids, hoppers, and scheduled block updates
• Drives most of the CPU cost of a running world

Why the Confusion Causes Real Damage

Because the two values control different things, tuning the wrong one produces no benefit. Raising view distance on a server with a laggy iron farm increases packet load but leaves the farm’s ticking unchanged. Lowering simulation distance to fix client stutter does nothing for client FPS while quietly freezing distant farms and spawners. Match the setting to the symptom, or you will spend hours chasing a fix that never arrives.

A quick way to remember it: view distance is what the player sees, simulation distance is what the server does. If the problem is visual or network, look at view distance. If the problem is mobs, farms, redstone, or raw CPU, look at simulation distance.

Reference Table: The Two Settings Side by Side

Where These Values Live: server.properties and Paper

Both distances start life in the same place, but Paper gives you far more control than vanilla ever did. Knowing the three layers – the global properties file, per-world overrides, and per-player adjustments – is what separates a server that scales from one that fights its own players.

The server.properties Keys

In a vanilla or Paper server the two keys live in the root server.properties file. Set them explicitly instead of trusting defaults, because defaults change between versions and many packs ship their own.

view-distance=10
simulation-distance=10

Both accept values from 3 to 32. Paper clamps out-of-range numbers, and it never lets simulation distance exceed view distance in a way that would break rendering: if you set simulation higher than view, the extra ticking radius simply does nothing useful because those chunks are not sent to anyone. Keep simulation at or below view distance, always.

Per-World Defaults and Overrides in paper-world-defaults.yml

One global value cannot suit every world. Paper lets you override view distance and simulation distance per world in config/paper-world-defaults.yml. This is how you keep a lobby at a modest distance while a resource world runs lean, all on the same server.

worlds:
  world:
    view-distance: 8
    simulation-distance: 6
  world_nether:
    simulation-distance: 5

The worlds block takes precedence over the global keys for that world. This is the cleanest lever for mixed-purpose servers: your survival overworld can run a generous simulation distance while a minigame or creative world runs a cheap one. Paper documents these values in its world configuration reference.

Per-Player View Distance: The Lever Most Owners Miss

View distance does not have to be a single global number. Paper exposes Player#setViewDistance() in its API, so plugins and performance packs can shrink the send radius for players who do not need it: someone standing in a lobby, watching a cinematic, or running a low-end client. Cutting a handful of players’ view distance reduces the server’s packet encoding work and their own bandwidth without touching world simulation at all.

Player player = event.getPlayer();
player.setViewDistance(6); // send fewer chunks to this client

Use this as a scalpel, not a hammer. Lower a player’s view distance when they are stationary or in a confined area, and restore it when they return to open survival play. Combined with per-world simulation distance, per-player tuning is where large networks find their biggest, cheapest wins.

Recommended Values for Survival, Creative, and Networks

There is no universally correct number, but there are sensible starting points for each server type. These come from tuning real worlds and watching where MSPT and packet load climb. Treat them as baselines and adjust with measurement.

• Start lower than you think you need, then raise until MSPT becomes uncomfortable.
• Keep simulation distance at least two chunks below view distance on busy servers.
• Raise view distance for visual appeal and lower simulation for CPU headroom.
• Use per-world overrides so a heavy world does not drag down a light one.

Balancing Players, Mob Farms, and Redstone

Mob farms and redstone machines are the sharpest test of simulation distance, because they depend on ticks, not on being visible. A spawner 50 chunks away from every player is not ticking, so the farm stops. If your community relies on distant farms, simulation distance is the number that keeps them alive, and it is also the number that costs the most CPU.

• For farm-heavy survival: keep simulation at 6 to 8 and place farms within that radius.
• For redstone engineers: their contraptions must sit inside the simulation radius to fire.
• For casual building servers: simulation of 4 to 5 is usually plenty and much cheaper.
• For minigames: small arenas mean simulation of 3 to 4 delivers full function.

Quick Setup Checklist

1. Record a baseline: run /tps and a Spark profiler during a busy period before changing anything.
2. Lower simulation distance first, since it is the CPU-heavy setting, and re-measure.
3. Adjust view distance for visual quality only after simulation is under control.
4. Add per-world overrides in paper-world-defaults.yml for any world with different needs.
5. Apply per-player view distance for lobbies, cinematics, and low-end clients.
6. Pre-generate the world so chunk loading never competes with chunk generation.
7. Re-run Spark after a week of real traffic and confirm MSPT stayed stable at peak.

Pre-Generation: The Multiplier on Everything

These settings interact directly with chunk loading. Every chunk that enters view distance or simulation distance has to be loaded, and if it has never been generated, the server pays the extra cost of generating it on the spot. That generation work is far more expensive than simply reading an existing chunk from disk, which is why pre-generation changes the performance picture so much. [How to Pre-Generate Your Minecraft World with Chunky] walks through using Chunky to generate terrain ahead of time. Official details live in the Chunky project on GitHub.

The catch is that pre-generation only removes generation cost, not ticking cost. A pre-generated chunk still consumes CPU every tick it stays inside simulation distance. So pre-generating lets you raise view distance more safely, but it does nothing to make an oversized simulation distance cheap. Tune the tick radius on real measurements, and let pre-generation protect the loading side.

Symptoms and How to Measure the Impact

Before you change a single number, learn what each symptom actually points to. The signals below tell you whether you are paying for view distance or simulation distance, which decides which value to touch.

Symptoms of Values Set Too High

• High and spiky MSPT, with tick times climbing whenever players spread out
• Chunk-load lag and rubber-banding as players cross the map
• Increased garbage collection pressure from heavy chunk and packet objects
• Bandwidth and CPU spikes that track player count rather than activity
• TPS that holds at idle but falls the moment many players explore

Symptoms of Values Set Too Low

• Mobs that appear frozen or ignore players just outside the short radius
• Farms and spawners that stop producing when players walk away
• Redstone machines that only work when someone stands on top of them
• Crops, saplings, and other random ticks that seem to stall
• Players seeing terrain pop in or fog closing in too close

Measuring With TPS, MSPT, and Spark

TPS tells you whether the server is keeping up, but MSPT (milliseconds per tick) tells you how much headroom you have left. On Paper, /tps prints recent MSPT alongside TPS, and anything creeping toward 50 milliseconds per tick is your warning line. For real diagnosis, use the Spark profiler to see exactly where the tick time goes.

• Run Spark during peak load, not on an empty server.
• Compare reports before and after each value change, one change at a time.
• Watch MSPT percentiles and the tick loop breakdown, not just the average.
• Confirm the bottleneck is chunk ticking before lowering simulation distance.

If you are new to the tool, [A Beginner’s Guide to Spark Reports] explains how to read the flame graph and spot chunk and entity ticking costs at a glance. You can grab the profiler from the Spark repository, and the Paper documentation covers the recommended startup flags that keep tick times stable. If the profiler shows garbage collection dominating, [ZGC vs G1GC: The Best Java Garbage Collector for Minecraft Servers] covers choosing a collector, while [CPU vs RAM: What Actually Stops Minecraft Lag in 2026?] helps you decide whether CPU or RAM is actually your ceiling.

Pros and Cons of Tuning These Values

Pros of Getting Them Right

• Stable MSPT and TPS even as player count climbs
• Lower bandwidth bills and happier clients on weak hardware
• Farms and redstone that work reliably because they tick
• Headroom to add players, plugins, or worlds without upgrading hardware
• Predictable performance you can actually benchmark and defend

Cons and Cautions

• View distance that is too low makes the world feel cramped and foggy
• Simulation distance that is too low silently breaks distant farms
• Per-player view distance adds moving parts and needs testing
• Aggressive values can change gameplay in ways players notice immediately
• Every world may need its own tuning, which takes time to dial in

Common Mistakes and Expert Tips

• Setting simulation distance above view distance. The extra radius does nothing useful. Keep simulation at or below view distance.
• Copying another server’s numbers. Hardware, player count, and world size differ. Yours should be measured, not borrowed.
• Tuning without a baseline. Change one value at a time and re-profile, or you will never know which change helped.
• Blaming view distance for farm lag. If mobs and redstone break, that is simulation distance, not the send radius.
• Ignoring per-world overrides. A single global value forces compromises that per-world tuning avoids entirely.
• Forgetting pre-generation. Fresh chunk generation is far costlier than loading, and it hides inside your tick times.
• Chasing distance while GC spikes. If Spark shows GC pressure, fix the collector first, then revisit distances.
• Never re-measuring. Player behavior changes after updates and events. Re-profile monthly at least.

The experts’ rule is simple: measure, change one thing, measure again. Distance tuning is one of the highest-leverage levers on any Minecraft server, but only when it is tied to evidence. Pair it with solid JVM startup flags so the tick loop has room to breathe.

Frequently Asked Questions

Conclusion: Tune With Evidence, Not Guesswork

View distance and simulation distance look like twins, but they pull on opposite ends of the game loop: one streams the world to eyes, the other drives it under the hood. Once you internalize that split, cutting chunk lag stops being trial and error. Set simulation distance first because it carries the CPU cost, tune view distance for visual quality after, and lean on per-world overrides and per-player adjustments so one world or one client never dictates the whole server’s limits.

Start where you are: record a baseline with /tps and Spark, lower simulation distance a couple of chunks, re-measure, then adjust view distance and add pre-generation to protect the loading side. Small, measured changes compound into a server that stays smooth at peak.

Ready to go further? Profile your server properly with [A Beginner’s Guide to Spark Reports], pre-generate your world with [How to Pre-Generate Your Minecraft World with Chunky], and if the numbers still will not settle, find out whether [CPU vs RAM: What Actually Stops Minecraft Lag in 2026?] or a better collector such as the options in [ZGC vs G1GC: The Best Java Garbage Collector for Minecraft Servers] is your real bottleneck. Take the checklist above, apply one change at a time, and you will feel the difference the very next session.