How to Fix FiveM Server Lag: A Resource & Performance Guide

1 First, figure out which kind of lag you have

People say "my server is lagging" for three very different problems. Fixing the wrong one wastes hours, so name it first:

Symptom	What it actually is
Rubber-banding, NPCs/vehicles popping, desync between players	Network / OneSync — the server can't sync entity state fast enough for the player count.
Whole server hitches, chat/commands delayed, "server thread hitch warning" in console	Server thread overload — resources are eating more time per tick than a frame allows.
Only you lag (low FPS) while others are fine	Client-side — a heavy HUD, too many props/streamed assets, or your own PC. Not a server fix.

This guide focuses on the first two — the ones a server owner controls. The single most useful number for both is your server-thread cost, and you read that with resmon.

2 Read resmon properly

In the live server console (F8 in-game, or the txAdmin live console) type resmon. You get a live table of every running resource with its CPU time in milliseconds and its memory.

• CPU msec is the number that matters for hitches. It's how long that resource takes each server tick.
• Memory matters for stability and streaming, not tick speed. A 200 MB MLO is normal; a 200 MB script is not.

Rough server-side thresholds for a single resource, measured while the server is populated:

CPU time	Verdict
under 0.5 ms	Healthy. Leave it alone.
0.5 – 1 ms	Fine for a core (ESX/QBCore/inventory), watch anything else.
1 – 2 ms	Worth investigating — usually a loop or event spam.
2 ms +	A real offender. This is where your hitches are coming from.

3 Fix the heavy resources

Once you know your top 3–5 offenders, the fixes are usually one of these, in order of how often they help:

Update it

Old builds of popular resources (ox_inventory, anticheats, HUDs) leak performance that newer versions fixed. Before doing anything clever, grab the latest release build and re-test. This alone resolves a surprising share of "sudden lag."

Hunt tight loops

The classic FiveM performance killer is a thread that runs every frame when it doesn't need to:

-- Bad: runs every tick forever
CreateThread(function()
    while true do
        Wait(0)            -- 60+ times a second
        DoExpensiveCheck()
    end
end)

-- Better: only loop fast when it matters
CreateThread(function()
    while true do
        local sleep = 1000   -- idle
        if nearPointOfInterest() then sleep = 5 end
        Wait(sleep)
        DoExpensiveCheck()
    end
end)

If a resource is yours or open-source, search it for Wait(0) and Wait(1). Most of them can wait far longer with dynamic sleep.

Cut what you don't use

Every ensured resource costs something even when idle. Disable HUD widgets you don't need, remove abandoned scripts, and avoid running two resources that do the same job (two targeting systems, two notification libs).

4 Right-size OneSync

OneSync is what lets FiveM go past 32 slots and sync entities server-side. It's also a common source of "everyone rubber-bands at 40 players." Two things to get right:

• Slot count vs. reality. Setting sv_maxclients 128 doesn't make your box able to handle 128 — it just lets them in. Set it to what your CPU and scripts can actually sync smoothly.
• Population / entity load. Heavy AI traffic, lots of spawned props, and big MLO interiors all add OneSync work. If network desync scales with player count, this is usually where to look before blaming the host.

Make sure OneSync is actually on in your config — our server.cfg generator sets set onesync on and sane defaults so you're not running the legacy 32-slot path by accident.

5 When it's not the scripts — it's the hardware

FiveM's server runs the bulk of its work on a single thread. That means raw core count barely matters; what matters is single-thread clock speed. A 32-core server CPU at 2.4 GHz will hitch where a 4-core desktop chip at 5.0 GHz sails through, because FiveM can only use one of those cores at a time for the main loop.

So if your resmon is already clean — core resources under 1 ms, no single offender above 2 ms — and you still hitch at population, you've likely hit your host's CPU ceiling. Budget "game panels" that pack hundreds of servers onto slow, many-core CPUs are the usual culprit.

6 Quick recap

1. Name the lag: OneSync/network, server-thread, or client-side.
2. Run resmon; sort by CPU msec.
3. Update, de-loop, and trim your top offenders one at a time.
4. Set OneSync on and size slots to what you can actually sync.
5. If scripts are clean and you still hitch, it's single-thread CPU speed — i.e. the host.