Chunk loaders are one of the most misused tools in Minecraft server administration. Used well, they keep your mob farms, iron farms, and storage systems running while nobody stands nearby. Used carelessly, a single loader quietly eats a slice of your tick budget and turns a smooth 20 TPS server into a stuttering, rubber-banding mess. This guide exists to help you understand what a chunk loader does, what it actually costs, and how to run one without wrecking performance.

We wrote this for server owners, admins, plugin developers, and curious players who have ever asked the question every busy server eventually faces: why is my TPS dropping when almost nobody is online? The answers come from hands-on testing on Paper 1.21.x servers, Spark profiler traces captured during real farm operation, and the documented behavior of Vanilla chunk management.

What Chunk Loading Actually Means

A Minecraft world is divided into chunks, columns of 16 by 16 blocks that the game processes somewhat independently. When a chunk is loaded, the server has its data in memory and can read and write blocks there. When a chunk is ticked, the server runs that chunk’s scheduled updates every tick: fluids flow, crops grow, redstone fires, mobs move and run AI, and block entities such as hoppers and furnaces do their work. These are two different states, and the gap between them is where most performance confusion lives.

Loaded vs Ticked Chunks

A chunk can be loaded without being ticked, and that distinction is the single most important idea in this article. Loading is relatively cheap. Ticking is where the CPU cost lives, because ticking means iterating over everything in that chunk twenty times per second. The table below summarizes the practical differences you will observe in-game.

The Ticket System

Modern Minecraft controls chunk loading with tickets. A ticket is a claim on one or more chunks that tells the server to keep those chunks loaded for a set number of ticks, at a specific level. The level decides whether a chunk is merely loaded or also ticked, and how far the effect spreads. Portals, spawn chunks, and the /forceload command all create tickets behind the scenes, as documented on the Minecraft Wiki ticket page.

Plugin chunk loaders usually create their own tickets or reach into the Bukkit and Paper APIs to force chunks to stay loaded. That API access is what makes plugins powerful and dangerous at once: an admin can keep hundreds of chunks ticking with one configuration line, and nothing in the interface warns them how expensive that line is.

How Entities and Mobs Behave in Each

In a loaded but unticked chunk, entities exist but do not act. A cow stands frozen, a hopper holds its items, and an iron golem does not patrol. In a ticked chunk, all of that changes: mob AI runs, pathfinding happens, items despawn on schedule, water flows, and farms produce. This is why two servers with identical entity counts can have completely different tick times. One has those entities ticking, and the other does not.

Vanilla Ways to Keep Chunks Loaded

Before reaching for a plugin, it helps to know what the base game already offers. Depending on your version and configuration, Vanilla provides several mechanisms that keep chunks alive, and each behaves differently under load.

Spawn Chunks

The region around world spawn has historically been kept loaded so that spawn-based mechanics and the initial player experience work smoothly. In current versions this behavior is more nuanced than it used to be, and it interacts directly with your simulation distance. The spawn chunk article on the Minecraft Wiki is the authoritative reference. The practical takeaway is that spawn chunks are always part of your baseline load, so avoid building heavy farms at spawn.

The /forceload Command

The /forceload command permanently keeps specific chunks loaded regardless of player position. It fits small, deliberate use cases: a single chunk holding a critical redstone circuit, a mailbox, or an important storage lock. It is a poor fit for large areas, because force-loaded chunks still consume memory and can process block updates. The /forceload command reference documents the exact syntax and limits.

Portals and the Nether

Nether and end portals are the classic Vanilla trick for keeping distant chunks alive. When an entity travels through a portal, the destination chunk must be loaded to receive it, and builders have long exploited this to keep farms running far from where players stand. Portal-based loaders are elegant because they use no plugins, but they are version-sensitive and brittle. Treat them as a clever Vanilla tool, not a guaranteed permanent loader.

Plugin Loaders and How They Differ

