If your server feels laggy, the culprit is usually not the internet but low TPS. This guide first helps you tell where the problem actually is, then gets your server smooth again by putting the highest-impact setting first.
What is TPS, and why 20?
TPS (ticks per second) is how many times per second the server updates game logic. The target is 20 TPS — one step of the world every 50 milliseconds. Below 20 the game slows: blocks break late, mobs stutter, commands lag.
You can see live TPS in the panel overview and in the console. 19.5 and above is healthy; below 15 is clearly noticeable in game.
First, separate: server, network or your own PC?
The same complaint can come from three different problems, with completely different fixes:
- Server lag (low TPS) — happens to everyone at once. Blocks break late, mobs teleport. That's the subject of this guide.
- Network lag (ping) — affects only some players. The game is smooth but responses arrive late. Check the ping on the F3 screen; the panel also shows the server's live latency.
- Client FPS drops — one player's screen stutters while everyone else is fine. Nothing to do with the server; it's graphics settings and drivers.
The fastest way to tell them apart: look at the panel's TPS value at the moment the problem happens. Near 20 means the server is fine and the issue is the network or the client.
The most common causes of low TPS
- High view distance — every extra chunk is new area to calculate every tick. This is the most common and biggest cause.
- Entity build-up — huge animal farms, items piling up on the ground, busy mob farms.
- Always-on redstone — clock circuits and large automated machines create work every tick.
- Heavy or conflicting plugins — one badly written plugin can cost more than ten good ones.
- Too many players for the package — RAM and cores have fallen behind the real load.
- Unlimited exploration — as the world grows, so do disk and memory; unbounded exploration is the most insidious long-term load.
Step-by-step optimisation — biggest win first
1. Lower view and simulation distance. In the Settings section, bring "View distance (chunks)" and "Simulation distance (chunks)" down to the 6-8 band. On most servers this single change makes the biggest difference, and players rarely notice. The ceiling for these values follows your package; on smaller packages it's already kept low.
2. Use Paper or Purpur in the plugin family. Moving from Vanilla or Spigot to Paper gives a clear gain from built-in optimisations, and your existing plugins keep working.
3. Limit entities. Keep animal farms reasonable, use a plugin that clears dropped items, and cap the output of mob farms. Lowering the entity broadcast range in Settings also helps in busy moments.
4. Eliminate plugins one at a time. Disable the suspect plugin temporarily and watch TPS. Disable several at once and you won't know which one was responsible.
5. Set a world border. Unlimited exploration inflates both disk and memory; a sensible border keeps the server healthy long term.
Diagnosing from the console
If you see Can't keep up! or Overloaded in the console, the server failed to finish a tick in time. Look at what happened just before those lines: after a world save it points at disk, during a busy moment at player load, right after a specific plugin's message at that plugin.
One-off warnings are normal (during a world save, for instance). Constant repetition means a real problem. The Logs section lets you search past records to find when it started.
Don't change without measuring
The most common mistake in performance work is changing five things at once. Even if the result improves, you won't know which change did it, and next time you start from scratch.
The right method: make one change, restart, watch TPS during a busy hour, note the result. Tedious, but it's the only approach that works.
Scheduled restarts
From the Scheduler section you can set a task that restarts your server automatically at set times. A daily restart at the quietest hour clears load that accumulates on long-running servers.
Treat it as maintenance rather than a fix: it doesn't remove the root cause, it postpones the symptoms.
When should you resize the package?
If you've applied the steps above and TPS is still low, the problem is resources rather than settings — resizing from the Resources section is the right call. Which tier covers what is explained in the how much RAM guide.
One more thing worth knowing: Minecraft's world loop runs largely on a single core. So adding RAM alone may not fix a redstone- and mob-heavy world; cores have to grow too. Packages scale both together, and the cores allocated to you are never sold twice.
With the right settings, holding 20 TPS is an achievable target for most communities. Watching TPS for a few days after installing a new plugin or mod is the easiest way to catch a problem before it grows.
