I spent an entire weekend dragging my render distance down to nearly nothing, convinced that was the fix for the tick lag ruining my survival world. Chunks loaded in tighter, the world looked worse, and the lag barely improved. The actual fix, when I finally found it, wasn’t a visual setting at all — it was a completely separate slider I’d never touched called simulation distance, and it turned out to be doing almost all the damage.
Most lag advice treats “lower your settings” as one instruction, but render distance and simulation distance are two different systems handling two different jobs, and one of them matters a lot more than the other for actual gameplay lag.
Render distance and simulation distance aren’t the same setting
Render distance is client-side. It controls how many chunks load around you visually — how far you can see — and it affects your frame rate, RAM usage, and how much data gets sent over the network in multiplayer. This is the setting most players reach for first because it’s the one that visibly changes what’s on screen.
Simulation distance is a separate, newer setting that controls something you can’t see directly: the radius around each player in which the game actively processes mobs, minecarts, items, redstone contraptions, and fluids like water and lava. Anything outside that radius simply freezes in place until a player gets close enough again. This distinction matters because simulation distance is doing the expensive computational work, while render distance is mostly doing the expensive visual work — and tick lag, the stuttery, world-wide slowdown that makes everything feel sluggish, comes overwhelmingly from the simulation side, not the rendering side.
Why simulation distance causes more lag than render distance
A high simulation distance is one of the most common causes of real tick lag, because every redstone circuit, every mob, every block of flowing water inside that radius needs to be recalculated on every game tick, 20 times a second. Render distance just decides what gets drawn to your screen — it doesn’t force the game to run physics and AI calculations on everything within it.
This is also why running both settings at the same high number is wasteful: you end up paying the full simulation cost across an area as large as your render distance, when a much smaller simulation radius would deliver almost the same gameplay experience with a fraction of the tick load. Keeping simulation distance lower than render distance is the actual optimization move, not lowering both equally.
The other major lag source render distance does nothing about: entity cramming
If you’ve built an AFK mob farm, or you play near a village, or you’ve got a large animal pen, there’s a second lag source that has nothing to do with either distance setting: too many entities stacked in one place. Mobs, dropped items, and minecarts all get updated every tick, and overcrowding — especially in mob farms designed to pile dozens of mobs into a small space — puts a heavy, concentrated load on the game regardless of how far you can see or how large your simulation radius is.
This is the lag source people usually misdiagnose as a render distance or general “my PC is bad” problem, because it’s invisible in a settings menu. It shows up specifically near farms, spawners, and anywhere entities pile up, and it doesn’t respond to graphics settings at all.
How to actually diagnose which one is hurting you
1. Open your F3 debug screen and watch the numbers, not just the FPS counter
The F3 screen shows more than frame rate — it can point to whether you’re rendering-bound (low FPS, high chunk counts) or tick-bound (fine FPS, but the world itself feels sluggish, laggy movement, delayed redstone or mob behavior).
2. If the world feels sluggish but your FPS looks normal, it’s simulation-side
Stuttery redstone, delayed mob movement, or general world sluggishness despite a healthy frame rate is the signature of tick lag from simulation distance or entity overload, not a rendering problem. Lowering render distance in this case won’t help much, because it isn’t the bottleneck.
3. If it’s specifically near a farm or crowded area, it’s entity cramming
Lag that’s localized to specific spots — near a mob farm, a village, or an animal pen — rather than happening everywhere in the world points at entity count in that specific area, not a global settings problem.
What to actually change, in order
Start with simulation distance before touching render distance, since it’s doing the heavier computational work per chunk. A simulation distance in the 4-6 chunk range is usually enough to keep nearby redstone and mob behavior responsive without simulating a huge radius most players never fully load. Keep render distance separately at whatever level your hardware handles visually — there’s no need to force it to match your simulation distance.
If your lag is specifically tied to farms or crowded areas rather than the whole world, address the entity count directly instead of touching either distance setting: reduce farm capacity, clear excess mobs periodically, or design farms with kill mechanisms that prevent large entity buildups in the first place. No amount of render or simulation distance tuning fixes lag that’s actually coming from raw entity count in one spot.
Why this got more confusing after Java 1.18
Simulation distance didn’t always exist as its own setting. Before it was split out, view distance handled both what loaded visually and what got simulated at the same time, so lowering one number fixed both problems at once, more or less. Since the split, a lot of older lag-fixing advice still floating around only talks about render or view distance, because that used to be the only lever available. That’s part of why so many players still reach for render distance first when troubleshooting lag today — the advice hasn’t caught up to the fact that there’s now a dedicated setting doing the heavier lifting.
If you’re following an older guide and it only mentions one distance setting, it’s worth checking your current version’s options menu for simulation distance specifically, since it may not be covered by advice written before the two settings existed separately.
Multiplayer server owners have an extra reason to care about this distinction: simulation distance affects every player on the server simultaneously, since the game has to track the union of all active players’ simulation radii. A server with ten players all running a high simulation distance is doing dramatically more per-tick work than a single-player world ever would, which is why dedicated server hosts frequently recommend keeping simulation distance conservative even when the hardware could technically support a higher render distance for visuals.
FAQ
Should I lower render distance or simulation distance first to fix lag?
Simulation distance first. It controls the more computationally expensive work — mob AI, redstone, and fluid updates — while render distance mostly affects what’s visually drawn. A high simulation distance is one of the most common causes of real tick lag.
What’s a good simulation distance to avoid lag without ruining gameplay?
Somewhere around 4-6 chunks works well for most single-player and small multiplayer setups, keeping nearby mechanics responsive while avoiding the cost of simulating a much larger area than you actually need active at once.
My FPS is fine but the game still feels laggy — what’s causing that?
That’s usually tick lag rather than a rendering problem, caused by simulation distance being too high or too many entities being processed in one area, like an overcrowded mob farm. Lowering render distance won’t fix this, since render distance isn’t the bottleneck in that scenario.