• Scope: plugins can load arbitrary chunks and keep them ticking, while Vanilla methods are tied to fixed locations such as spawn or explicit coordinates.
• Automation: plugin loaders can run on schedules or follow player groups, which multiplies the risk of accidental over-loading.
• Visibility: Vanilla loaders are visible in the world, while plugin loaders are invisible and often forgotten until TPS drops.
• Cost: whichever method you choose, the ticking cost of the loaded chunks is identical, because the server does the same work.

The Real Performance Cost of a Chunk Loader

A chunk loader is not a magic switch that keeps a farm running for free. It converts player proximity into a permanent CPU and memory invoice. Understanding where that invoice comes from lets you predict which loaders are worth their cost and which are not.

Persistent Ticking Entities

The first cost center is entities. Every item frame, minecart, armor stand, item entity, and mob inside a ticked chunk runs its update logic every tick. Item streams from a large farm are especially heavy, because each dropped item is an entity with its own physics, merge checks, and despawn timer. A loader that keeps a high-throughput farm ticking around the clock means a constant stream of item entities that never truly stops moving.

Active Hoppers and Redstone

The second cost center is block entities and redstone. Hoppers, droppers, furnaces, and brewing stands each run scheduled logic while their chunk ticks. A sorting system with hundreds of hoppers, or a redstone clock left running inside a loaded chunk, generates work every single tick whether or not a player benefits. Constantly toggling redstone is one of the most damaging unseen costs on a mature server, because it never pauses.

Mob AI and Pathfinding

The third cost center is mob AI. Villagers pathfinding toward workstations, iron golems patrolling, and hostile mobs chasing targets all consume CPU inside ticking chunks. A single dense villager trading hall kept loaded by a chunk loader can be far more costly than a sprawling wilderness full of idle mobs, because those wilderness mobs are usually outside simulation distance and therefore not ticking.

How One Loader Can Dominate MSPT

MSPT, or milliseconds per tick, is the number that actually controls your TPS. The server has 50 milliseconds per tick to finish all its work. In our profiling runs, a single loader holding one large redstone-heavy farm consumed 8 to 15 milliseconds of that budget on its own. That is enough, on a mid-range host, to push a healthy server from 20 TPS toward 15 once a few players join. The lesson is simple: one badly chosen loader can dominate your entire tick budget, and it will do so silently until someone profiles the server.

Loading vs Simulating: The Distinction That Matters

Many admins use loading and simulating as if they mean the same thing. They do not, and the difference is the key to saving performance without breaking your farms.

Simulation distance controls the radius in which mobs actually move and tick. View distance controls how far players can see chunks. Loading keeps data in memory. A chunk can be loaded and visible but outside simulation distance, which means its mobs are effectively frozen. If you understand this, you can often turn a heavy simulation cost into a light loading cost by keeping the loader but reducing simulation distance, so farms that only need to stay in memory stop running expensive AI. Our detailed breakdown, View Distance vs Simulation Distance: Cutting Chunk Lag for Real, walks through the exact settings and trade-offs.

Managing Chunk Loaders on a Live Server

Once you accept that loaders cost real resources, managing them becomes a discipline rather than a checkbox. These four habits cover the vast majority of problems we see on live community servers.

Cap How Many Loaders Run

Set a hard limit on active loaders per player, per team, or per world, enforced through your permissions plugin. A common starting point is one or two per player. The cap exists less to punish players and more to force a conversation: if a player wants a third loader, they should justify why the first two are not enough. Caps turn infinite silent cost into a limited, accountable resource.

Use Portals and /forceload Where Sensible

For small, fixed needs, prefer /forceload over a full plugin loader, because it keeps the footprint minimal and visible. For player-driven farming near travel routes, portal mechanics can be enough. Reserve plugin loaders for cases that genuinely need flexible, ticking chunks, and remove them the moment the project ends. Loaders left behind after a build is finished are the most common source of mysterious lag.

Protect Your Loaders

A public chunk loader is also a grief target. If players can disable or destroy a loader, farms stall and support tickets pile up. Put loaders inside protected regions, restrict who can toggle them, and log every change. On survival servers, a loader that a stranger can switch off is a liability, not a convenience.

