Minecraft View Distance vs Simulation Distance: What Should You Change?

View distance controls how far the server sends world data around a player. Simulation distance controls the nearby area in which normal entity simulation runs. Lowering either can reduce some server work, but they affect different parts of the experience. A good setting preserves the gameplay your community needs while keeping tick time and resource use within budget.

What changes when you lower each distance?

Distances are measured in chunks around the player
Setting	Primary effect	What players should check
View distance	How much surrounding terrain the server supplies	Visible landscape, travel and chunk delivery
Simulation distance	How far nearby simulation remains active	Farms, mobs and activity away from the player
Client render distance	What the client asks to display within available data	Client performance and visible terrain; it cannot force the server to supply more

Loaded, visible and ticking are not synonyms. Tickets, spawn behavior, other players and extensions can keep areas active for other reasons. A distance setting is not a complete count of loaded chunks or a guarantee about every farm mechanic.

Where should you change the settings?

For a conventional Java server, start with server.properties. Paper also reads relevant per-world defaults and overrides in spigot.yml. Its documented default or -1 inheritance values defer to server.properties. Check the configuration generated by your exact build and any plugin that adjusts player distances before concluding that a change did not work.

# Example experiment, not a universal recommendation
view-distance=8
simulation-distance=6

Back up the configuration, stop cleanly, edit the effective settings and start again. A hosting panel may regenerate properties from its own settings; use that control if it owns the file. Do not paste an entire YAML file from a different release over your current configuration.

How do you choose values for your world?

Record the current effective distances and the problem: slow ticks, slow chunk delivery, memory pressure or client frame rate.
Measure a busy period with representative activity. Record player positions and whether they explore new terrain or remain together.
Change one setting by a modest amount. Keep the other settings, workload and software unchanged as far as practical.
Repeat the observation. Check tick-time spikes, memory use, travel and the farms players rely on.
Keep the change only if the benefit is useful and the gameplay tradeoff is acceptable; otherwise restore the previous configuration.

Use TPS and MSPT to tell sustained tick overload from a short stall. If a profile points to an unrelated plugin task, lowering distances may hide only part of the symptom. If only one player has poor frame rate while server ticks are healthy, investigate that client separately.

Why can a small distance change have a noticeable effect?

As a simplified geometric illustration, a square of radius 10 contains (2 × 10 + 1)² = 441 cells, while radius 8 gives 289. These are illustrative areas, not measured chunk counts or a predicted percentage speedup. Real loading and ticking rules differ, and nearby players can share much of the same area.

That overlap matters when planning tests. Ten players standing in one town and ten players exploring far apart do not create the same demand. Keep the distribution of players in your notes rather than comparing only the online count.

Why did a distant farm stop working after the change?

First reproduce the behavior with a player near the farm and then farther away. Restore the previous simulation setting on a test copy and repeat. Check the farm’s version-specific requirements, any chunk-loading mechanism and the presence of other players. Do not compensate by increasing every distance until the server runs out of headroom.

If the required gameplay still exceeds available capacity after profiling, bring those measurements to a Minecraft hosting comparison. The RAM guide helps determine whether memory is actually the remaining constraint.