Is your Paper server stuttering? This guide shows you how to find the cause and fix it deliberately – instead of blindly changing values. For simply looking up what a config option means, see the reference article Paper configuration explained.

Understanding TPS and MSPT

  • TPS (Ticks per Second): how often the server calculates the world per second. 20 = target. From 19 it's noticeable, below 15 it's critical.
  • MSPT (Milliseconds per Tick): how long one tick takes. This is the more meaningful number. At 20 TPS you have 50 ms per tick – target: consistently under 50 ms, ideally under 35 ms.

Measure TPS/MSPT with /tps, /mspt and – most informative – the Spark plugin.

Diagnose first, then configure

This is the most important section. First measure where the time goes – don't guess.

  1. Install Spark (plugin)
  2. Start the profiler: /spark profiler start, let it run under load for a few minutes
  3. Stop with /spark profiler stop – you get a link with a detailed report
  4. Read off which systems eat the time (entities, chunks, redstone, plugins, hoppers)
  5. For sudden stutters: /spark tickmonitor shows lag spikes
  6. Alternatively: the classic timings report
Important
Rule of thumb: Config tuning gains 2–5 TPS – one broken plugin costs 15. Tweaking the config without diagnosis often optimizes the wrong thing.

Lag causes by category

CategoryTypical cause
Memory / JVMToo little RAM or missing/wrong JVM flags (Aikar's Flags)
Java versionWrong Java version for the Minecraft version
View distanceview-distance / simulation-distance too high
EntitiesMob farms, dropped items lying around, boats/minecarts in bulk
ChunksPlayers constantly generating new chunks with Elytra
RedstoneRedstone clocks, long hopper chains
PluginsToo many or badly written plugins
HardwareHDD instead of SSD, oversold/shared hardware
NetworkNetwork lag ≠ server lag: high ping with good TPS = network, not the server
Info
Ping and TPS are two different things. A high ping with stable 20 TPS is a connection problem (routing, Wi-Fi, distance) – not server lag.

Concrete config recommendations

The following levers tend to help most. For each: what it costs in gameplay – stated honestly. The full explanation of every key is in the reference article.

Setting (file)RecommendationGameplay cost
view-distance / simulation-distance (server.properties)Match to player count, e.g. view 8, simulation 6Slightly shorter view; barely noticeable
redstone-implementation (paper)ALTERNATE_CURRENTNone – faster, compatible redstone engine
per-player-mob-spawns (paper)trueNone noticeable; fairer mob distribution
tick-rates.behavior.villager / sensor.villager (paper)Increase the values (tick less often)Villagers react slightly slower
max-auto-save-chunks-per-tick (paper)Lower itSaving spreads out; slightly higher data-loss risk on a crash
despawn-ranges (paper)ReduceMobs despawn a bit sooner in the distance
entity-activation-range (spigot.yml)Lower per mob typeDistant mobs "sleep" sooner; mind your farms
merge-radius (spigot.yml)Increase for items/XP orbsDrops/orbs merge more generously
max-entity-collisions (paper)Lower (e.g. 2)Less push physics with mob crowds
hopper.disable-move-event (paper)true⚠️ Can break hopper-dependent plugins
Caution
hopper.disable-move-event: true saves noticeable performance but suppresses the InventoryMoveItemEvent. Plugins that react to hopper movement (some shop/sorting plugins) will stop working. Check first.

JVM & hardware

  • Use Aikar's Flags – but understand them, don't just slap them on: they tune the G1 garbage collector so that lag spikes from GC pauses are minimized. The full flag set is in Optimizing Minecraft server performance.
  • RAM: more is not automatically better. Too much heap lengthens GC pauses. Allocate as much as the server realistically needs (-Xms = -Xmx).
  • CPU: Minecraft is mostly single-threaded – the main tick runs on one core. Single-core performance beats core count. A fast 4-core beats a slow 16-core.
  • Pick the Java version to match the Minecraft version (current versions need Java 21).
Tip
On shared/oversold hardware, no config trick helps if the CPU power simply isn't there. A server with guaranteed, strong single-core performance is the foundation – it's worth looking at a more powerful game server.

Plugin hygiene

  • When suspicious: disable plugins one by one and watch the TPS to pin down the culprit
  • Typical performance hogs: Dynmap (rendering), heavy protection/world-management plugins
  • Spark is a must for diagnosis; judge ClearLag & co. critically – they often just mask symptoms
  • Beware "optimization" plugins that noticeably add load themselves

What does NOT help

  • Blindly raising RAM – past a point, more heap actually hurts through longer GC pauses
  • Copying random configs from YouTube videos – often outdated, for other versions, or applied blindly
  • A chunk cleaner as a permanent solution – it fights symptoms, not the cause; better find the source of the entities

Quick checklist

  1. Measure with /spark profiler – don't guess
  2. Rule out plugins (disable one by one)
  3. Java 21 + Aikar's Flags, -Xms = -Xmx
  4. Match view-/simulation-distance to player count
  5. redstone-implementation: ALTERNATE_CURRENT, per-player-mob-spawns: true
  6. Villager tick rates up, max-auto-save-chunks-per-tick down, despawn-ranges down
  7. Only then think about fine-tuning

Where to next

Frequently asked questions

What is the difference between TPS and MSPT?

TPS counts how many ticks the server completes per second – the target is 20. MSPT measures how long a single tick takes; consistently above 50 ms means the server can no longer keep up.

How do I find out what makes my Paper server lag?

With the spark plugin: /spark profiler start, wait a few minutes, /spark profiler stop – the report shows which entities, plugins or systems consume the tick time. Measure first, configure second.

Which settings help most against lag?

View distance and simulation distance have the biggest effect, followed by entity limits and activation ranges. Blanket numbers without measuring achieve little – the recommendations in this article are the starting point, spark is the proof.

Is switching from Spigot to Paper really worth it?

Yes — Paper is noticeably faster than Spigot and vanilla while staying compatible with almost all plugins. For most servers it is the single easiest performance win.

Do ready-made "optimization configs" from the internet help?

Only partially: many circulating configs are outdated or built for different server profiles and needlessly degrade game mechanics. Measure your own lag causes and change only the values that matter.

How many plugins are too many?

There is no fixed number – a single badly written plugin does more damage than ten clean ones. The spark report decides: whatever consistently eats tick time gets removed or replaced.