> ## Content Index > Fetch the complete content index at: https://dedicatedmc.io/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Optimising a modded Minecraft server - URL: https://dedicatedmc.io/blog/optimising-modded-minecraft/ - Published: 2026-08-18T10:00:00.000Z - Updated: 2026-10-30T12:21:06.000Z - Description: Why modpacks cost so much more per tick, and the practical steps that bring a modded Minecraft server under control, from pregen to caps and heap sizing. - Author: Mark E - Tags: Guide, Minecraft, Modded, Performance A modpack is a much heavier thing to run than vanilla Minecraft, and the first time people make the switch, it shows. The same box that hosted a smooth vanilla world starts dropping ticks the moment a few players spread out and start building. This post explains why modpacks cost so much more per tick, and the practical steps that bring them under control. Good hardware helps, but a modpack that is tuned well runs happily where an untuned one struggles, so the tuning is worth doing first. ## Why modpacks cost more per tick Every tick, the server simulates the world: move entities, run block updates, process anything active in loaded chunks. Vanilla keeps that workload modest. A modpack piles on top of it. Modpacks add far more of everything the tick has to touch. More entity types, more mobs, and often more at once. Machines and automation that run logic every single tick, sometimes hundreds across a busy base. Chunk activity from mods that keep areas loaded so their contraptions keep working with no player nearby. Each of those is more work for the one thread that has to finish the tick, and a modpack can multiply it many times over compared with vanilla. That is why a modded server is still, almost always, CPU-bound rather than RAM-bound. It needs more heap than vanilla, which we will come to, but the thing that caps how many players and machines it can handle is single-thread CPU speed. RAM stops it crashing; the CPU decides how fast it runs. ## Pre-generate the world The single most effective thing you can do for a modded server is pre-generate the world before players are on it. Generating new terrain is one of the most expensive things the server does, especially with a modpack that adds custom world generation, ores and structures. When a player walks or teleports into fresh terrain, the server builds it on the spot, and that lands as a lag spike for everyone. Pre-generating walks the world ahead of time, up to a set radius, so the expensive work is done once, quietly, before anyone is playing. After that, players are almost always moving through terrain that already exists. Set a sensible world border to match, so the pre-gen ends somewhere and the world has a size cap on disk. ## Optimisation mods and chunk management The modding community has built a strong set of mods whose whole job is to make the server run better. These are worth looking into, and it is best to confirm compatibility with your exact pack and version before adding them. As of Minecraft 1.21.x the usual picks are Lithium for general server-side patches, FerriteCore for memory, and C2ME for chunk work, all of which have Fabric and NeoForge builds, with Moonrise adding a rewritten chunk and light engine on those two loaders. Forge has fewer options, though FerriteCore and ModernFix both cover it, and a heavy Forge pack can still be tuned through its own configs. The two categories that matter most: - General performance mods that rewrite inefficient parts of the game's own code, cutting the cost of things the server does every tick without changing how the game plays. - Chunk management, often the biggest single win. Automation mods love to keep chunks loaded, and a base full of always-loaded chunks is one the server simulates around the clock. Tools that let you see and rein in runaway chunk loading directly cut the work the tick has to do. ## Mob and entity caps Entities are one of the largest tick costs on a busy modded server, and they accumulate. Mob farms, breeding, dropped items that never despawn, and the extra creatures mods add all pile up until the server spends real time every tick just tracking them. Sensible caps keep that in check. Limit how many mobs spawn per area, keep item despawn timers reasonable, and watch for the entity types a given pack produces in huge numbers. The performance forks and configs most servers already use give you levers for this, and entity cleanup is often the difference between a base that ticks smoothly and one that grinds. ## View and simulation distance View distance and simulation distance are two of the strongest dials you have, and on a modpack they are stronger still because every loaded chunk is more expensive than in vanilla. View distance sets how far chunks are sent to players. Simulation distance sets how far the server actually ticks the world: mobs, crops, machines and block updates. Simulation distance is the one that costs the server, because ticking a chunk is far more work than sending it. Bringing it down even by a couple of chunks can noticeably lower MSPT on a heavy pack, and most players never notice. Keep view distance comfortable and keep simulation distance as tight as the pack can tolerate. On a heavy modpack that usually means a simulation distance of around 4 to 6, dropping to 3 on a very busy server, with view distance sitting a little higher at 6 to 8 for the look of it. ## Loaders and heap Modpacks run on a mod loader: Forge, Fabric, or the newer NeoForge, depending on the pack. They differ in ecosystem and in some technical details, and the pack itself dictates which you use, so this is rarely a free choice. What they have in common is that a loaded modpack needs more heap than vanilla. Mods load a great many classes and keep more in memory, so the comfortable heap sits well above what a vanilla world of the same player count would want. Our guide to [how much RAM a Minecraft server needs](https://dedicatedmc.io/blog/how-much-ram-minecraft-server) covers the ranges. Worth repeating: giving it more heap than it uses does not make it faster, and past a point can lengthen garbage-collection pauses. Size it to what the pack needs, then stop, because the server is still CPU-bound underneath. ## Keep mods updated Optimisation is not a one-off. Mod authors fix performance bugs constantly, and a version bump can quietly remove a stall that was costing you MSPT every tick. Keeping the pack current is one of the cheapest ways to stay fast, provided you test updates before rolling them onto a live server rather than after. If you work through this list and still have spikes, our [Minecraft lag checklist](https://dedicatedmc.io/blog/minecraft-lag-checklist) is the next place to look, because it walks the diagnosis step by step. Modded servers reward the box behind them, because there is simply more work per tick to absorb. If you want hardware built for that kind of load, that is what we run. [Explore modded Minecraft hosting](https://dedicatedmc.io/modded-minecraft-server-hosting?ref=dedicatedmc.io)