FiveM Server Optimization: Reduce Lag Below 10ms in 2026

In FiveM, "lag" almost always means one thing: the server's main thread execution time is too high. The target is under 10ms. Above 30ms, players experience rubber-banding. Above 50ms, the server is functionally broken. This guide covers how to measure, diagnose and fix every common performance bottleneck.

Reading the txAdmin Resources Panel

Open txAdmin → Resources and sort by the Time column descending. This shows every resource's main thread consumption in milliseconds. The top entries are your performance problem. Targets:

• Framework (qb-core / es_extended): under 1.0ms
• Each job script: under 0.5ms
• HUD and UI resources: under 0.1ms
• Total server thread: under 10ms with players online

Anything above 2ms for a single resource needs investigation. Anything above 5ms is a critical problem.

OneSync Configuration

Enable OneSync Infinity on all modern servers. Without it, every entity update broadcasts to every player — a 128-player server without OneSync spends the majority of its bandwidth on entity sync instead of gameplay:

# server.cfg
set onesync on

OneSync implements proximity-based entity culling: players only receive state updates for entities within approximately 400 units (~150m). State for distant players is culled entirely, dramatically reducing network and CPU overhead.

Finding Bad Resource Loops

The most common cause of high resource thread time is Citizen.Wait(0)inside a loop — this runs the loop every single frame, which at 60 FPS means 60 executions per second.

-- BAD: runs 60 times per second
Citizen.CreateThread(function()
    while true do
        Citizen.Wait(0)
        -- expensive check here
    end
end)

-- GOOD: runs once per second for passive checks
Citizen.CreateThread(function()
    while true do
        Citizen.Wait(1000)
        -- check here
    end
end)

Search your resource files for Wait(0) — every instance should be justified. Animation loops and input detection legitimately need it; database checks and distance calculations do not.

Database Optimisation

Most FiveM lag on live servers originates from slow SQL queries. Enable slow query logging in oxmysql:

# server.cfg
set mysql_slow_query_warning 100  -- warn on queries over 100ms

The most impactful index to add, covering 90% of slow lookup queries:

ALTER TABLE players ADD INDEX idx_identifier (identifier);
ALTER TABLE player_vehicles ADD INDEX idx_citizenid (citizenid);
ALTER TABLE player_vehicles ADD INDEX idx_plate (plate);

Run EXPLAIN SELECT ... on any query that appears in slow query logs. A query that shows type: ALL (full table scan) needs an index.

Streaming Budget Management

Vehicle streaming is the most common source of client-side lag on servers with large vehicle packs. Each client maintains a streaming budget — as it fills, lower-priority assets unload, causing texture pop-in and stutter.

Split large vehicle packs across multiple resources (see the vehicle streaming guide), and ensure garages use lazy-loading — only streaming a vehicle when the player retrieves it from the garage, not on server start.

Monitoring After Optimisation

Set a recurring check: every two weeks, look at the txAdmin resources panel during peak hours. New scripts added by staff members are the most common source of performance regressions — a single poorly written resource can undo weeks of optimisation work.