Lithium

Lithium: The Server Performance Mod to Install First

Lithium is a no-compromises optimization of Minecraft's game logic and, with over 105 million downloads, one of the most important performance mods in existence — explicitly useful for both single-player and multiplayer servers. Unlike rendering-focused mods, Lithium improves internal computations like pathfinding, tick processing, and redstone logic, which translates directly into a healthier server tick rate.

For a rented server, Lithium should be one of the first mods you add to the mods folder — it pays off especially with high player counts, large redstone builds, or entity-dense farms. Install the same version on the client too, so local play sessions benefit as well.

Pairing tip: Combine Lithium (CPU/tick performance) with FerriteCore (memory) to cover the two biggest server bottlenecks at once — well worth including in any performance-focused modpack.

Plan the rollout and operation

Test Lithium under real world load because its benefit lies in ticking and AI. Compare milliseconds per tick or tick rate at the same farm, with the same loaded chunks and a similar player count. Check redstone, villagers, mob farms, and dimension travel after a restart. Add other performance mods one at a time so a rare incompatibility can be attributed to a specific change.

Before installation, back up the world, mods, config, and defaultconfigs, and record the Minecraft, loader, mod, and dependency versions. Start the complete list on a copy first and read the log for missing or incompatible requirements. A meaningful test covers server boot, joining with a matching client, chunk loading, the core feature, saving, restarting, and joining again. Measure performance mods against the same world and load; validate libraries through at least one dependant feature. Update only one package or one related dependency group per run. Before removal, determine whether blocks, entities, items, or configuration remain in the save. Only a cleanly loading world copy justifies changing the live server. Keep previous files and the backup ready rather than mixing several versions during a boot failure. Finally, record the result with the server log and client version so later updates can be compared against a proven working state.