Why your FiveM server lags
It is almost never the resource everyone in your Discord is blaming. Here is how to find out what it actually is.
Every server has a resource its community is certain is the problem. It is usually the newest one, or the one that was running when things last went wrong. It is usually not the cause.
Lag has a small number of real causes, and they leave different fingerprints.
First: is it the server or the client?
These feel similar and are fixed in opposite places. Server-side trouble hits everyone at once, shows up as rubberbanding and delayed events, and lines up with player count. Client-side trouble is one player with bad frames while everyone else is fine, and it moves with what is on their screen.
Check the server console for tick warnings and watch whether the complaints arrive together. If three people report stutter within the same minute at peak, that is the server. If one person reports it all evening, that is their machine or a client-side script running badly on it.
Reading resmon properly
The mistake is running resmon on an empty server. Everything looks fine because nothing is happening. Numbers you can trust come from a busy server, ideally at peak.
What you are looking for is not the highest number. It is the resource that costs something while nothing is happening. A script at 0.6ms during an idle moment is running a loop it does not need, and it will still be doing that at peak on top of everything else.
The four things it usually is
- A thread running every frame. Something checks a distance or a key on every tick when it could check twice a second, or only after an event. This is the single most common cause and the cheapest to fix.
- A database query in a loop, or one that runs on every spawn without an index behind it. Symptom: fine at 20 players, unusable at 80. It scales worse than linearly, which is why it seems to appear overnight.
- A NUI page that never stops rendering. The interface is closed, the browser is not. Animations keep running on a hidden layer and the player pays for it in frames.
- Event spam. Client and server chatting far more than needed, sometimes because a client event fires on a loop, sometimes because something is being validated in the wrong place.
When it is not a script at all
Two hosting causes look exactly like a bad script.
The first is shared CPU. FiveM leans hard on a small number of threads, so a cheap VPS with oversold cores produces stutter at peak that no amount of script tuning fixes. Above roughly forty concurrent players this is worth ruling out before you pay anyone to optimize anything.
The second is a remote database. Every query pays the round trip. It is invisible at low player counts and brutal at high ones. Moving MySQL onto the same machine is frequently the largest single performance win available on a busy server.
How to work through it
- Measure at peak, not on an empty server.
- Change one thing at a time, and write down the number before and after.
- Suspect what is idle, not what is loudest.
- Rule out hosting before optimizing scripts, not after.
- Keep the notes. The next time it happens you will want to know what you already tried.
If none of that finds it, the honest next step is someone reading the resources under load. But do the measuring first: it is free, and it often ends the search on its own.
Questions
about this
How many resources is too many?
There is no number. Two hundred well-written resources can idle at almost nothing while a dozen bad ones can eat your tick. Count milliseconds, not resources.
Will restarting on a schedule fix it?
It hides leaks and postpones them, which is worth doing anyway for other reasons. If your server is only usable for the first hours after a restart, you have a leak, and the restart is a workaround rather than a fix.
Want this handled instead of researched?