Why Your FiveM Server Is Lagging: A Script Developer's Diagnosis

The answer you'll get everywhere else

Search this question and nearly every result is published by a company that sells servers. Their answer, reliably, is that you need a better server. Sometimes that's true. Usually it isn't.

We write the resources instead, so our incentive points the other way — and it points at the honest answer: the single most common cause of a laggy FiveM server is a resource doing expensive work every frame that it should be doing rarely, or never. You can find it yourself in about ten minutes, and no purchase is required to do it.

Ten minutes with resmon

resmon is FiveM's built-in per-resource CPU monitor and it is the only tool that matters for this diagnosis. It reports how many milliseconds of each frame a resource consumes. A frame at 60fps is 16.67ms total, shared across everything.

• Press F8 and run resmon 1. The overlay lists every running resource with its current ms cost.
• Click the ms column to sort. Watch it at idle first — standing still, nothing happening.
• At idle, a well-built resource should read 0.00–0.02ms. Anything holding above ~0.05ms while you do nothing is burning your frames for no reason.
• Now do the thing that lags: open the inventory, drive fast, enter the busy zone. Watch which resource climbs and stays climbed.
• Active spikes are normal and brief. Sustained cost above ~0.10ms during use is the signature of a loop that should be an event.
• Note the name. Stop that resource. Repeat the action. If the lag is gone, you have your answer.

What actually causes the cost

Nearly every expensive resource we've profiled is expensive for one of a few reasons, and all of them are choices made by the person who wrote it.

The most common is a while true do ... Wait(0) end loop running logic sixty times a second for something that changes once a minute — a marker check, a distance test, a UI refresh. The second is a database query inside that loop, turning a frame cost into a frame cost plus a round trip. The third is client code asking the server for something the client already knows, on a timer. The fourth is drawing 3D text or markers for every entity in the world rather than the few near the player.

None of these are exotic. They're what happens when a resource is written to work rather than written to be cheap, and they are invisible to a buyer reading a feature list.

When it really is your server

Hardware is the second thing to check, and there are honest signals for it. If resmon shows every resource behaving well and the server still hitches under player load, look at single-thread CPU performance — FiveM's server loop cares far more about per-core speed than core count. If lag correlates with player count rather than with any particular action, OneSync configuration and network are worth a look. If hitching arrives in periodic spikes with no in-game trigger, watch for database slow queries and for scheduled tasks all firing on the same interval.

But do the resmon pass first. It costs ten minutes and it usually ends the investigation.

How to not buy the problem again

Every store claims performance. Almost none publish a measurement. Before you buy, ask the seller for the resmon number, the method used to get it, and the date it was taken — those three together are a claim you can check, and any of them missing makes the number decorative.

That standard is the one we hold ourselves to: our resources publish measured idle and active figures with the method and date, or they publish nothing and say so. A pending label is more useful to you than a confident number nobody measured.

Frequently asked

Read next