How to Improve Hytale Server Performance and Reduce Lag
Find out whether your Hytale lag comes from the host, the world or a mod, measure it with the server’s own commands, and fix the real bottleneck before you pay for more RAM.
If everyone in one world sees delayed block breaks, rubber-banding and frozen creatures at the same time, that is server lag. If only one player suffers, check ping or client FPS first.
Use world perf, CPU, memory, entity count, who, plugin list and the logs folder during a normal busy session. That tells you what changes actually helped.
Max view radius, players exploring apart, fresh terrain generation and high entity counts are the usual bottlenecks. They hit RAM and main-thread CPU directly.
More RAM helps memory pressure and garbage collection. It does not fix a weak or heavily shared CPU, and it does not fix a bad mod.
First: is it server lag, network lag, or your own FPS?
Before changing anything, separate the symptom. Hytale server performance issues are often blamed on “lag” when the real problem is either one player’s connection or one player’s frame rate. The fix is completely different in each case.
A Hytale world targets 30 ticks per second. That gives each world tick about 33 ms to process world simulation, entities, chunk work and other server tasks. If the work for that tick takes longer than that budget, the world falls behind. Everyone in that world starts to feel delayed block breaks, creatures pause or snap forward, movement rubber-bands, and blocks you broke can pop back for a moment before the server catches up.
That is server lag. It is different from network lag, where packets arrive late for one player, and different again from client FPS lag, where the game renders badly on one machine even though the server is responding on time.
- Everyone sees it at once in the same world: likely server lag. Ask two or three players in the same area whether blocks, creatures and movement all feel delayed together.
- Only one player rubber-bands: likely network lag. If others in the same world are fine, the world tick itself is probably healthy.
- The picture is choppy but actions register promptly: likely client FPS. Low frame rate makes movement look bad even when the server is not behind.
- Ping is high but world actions are otherwise timely: that affects the player’s feel, not the server’s tick rate.
Once you know it is real server lag, sort the cause into three buckets: machine limits, world load, or mods.
Java heap too small, so garbage collection runs constantly
The UDP 5520 network path
Players exploring apart
New terrain and crowded creature areas
Errors repeated every tick
Built for an older Hytale version
Measure before you change anything
Do this during a typical busy time, not right after a clean restart with nobody online. A quiet server hides the problem. Reset the counters, reproduce the issue, then record what you see so each change has a before-and-after comparison.
world perf --all world perf --delta world perf graph world perf reset server stats cpu server stats memory entity count who world list plugin list
- world perf –all shows how smoothly a world is running overall. This is your main “is the world missing its 33 ms budget?” check.
- world perf –delta shows the change between readings, which is handy while you test one setting at a time.
- world perf graph helps you spot recurring drops instead of one-off impressions.
- world perf reset clears old data so you are not comparing tonight’s lag against yesterday’s exploration run.
- server stats cpu tells you whether the machine is working hard at the same time world performance drops. High CPU by itself does not prove the cause, but high CPU plus poor world perf usually means real server-side work is overrunning.
- server stats memory shows memory use. Watch it alongside CPU. If memory pressure builds and CPU rises with no matching jump in player activity, garbage collection is a strong suspect.
- entity count tells you whether a world has an entity problem. CPU load often follows active creatures and NPCs.
- who and world list show where players actually are. This matters because a few players spread far apart are often harder on the server than a larger group staying together.
- plugin list confirms what mods or plugins actually loaded. It is useful when somebody says “we removed that mod” but the server still has it active.
Also watch the console and the logs/ folder. Repeated warnings from the same mod, protocol complaints after an update, or a flood of errors every tick can explain poor Hytale server performance faster than any tuning guess. If you self-host and want proper graphs over time instead of snapshots, Hypixel recommends ApexHosting:PrometheusExporter for detailed server and JVM metrics.
The matrix below is the quick way to match symptom patterns to the likely bottleneck before you start tuning.
| What you see | Host limits | World load | Mods |
|---|---|---|---|
| Lag only when players spread out | Partly | Likely | No |
| Stutter in fresh, unexplored land | Partly | Likely | No |
| CPU climbs while the same players stay online | Likely | Partly | Partly |
| Worst near crowds of creatures | Partly | Likely | No |
| Started right after adding or updating a mod | No | No | Likely |
| The same error repeats in the logs | No | No | Likely |
| Laggy even at 12 chunks with few entities and current mods | Likely | No | No |
Use a triage path, not random tweaks
Once you have a baseline, follow a simple yes-or-no path. The goal is to test one theory at a time and stop changing things that are not connected to the symptom.
- If the issue affects one player only, check that player’s ping and FPS before touching the server.
- If the issue affects everyone in one world, look at world perf first. If it is poor, you are dealing with real server lag.
- If lag appears when players spread out, explore fresh land, or the server is running a high view radius, suspect world load.
- If CPU climbs while player behaviour stays steady and memory use is pressing against the heap limit, suspect garbage collection and memory pressure.
- If lag began after a new mod, after a game update, or the logs repeat the same mod errors, suspect mods.
- If the world still lags with sensible view distance, current mods and modest entity counts, suspect CPU quality or shared host contention.
World load fix 1: lower view distance first
View distance is the main driver of RAM usage on a Hytale server, and it also increases chunk management work. The default MaxViewRadius is 32 chunks, which is also the maximum. Hypixel recommends 12 chunks (384 blocks) for both performance and gameplay, and on a small plan it is sensible to try 8 to 10 first and only raise it after you know how your group behaves.
Why this setting matters so much: loaded area grows with the square of the radius, not in a straight line. A chunk is 32 blocks wide, so 12 chunks reach 384 blocks and the default 32 chunks reach 1,024 blocks. That default covers about 7.1 times the area of 12 chunks for each player. Going the other way, 10 chunks (320 blocks) is about 0.69 times the area of 12, and 8 chunks (256 blocks) about 0.44 times. When players stay together, some of that area overlaps. When they spread out, the server has to load separate chunk sets for each player, so RAM use rises sharply and chunk work multiplies.
Use the live command first so you can test the effect before editing files permanently.
maxviewradius maxviewradius 10
For a permanent change, stop the server first and edit config.json in the server folder (the main server config, not a world’s own config). Do not edit config files while the server is running, because the server reads them at startup and can write over manual changes.
"MaxViewRadius": 12,
Watch for three things after the change: lower memory pressure, smoother world perf during exploration, and less stutter when players separate. The trade-off is simple: players see less of the world at once. That is usually a far better compromise than a large radius that causes everyone to lag.
The chart below is the important bit to remember: radius looks harmless, loaded area is not.
If your player spread varies a lot through the day, Nitrado:PerformanceSaver can adjust view distance dynamically based on resource usage. It is useful as a safety net, but it still works best with a sensible ceiling rather than the maximum.
World load fix 2: players spreading out, new terrain generation, and extra worlds
A few players exploring in different directions can cost more than a bigger group standing near each other, because the server loads chunks around each player. Fresh terrain is worse again: the server is not only loading chunks, it is generating them, pushing work onto the world’s main thread and shared worker pool, then saving that new data to disk.
This is why lag often shows up as soon as somebody heads into untouched land. The server suddenly has to create world data instead of simply reading existing chunks. If that lines up with poor world perf, pre-generation is one of the cleanest fixes.
who world list world settings pregenerate set <minX> <minZ> <maxX> <maxZ> world settings keeploaded set <minX> <minZ> <maxX> <maxZ>
- Pregenerate the area around spawn, hubs, roads or any place players regularly reach early. This moves chunk generation work to a quiet time so normal sessions spend less of the 33 ms tick budget on world creation.
- Use keeploaded sparingly. It keeps a region ready, which can reduce reload churn for a small hub area, but it also keeps those chunks in memory permanently. That costs RAM all the time, not just when players are there.
- Check where players really are with who and world list. If one world has everybody spread across it, that is a different problem from several players gathered in separate compact worlds.
Extra worlds also matter. Each world runs on its own main thread and off-loads parallel work to a shared thread pool. That means one active world cannot magically borrow single-thread speed from another. More worlds can help organise your server, but every active world adds memory use and more total CPU work. If players are active across several worlds at once, total machine load rises even if no single world is enormous.
World load fix 3: entities and NPCs
CPU tends to follow active entity counts because creatures and NPCs need ticking, movement, scans and general world interaction. Update 7 reduced the cost of some distant creature behaviour, and far-away blocks, fluids and creatures are handled more cheaply, but crowded active areas can still drag a world behind.
entity count world settings freezeallnpcs set true world settings freezeallnpcs set false world settings spawningnpc set false world settings spawningnpc reset
Use these as diagnostic tools, not as permanent fixes. If freezing all NPCs for a minute makes world perf recover quickly, you have learned something valuable: entity activity is a real part of the load. If disabling spawning stops the problem from getting worse over time, the server is accumulating too many active creatures or NPCs in loaded areas.
The trade-off is obvious. Frozen or non-spawning NPCs reduce CPU work, but they also make the world feel empty or change how your server behaves. That is why the right long-term fix is usually to identify where entities are piling up, confirm it with entity count, and then reduce that hotspot rather than leaving the whole world frozen.
If you prefer persistent per-world settings, the same behaviour exists in each world’s config as flags such as IsSpawningNPC and IsAllNPCFrozen. Just make file changes with the server stopped so they are not overwritten.
Host limit: memory, Java, and garbage collection
The server can run on any device with at least 4 GB of memory and Java 25, but that only means it starts. Smooth play depends on behaviour: how far players spread, how many chunks stay loaded, and how many entities are active. Large loaded world area mostly pushes RAM; heavy entity activity mostly pushes CPU.
Hypixel’s wrapper reads custom JVM arguments from jvm.options. Their example is a good, simple starting point because it sets an explicit heap instead of leaving Java to guess.
# jvm.options -Xms2G -Xmx4G -XX:+UseG1GC
Why explicit heap sizing helps: without specialised tooling it is hard to tell how much heap the Java process really needs. If the heap is too small for your loaded world area, Java spends more time reclaiming and rearranging memory. That garbage collection work shows up as higher CPU usage even when player count is steady, because the machine is burning cycles managing memory instead of finishing world ticks.
That pattern matters: steady players, rising CPU, and memory pressing against the heap limit usually points to memory pressure rather than a sudden CPU-heavy event. In that case, reducing view distance often helps more than anything else because it cuts the loaded chunk footprint at the source. If the server still runs out of memory after lower view distance and current mods, then more RAM may genuinely be needed.
Do not give Java all available RAM. The operating system and Java’s off-heap memory still need headroom. Also, more RAM does not fix a world that is CPU-bound on entity ticks or chunk generation.
The shipped HytaleServer.aot cache helps boot time by skipping warm-up. It does not improve tick performance once the server is running. And while /world tps exists, lowering the tick rate is not a fix for lag; it simply makes the whole world simulate more slowly. If somebody has experimented with it, restore normal behaviour first.
world tps reset
Host limit: CPU quality, shared plans, and network
Because each world runs on its own main thread, single-world performance depends more on per-core speed than on headline core count. More cores still help for extra worlds and parallel work, but they do not make one overloaded world’s main thread finish faster. If you want the hardware logic behind that in more detail, our guide on how game server hardware requirements work breaks down CPU, RAM and storage in plain terms.
This is also why some rented plans feel inconsistent. If your server is on a heavily shared machine, the same world load can behave differently from one session to the next because the CPU time available to your main thread is less predictable. A good clue is poor world perf at modest view distance, current mods and low entity counts, especially if it happens even before players fan out.
Network issues are separate. Hytale uses QUIC over UDP on the default port 5520. Server location affects ping, not tick rate, so a distant region can make one player feel delayed without causing the world itself to miss ticks. If you need the networking side explained clearly, this guide on how server location affects ping covers what location can and cannot fix.
Leave RateLimit alone unless players are actually being dropped for packet rate. The defaults are 2000 packets per second per client with a burst capacity of 500. Those settings do not repair a slow world tick; they only govern packet bursts and abusive traffic patterns.
Mod-related lag: update, isolate, compare
Mods run on the same server process as the game, so one heavy, outdated or erroring mod can cause lag on its own. After every Hytale update, keep the server current and update mods immediately. Client and server also need to be on the exact same protocol version, so letting the game update while the server or a mod pack stays behind is asking for trouble.
Keeping the server current matters for performance as well as compatibility. Update 7 brought cheaper block, fluid and farmland ticking in busy areas, more efficient world-data compression when saving, and less work for distant blocks, fluids and creatures. If you are troubleshooting on an old build, you may be fighting problems that the current server already handles better.
plugin list
The clean way to test a suspected mod is to remove one at a time from mods/, restart, then compare your baseline with world perf, CPU, memory and logs. Start with anything recently added or anything built for an older Hytale version. If the same warning or stack trace repeats in the console or logs/, treat that as a strong clue rather than background noise.
If you need a refresher on the file side, this guide on how to install mods on a Hytale server covers the basics cleanly.
Symptom patterns and the tune-or-upgrade decision
| Symptom | Likely cause | First fix |
|---|---|---|
| Everyone in one world gets delayed block breaks and rubber-banding together | Real server lag in that world | Check world perf –all, then follow world load, memory and mod checks in order |
| Lag starts when players split up, but is fine when they stay together | Loaded chunk area too large | Lower MaxViewRadius; test 8 to 10 or move towards 12 as a sensible ceiling |
| Stutter appears mostly in fresh unexplored areas | New terrain generation | Pregenerate the routes, spawn region or hub area |
| CPU rises while player count stays steady and memory sits near the heap limit | Garbage collection from memory pressure | Reduce loaded world area first, then review -Xmx with headroom left for the machine |
| Lag is worst near creature-heavy or NPC-heavy areas | Entity ticking load | Use entity count; test freezeallnpcs or disable spawning briefly to confirm |
| Only one player rubber-bands while others play normally | Network or ping issue | Check that player’s connection and route before changing server settings |
| Only one player sees choppy movement, but actions still register quickly | Client FPS issue | Treat it as a client problem, not a server one |
| Lag began right after a Hytale update or after adding a mod | Outdated or incompatible mod, or old server version | Update the server and mods, then remove one mod at a time and compare |
| Low player load still feels bad at modest view distance with current mods | Weak or contended CPU plan | Suspect host limits, especially if world perf is poor and CPU is high |
| Players get disconnected, but the world itself stays smooth | Packet rate or network issue | Check logs first; only touch RateLimit if drops point to packet-rate handling |
Tune first, or upgrade now?
| What your testing shows | Best next step | Why |
|---|---|---|
| Lowering view distance fixes the problem quickly | Tune and keep measuring | The bottleneck was loaded world area, so more RAM may not be necessary yet |
| Pregeneration removes the worst stutter during exploration | Tune world generation workflow | You moved expensive chunk creation to quiet time instead of paying for it during play |
| Freezing NPCs or removing one mod restores smooth ticks | Fix entities or the mod set | The machine was not the root cause |
| Memory pressure remains after reduced view distance and current mods | Increase available RAM or heap carefully | This is one of the cases where more RAM actually helps |
| Lag persists with sensible settings, modest entities and clean mods | Move to stronger or less shared CPU resources | One world’s main thread is still missing its 33 ms budget |
If you decide to move to your own box, our Hytale dedicated server setup guide is a good checklist for the basics before you migrate.
If your tests point to plan limits rather than settings, do not keep papering over the problem with random tweaks. Our Hytale server hosting comparison is the quickest way to narrow down the right kind of plan for your player group and world style.
Compare the best Hytale server hostsHytale server FAQ
Why does my Hytale server lag when players split up?
Because the server has to load chunks around each player, and separate groups create separate loaded areas. That pushes RAM use up first, and it adds chunk management work on top. If some of those areas are fresh terrain, generation adds more main-thread CPU work as well.
What is the best view distance for a Hytale server?
There is no perfect number for every server, but 12 chunks is Hypixel’s recommended target for performance and gameplay. If you are on a smaller plan or you already see lag with several players, testing 8 to 10 first is sensible. The right number is the highest setting that keeps world perf healthy during your normal busy session.
Will more RAM fix Hytale server lag?
Only if memory pressure is the real problem. More RAM helps when view distance and loaded world area are too large for the current heap, or when the server is spending too much CPU time on garbage collection. It does not fix a weak CPU, a contended shared plan, or a heavy mod.
How do I check my Hytale server’s TPS?
Use world perf, especially world perf –all and world perf –delta, because that shows how smoothly the world is meeting its 30 TPS target. world perf graph is useful for spotting dips over time, and world perf reset lets you test one change cleanly. If someone changed the target tick rate manually, restore it with world tps reset.
Can mods make a Hytale server lag?
Yes. Mods run on the server alongside the game, so a heavy or outdated mod can slow ticks or fill the logs with repeated errors. The safest test is to remove one mod from mods/, restart, and compare world perf, CPU, memory and logs against your baseline.
More Hytale server help
Set up, mod and host your server with the rest of our Hytale guides.
Written for Hytale Early Access Update 7. Settings and defaults come from Hypixel’s Hytale Server Manual and the official server documentation. Hytale changes quickly in Early Access, so if your host’s panel labels a setting differently, follow the panel.
