The server.properties settings that change how Minecraft plays

Most server.properties guides are a transcription of the file with the default repeated back at you. That is not useful, because the file is already self-documenting and the question nobody answers is which lines change what players experience and which ones are folklore.

There are about sixty entries. Six of them decide how the server feels. The rest are either a switch you already know you want or a number you should leave alone.

The four that cost CPU

view-distance defaults to 10 and simulation-distance also defaults to 10, per the Minecraft Wiki's server.properties reference. Almost everyone treats these as one setting. They are not, and splitting them is the cheapest performance work available on a survival server.

View distance is how far chunks are sent to the client. Simulation distance is how far the server keeps ticking entities, redstone, crop growth and mob AI. A player standing on a hill wants to see a long way. Nothing about that requires zombies to be pathfinding four hundred blocks behind them.

Dropping simulation to 6 while leaving view at 10 gives you the view people notice and removes most of the work they do not. Dropping both to 6 gives you a claustrophobic server that also runs well, which is a worse trade than it sounds.

max-tick-time defaults to 60000 (sixty seconds). It is a watchdog: if a single tick takes longer than that, the server shuts itself down and writes a crash report naming the plugin that hung. Setting it to -1 disables the watchdog, and every forum post recommending that is telling you to silence the alarm rather than find the fire. Leave it. If it is firing, read the crash diagnosis guide instead.

network-compression-threshold defaults to 256 bytes. Packets larger than that are compressed. On a box where CPU is the constraint and bandwidth is not (which is almost every rented server), raising it to 512 trades a little bandwidth for a little CPU. On a home connection behind CGNAT or a thin uplink, leave it alone or lower it.

The two that decide whether you lose the world

sync-chunk-writes defaults to true. It forces chunk writes to complete before the server continues. On a machine with a real SSD the cost is small and the protection is real: an unclean shutdown mid-write is how a world ends up with a corrupted region file. On network storage it can stall the main thread badly enough to be worth turning off, and that is the one case where false is defensible: provided you have backups you have actually restored from.

The second is not a setting at all. It is that server.properties is read once, at boot. Editing it on a running server does nothing and then confuses you an hour later when the change has not taken.

The one that is a security setting wearing a performance costume

max-players is not a performance control, though it is used as one constantly. Lowering it does not make the server faster; it makes the server refuse people. The work a server does scales with the players who are actually on it and the chunks they are actually loading, so a 200-slot server with eleven players costs exactly what an eleven-slot server with eleven players costs.

What max-players does change is how the server reads to somebody scrolling a list. Eleven players in 200 slots reads as abandoned. Eleven in twenty reads as a small server having a quiet evening. Same eleven people, same machine, entirely different first impression, and that impression is most of what decides whether a stranger clicks, which is the argument a listing has to win in about two seconds.

Set it near your realistic peak plus a margin. Not near your ambition.

The ones that are not performance settings pretending to be

spawn-protection defaults to 16 blocks and stops non-operators building near spawn. People raise it to 100 to prevent griefing and then wonder why new players cannot place a single block anywhere near where they arrive. The first thing a player does is try to interact with the world; a large protection radius means their first action fails silently. That is a retention problem wearing a security costume, and it belongs in the same conversation as what the first ten minutes look like.

difficulty and hardcore are game design, not tuning. online-mode is a security setting, and setting it to false on a public server means anyone can connect as any username. If you are running behind a proxy that is already correct; if you are not, it is an open door.

The settings worth an evening

Set simulation distance below view distance. Leave the watchdog on. Decide sync-chunk-writes based on what your disk is, not what a video said. Then stop touching the file, because the next hour of tuning is worth less than the first hour of watching what the server actually does under load.