Every FiveM server owner eventually asks some version of “why is my server laggy when the VPS CPU is only at 40%?”

The answer is almost always TPS, server ticks per second. It's the metric that determines whether your server feels smooth, independently of your hardware spec. Here's what it is and how to actually fix it.

What TPS actually means

FiveM's server-side scripting runtime runs on a loop. Every iteration of that loop is a tick: the server processes incoming events, runs every script's Wait(0) loops, handles callbacks, sends network updates to connected players, and repeats.

The server's main script thread targets ~20 ticks per second, one tick roughly every ~50 ms. When your scripts are light enough that the work finishes well inside that budget, the main thread sustains its full 20 TPS and everything feels smooth. (The network thread runs separately and much faster, at 100 Hz.)

When a script's per-tick work bloats and the main thread can no longer keep up, effective TPS falls below 20. That's where rubber-banding, delayed menu responses, and “I pressed E and nothing happened” come from. The 60 TPS / 16.67 ms number you see quoted is the client's60 fps frame budget, not the server's.

TPS is not a hardware metric. It's a script-quality metric. Upgrading your VPS almost never fixes a TPS problem because the FiveM main thread is single-threaded, a faster single core helps marginally, more cores help not at all.

The four TPS killers

1. Unoptimized script loops

The most common TPS killer is a script doing more work per tick than it needs to. Classic mistakes: calling GetPlayerPed(-1) inside a tight loop (use the ox_lib cache.ped instead); iterating over all players on every tick when you only need to check every second; running heavy math inCitizen.CreateThread with Wait(0) whenWait(1000) would do.

resmon (connect in-game, press F8 to open the client console, then run resmon true) shows per-resource CPU time per tick. Any resource using more than 1-2 ms on average is a candidate for rewriting. Anything over 5 ms is usually a ticking time bomb.

2. Database work on the main thread

Synchronous database queries (MySQL.Sync.fetchAll and similar) block the main tick until they return. A single 40 ms query stalls the main tick. Switch to async (the oxmysql promise-based API) and index your queries, see the FiveM Coach by Quasar FiveM server optimization guide for the SQL indexing and hot-path treatment.

3. Resource startup spikes

When a server restarts, all resources start in parallel. If you have 80+ resources loading at once, you get a 20-30 second window of 10-15 TPS while everything initializes. Stagger critical resources using server.cfgordering, and avoid heavy work in a resource's top-level CreateThreadthat runs on start.

4. Entity density hotspots

Areas with lots of NPCs, vehicles, or props (police HQ, hospitals, the Legion Square bank) cause local entity-update surges that impact the server tick. Mitigations: use polyzone-based resource activation (only run NPC logic when a player is nearby), despawn unused vehicles, and cap NPC counts per zone.

What almost never helps

  • Upgrading from a 4-core to an 8-core VPS.Main thread is single-threaded.
  • More RAM. Only helps if you were actually running out, which is rare.
  • Switching Linux ↔ Windows. Marginal at best.
  • Removing ox_lib or ox_inventory.These are well-optimized; they're almost never the problem.

Diagnosing TPS in under 10 minutes

  1. Open txAdmin → Server dashboard. Note current tick time / hitch data for the server thread.
  2. Connect to your server in-game, hit F8 to open the client console, and run resmon true. Sort by CPU time.
  3. The top 3 resources by CPU time are your suspects. Anything above 1 ms average and you start there.
  4. For each suspect, open the resource's .lua files and search for while true do and Wait(0). Most unoptimized scripts have at least one of these running more often than needed.
  5. If it's a third-party resource, check for an updated version, or an alternative that does the same job.

When to get help

TPS diagnosis is the single most common “bring your server to the call” topic in Academy Elite. If you've gone through the checklist above and still can't identify the bottleneck, Elite gets you a weekly code review that almost always resolves this in one session. The Enterprise track includes done-with-you server profiling.

Frequently asked questions