Which Paper setting delivers the most?

Usually simulation-distance. It determines in how many chunks the world is actually ticked and weighs far more heavily than view-distance. A lower simulation-distance with a generous view-distance keeps the view nice while the server does less work.

What is the difference between view-distance and simulation-distance?

View-distance determines how many chunks players see, simulation-distance in how many chunks mobs move, crops grow and machines tick. Simulating is far heavier than showing, so the latter has the biggest impact on performance.

Are 'optimized' Paper configs from the internet safe?

Be careful with them. They're often written for older versions and change dozens of settings at once, which makes mob spawns, farms and redstone behave differently. At most, deliberately adopt individual values and measure the effect with spark.

How do I measure where the lag on my server comes from?

With spark, which ships with recent Paper versions by default. The command /spark tps shows TPS and MSPT, /spark profiler shows which tasks or plugins are eating the time. Measure at a busy moment, before you change any settings.

// Minecraft

Paper config tuning: settings that actually improve performance

24 August 2026 · 4 min read

Not a week goes by without someone in some Discord sharing an "optimized Paper config" that will supposedly make your server "twice as fast". The reality: Paper's default settings are already pretty good, most of the gains sit in a handful of knobs, and the rest of such a magic config mainly changes how your server plays — not how fast it is. Hence this article: which settings actually deliver performance, which file they live in, and why you measure first before turning anything.

Measure first, then tweak

Tuning without measuring is guessing. Fortunately, measuring is easy these days: recent Paper versions ship with the profiler spark out of the box. With /spark tps you see TPS and MSPT at a glance, and with /spark profiler you start a measurement that shows where the time is going: entities, hoppers, world generation or that one plugin. The older timings reports are being phased out; spark is the successor.

An important distinction here: low FPS on a player's screen is client lag and won't be fixed with server configs. Only when the TPS drops below 20 or the MSPT structurally creeps towards 50 is your server actually struggling. Also measure at a representative moment — a busy evening, not an empty Tuesday morning — and keep that measurement. Only then can you see whether a change actually achieved anything.

The config layers at a glance

Paper builds on Spigot, which in turn builds on Bukkit and vanilla. Each layer has its own file:

File	What lives there
`server.properties`	The vanilla basics: view-distance, simulation-distance, max-players, world settings
`bukkit.yml`	Spawn limits per mob category, autosave interval
`spigot.yml`	Entity activation range, mob-spawn-range, hopper ticks, merge radius
`config/paper-global.yml`	Server-wide Paper settings, such as the chunk system
`config/paper-world-defaults.yml`	Per-world Paper settings: hopper behaviour, spawn tweaks and much more

Good to know: settings from paper-world-defaults.yml can be overridden per world with the file paper-world.yml in that world's folder.

The knobs that actually do something

view-distance and simulation-distance

The biggest lever, both in server.properties. View-distance determines how many chunks a player gets to see; simulation-distance determines in how many chunks the world actually lives: mobs move, crops grow, machines tick. Simulating is far more expensive than showing. Hence the classic trick: keep view-distance generous (8 to 10) and set simulation-distance lower (5 to 7 on a busy server). Players see a distant horizon, while your server only has to tick a fraction of those chunks. How to change the view distance is in the knowledge base: adjusting your view distance.

Mob spawns

The spawn-limits in bukkit.yml determine how many mobs per category may exist around players; monsters defaults to 70. On a busy server you can step that down gradually. In spigot.yml, mob-spawn-range should stay in balance with your simulation-distance, and Paper spreads spawns fairly across players by default, so one AFK player at a farm doesn't swallow all the spawns. But beware: cutting too aggressively shows up immediately in gameplay — empty nights, farms grinding to a halt, angry players. Small steps, then.

Hoppers

Large sorting systems and farms with thousands of hoppers can seriously weigh on your tick time. In spigot.yml, ticks-per.hopper-transfer and ticks-per.hopper-check determine how often hoppers do their work; raising them a little makes a noticeable difference, but does change the timing of existing farms and sorting machines. In paper-world-defaults.yml you can additionally give full hoppers a rest with cooldown-when-full. Measure first whether hoppers are even your problem before touching anything here.

Chunk loading

Generating new chunks is one of the heaviest tasks a server knows. Paper has knobs for the chunk system in paper-global.yml, but the honest advice is: stay away from them unless a measurement points you there and you know what you're doing — the defaults are well chosen. You'll gain more from a world border and pre-generating chunks (see further reading), and from fast storage: loading chunks from NVMe is something you simply notice in game.

Sane defaults per server type

Small survival server (2 to 10 players): leave almost everything at default. The Paper defaults are amply sized for this; if it still stutters, that's more likely one extreme farm, a heavy plugin or too little RAM than your config. Sinking hours into tuning rarely pays off here.

Busy community server (20+ players): use this as a starting point, not as dogma:

view-distance 8 and simulation-distance 6;
spawn-limits.monsters stepped down gradually from 70;
mob-spawn-range in line with your simulation-distance;
hopper settings only if spark points at hoppers.

Apply changes one at a time and measure at least one busy evening after each step. Otherwise you'll never know which knob made the difference — or which knob broke something.

Beware of "magic configs" from the internet

About those ready-made optimization configs doing the rounds everywhere: be sparing with them. They're often written for older versions, flip dozens of settings at once and mostly cut behaviour away: fewer mob spawns, different redstone timing, farms that quietly stop working. If your server gets faster, you don't know which of the forty lines did it; if something breaks, you don't either. If you still want to use one: put it next to the default values, only adopt deliberately what you understand and change things in small steps. The Paper defaults were written by the people who build the server software themselves; "everything different" is rarely an improvement.

When tuning isn't enough

The honest story to finish: a config can't conjure up hardware. Too little RAM for your player count, a pile of heavy plugins or slow storage won't be fixed with YAML. If spark points towards memory pressure or slow chunk storage, a bigger plan is simply the better investment. At MC-Node every Minecraft server runs on our own hardware with NVMe storage — a noticeable difference for chunks in particular — from €0.50 per month, at around €1.10 per GB of RAM. Everything can be cancelled monthly, so trying a size up and scaling back down if it turns out to be overkill is perfectly fine.