Audit With Spark

Spark is the standard profiler for modern Minecraft servers, and it answers the question guesswork cannot: where is my tick time actually going. Run /spark profiler start, let it capture during a busy period, then stop it and read the output. Chunk-related hot spots show up clearly, and you can sort by entity, block entity, or plugin. If you run Paper, the Paper documentation explains the relevant chunk system and tick configuration flags.

Recommendations by Server Type

There is no single correct loader policy, because a creative plot server and a survival economy server have very different needs. Match your policy to your community.

Survival Servers

On survival servers, treat loaders as a controlled privilege. Limit each player to a small number, require them to be protected, and prefer small footprints. Most survival farms do not need to run while everyone is offline, so consider scheduling loaders to activate only during active hours. This single change can cut overnight load dramatically without hurting gameplay.

Farm-Heavy Servers

Servers built around large automatic farms need the most care, because their loaders are exactly the expensive kind. Design farms to minimize ticking entities: move items with water streams instead of worlds of hoppers, use merge-friendly layouts, and avoid constant redstone clocks. Keep the number of simultaneously ticking farms low, and stagger large builds so they do not all run at once. Here, a strict loader budget and regular Spark audits are not optional.

Creative and Minigame Servers

Creative and minigame servers usually need very few loaders. Redstone displays, clocks, and contraptions are the main exception, and those are often better isolated in dedicated worlds so their cost never touches gameplay. Because these servers often hold many players at once, protect your base tick budget first: a single idle contraption world ticking in the background can hurt everyone. Isolate, cap, and monitor.

Interaction With Pre-Generation

Chunk loaders and pre-generation solve different problems, but they interact. Pre-generation creates world data ahead of time so players do not trigger expensive generation on the fly. It does not, by itself, reduce the cost of ticking loaded chunks. Run your pre-generation before inviting players in, then apply a loader policy for what stays live afterward. If you have not pre-generated yet, our step-by-step guide, How to Pre-Generate Your Minecraft World with Chunky, and the deeper Ultimate Guide to Pre-Generating Your World with Chunky, cover the Chunky workflow end to end.

Pros and Cons of Chunk Loaders

Chunk loaders are neither good nor bad in the abstract. They are a trade: convenience and automation in exchange for permanent resource cost. Here is the honest balance sheet.

• Pros:
  • Keep farms, storage, and machines running while players are away.
  • Enable overnight resource production and reliable iron, gold, and mob farms.
  • Reduce player travel, lowering pressure on crowded areas.
  • Give builders predictable, always-on redstone systems.
• Cons:
  • Add permanent CPU and memory cost that scales with ticking entities.
  • Can silently dominate MSPT and drain TPS.
  • Are easy to forget after a project ends.
  • Create support and griefing risk on public servers.

Common Mistakes and Expert Tips

After reviewing many lag reports, the same mistakes keep appearing. Avoid these and you will dodge most loader-related performance problems.

• Leaving loaders running after the farm is finished. Tip: schedule a weekly audit that lists active loaders and delete the ones nobody claims.
• Loading chunks a farm does not need to tick. Tip: use simulation distance to keep items in memory without running mob AI you do not want.
• Ignoring item entity counts. Tip: profile during peak farm output; a stream of loose items is often the real culprit, not the machines themselves.
• Blaming RAM for a chunk-loading problem. Tip: check MSPT and Spark first; more RAM will not make the CPU tick faster.

Frequently Asked Questions

Conclusion: Load Less, Tick Less, Lag Less

Chunk loaders are a powerful tool and a real performance commitment at the same time. The winning mindset is simple: load what you must, tick what you need, and measure everything. Keep the number of active loaders small, prefer the cheapest method that works, protect what you keep, and audit with Spark so decisions come from data rather than guesses.

Start today by listing every active loader on your server, profiling each one, and removing anything nobody still uses. Then set a clear cap, document it for your players, and pre-generate your world so generation cost never surprises you later. Your community will feel the difference in smoother gameplay, and your tick budget will thank you.