FiveM Script Performance: Resmon Basics for Server Owners

When players say "the server lags", they can mean three different things: low FPS on their own PC, rubber-banding and desync, or long waits for menus and actions. The resource monitor, usually called resmon, helps with the first one and gives hints about the others.

This guide explains how to use it without being a developer. It is written for GTA V FiveM servers on any framework.

What resmon measures

Resmon shows how much work each resource does on the client, the player’s PC. Open it from the F8 console with:

resmon 1

and close it with resmon 0. You get a list of running resources with, among other things:

• CPU time in milliseconds (ms): how much time the resource’s scripts take per frame, on average.
• Memory: how much memory the resource’s scripts are holding.

The ms column is the one to watch.

Why milliseconds per frame matter

At 60 frames per second, the game has about 16.7 ms to produce each frame. Everything happens in that budget: the game itself, the rendering, and every resource on your server. If your resources together take 5 ms per frame, that is time the game does not have for anything else.

One resource at 0.5 ms looks harmless. Twenty resources at 0.5 ms each are 10 ms, more than half the frame. That is how a server "suddenly" becomes laggy even though no single script looks bad.

What is a good number?

There is no official limit. As a rule of thumb, many developers aim for resources that sit at or very close to 0.00 ms when nothing is happening, and that only rise briefly while they are doing something, like when a menu opens or a job runs. A resource that stays high while idle is doing work nobody needs.

Treat those numbers as a guide, not a standard. What matters is your total, on your players’ PCs.

How to measure properly

A single look at resmon tells you little. Do this instead:

1. Test in a busy spot. Measure where players spend time, not in an empty field.
2. Measure idle and active. Note the value while you do nothing, then while you use the script: open the menu, start the job, drive the car.
3. Write down a baseline. Record the top ten resources after a restart. Next time something feels wrong, compare.
4. Change one thing at a time. Add or update one resource, restart, measure again.
5. Test on a weaker PC. A high-end CPU hides problems your players feel.

Finding the resource that costs frames

Sort and look at the top

Most of the time, two or three resources account for most of the cost. Look at what is at the top of the list, idle, in a busy area.

Usual suspects

On many servers, these types of resources are often near the top:

• HUDs that update the UI every frame.
• Target and interaction scripts with many zones checked in loops.
• NPC and world scripts that manage many peds or props.
• Scripts with markers drawn every frame for every location on the map, even far away.
• Old versions of anything. Many performance fixes arrive in updates.

This is not a list of bad resources. It is where to look first.

Stop and compare

On a test server, stop a suspect resource and measure again. If the total drops and the lag goes away, you found it. Never test this on a live server with players: stopping resources can break characters, inventories or vehicles.

What good scripts do differently

You do not need to write Lua to recognise good habits. When you read a script, or ask the author, look for these:

They wait instead of looping

A loop that runs every frame (Wait(0)) is sometimes needed, for example to draw something on screen. But it should only run while it is needed. A good script checks every second or so whether the player is near something, and only then switches to a fast loop.

They react to events

Instead of checking "is the player in a vehicle?" 60 times per second, a good script listens for the moment the player enters a vehicle. Frameworks and libraries such as ox_lib offer events and caches for this.

They use zones and points

Checking the distance to 200 shops every frame is expensive. Libraries that provide zones and points only notify the script when the player comes close.

They cache values

Reading the player’s ped, position or vehicle in many places each frame adds up. Reading once and reusing the value is cheaper.

They keep NUI quiet

A web UI that receives messages every frame costs CPU on the client. Good UIs update when a value changes.

They do heavy work on the server

Things like database queries and payouts belong on the server, done once, not repeated on every client.

Reading the memory column

Memory is less important than CPU time, but it still tells you something. A resource that holds a few megabytes is normal, especially one with a large UI. What matters is how the number changes over time.

• Stable memory after the first few minutes is what you want.
• Memory that keeps climbing during a long session, and only drops after a restart, often means the resource keeps data it no longer needs, for example a table that grows every time something happens. On a server that runs all day, that can end in stutters or crashes for players who stay online for hours.
• A sudden jump when you open a menu or start a job is normal, as long as it comes back down.

Check it the same way as CPU time: note the value after joining, play for an hour, and look again.

Server performance is a separate question

Resmon shows the client. Rubber-banding, desync and slow actions often come from the server side: too many networked entities, slow database queries or a resource that blocks the server thread.

FiveM’s server has a built-in profiler you can start from the server console to record a short period and inspect it. Your hosting panel or txAdmin also shows server CPU and memory. The rules are similar: know your baseline, measure after each change, and check what is at the top.

Database queries deserve a special mention. A resource that runs a slow query every few seconds for every player can make the whole server wait. Look for missing indexes, huge tables of old logs, and scripts that save data far more often than needed.

A monthly performance routine

A short routine keeps a server healthy:

1. Update your artifacts, framework and resources on a test server first.
2. Restart and record the top ten in resmon, idle, in your busiest area.
3. Compare with last month.
4. Remove resources nobody uses.
5. Clean old log tables in the database.
6. Check the server console after a restart. Fix red lines.

It takes less than an hour and prevents most "the server got slow" weeks.

How we handle it

Every product page lists the resources a script needs. Because our scripts come with the full source, you can see exactly what runs and how often. That also means a performance problem is something you or your developer can find and fix, rather than wait for. Read more in escrow vs open source FiveM scripts.

If you are building out a GTA 6 inspired server, performance is the part that keeps it enjoyable. The Vice City checklist, the HUD guide and living NPCs and AI all come back to it. For a clean base, see the QBCore and QBox setup guide and how to install a FiveM script.

Browse our FiveM scripts, by framework under QBCore, QBox and ESX, or start with the free scripts. If one of our scripts shows a high value on your server, send the resmon screenshot to support.