Why your FiveM server lags: diagnosing client vs server

“It’s lagging.” Two words that tell you nothing. Behind them sit three distinct problems, with different causes, different people responsible, and fixes that have nothing in common. Until you know which one you’re actually suffering from, you’re guessing.

This guide gives you the method: separate the symptoms, measure them with FiveM’s built-in tools, and know what to do depending on whether you’re a player or a server owner.

Three “lags” that have nothing to do with each other

Symptom	What it really is	Where it happens	How to measure
Constantly choppy image, mushy camera movement	Low FPS	Your PC (GPU/CPU)	FPS counter
Other players teleporting, your car rubber-banding	Ping / network	Between you and the server	netgraph
Everyone freezing at the same moment, in regular bursts	Server tick / hitching	The server	The server console and its profiler

The quickest test to split client from server: is it happening to everyone at once? If the server’s Discord fills up with “are you freezing too?” at the same second, it isn’t your PC. If you’re the only one, stop looking at the server.

Low FPS: that’s your machine

FPS measures how many frames your PC renders per second. No server on earth can give you frames. If your image feels sluggish but other players move smoothly and consistently, the problem is local.

The budget is easy to remember: at 60 frames per second, your PC has roughly 16.6 ms per frame to do everything — rendering, physics, scripts. That number is what gives the rest of this article its meaning.

The usual causes, in order of how often they’re the answer:

• Too many streamed assets. A server pushing hundreds of add-on vehicles, MLOs and clothing packs fills your video memory. When it overflows, you don’t lose 5 % of performance — you get hard stutter.
• Textures. A badly optimised vehicle pack ships .ytd files at absurd resolutions for parts nobody ever sees. It’s the single biggest source of waste on community servers.
• Shadows and draw distance. In a chase game these are the two most expensive and least useful settings. Drop them first.
• An underpowered machine, plain and simple — see our PC requirements guide for FiveM on GTA 5 Enhanced.

Ping: that’s the network

Ping is the round-trip time between your client and the server. It doesn’t degrade your frame rate — it degrades the consistency of what you see.

Open the console with F8 and type:

netgraph 1

You get a live graph of your connection to the server. What you’re looking for isn’t so much the average value as its stability: a high but perfectly flat ping stays playable, your brain compensates. A ping that saws up and down, or actual packet loss, produces exactly that “players teleporting” feeling and cars snapping backwards.

Typical signatures:

• Visible packet loss → a problem with your connection (Wi-Fi, saturated router, housemate downloading) or with the network path. Go wired before anything else.
• High but stable ping → geographic distance. A server hosted on the other side of the world can’t be fixed from the client side.
• Ping that only spikes as the server fills up → that one isn’t you. That’s a server failing to carry its population.

resmon: the tool that names names

This is the only tool that points at a specific culprit. In the F8 console:

resmon 1

You get the list of loaded resources with, for each one, its CPU time in milliseconds. That’s the column that matters. The others (memory, streaming) are useful, but CPU time is what produces hitching.

How to read the numbers:

• Below 0.05 ms: negligible, don’t waste your time.
• Around 0.10 to 0.50 ms: normal for an active resource that’s genuinely doing something.
• Above ~1 ms: always worth a look. Against a 16.6 ms frame budget, a single resource at 1 ms is already eating 6 % of the available time — and a server runs dozens of them.
• Several ms sustained: you’ve found your problem, stop looking elsewhere.

The key habit: check the value at rest, when you’re doing nothing. A resource costing 2 ms while you’re using its menu is fine. That same resource at 2 ms while you stand idle in the middle of a street touching nothing is a per-frame loop left running permanently. It’s by far the most common cause of lost performance, and it’s almost always one guilty resource rather than “the server in general”.

One caveat: resmon is a client command. It measures what resources cost on your machine, not the time spent inside the server tick. For that, you need the server console and its profiler.

The classic server-side causes

If you run a server, these are the four culprits to know by heart. They’re the ones we ban from our own codebase.

1. Permanent per-frame loops. A Citizen.Wait(0) inside a while true runs every single frame, forever, even when the feature it belongs to isn’t being used. The healthy rule: a per-frame loop must be conditional — active only while the feature is engaged (menu open, game mode running) — and dropped to a slow cadence, on the order of 250 to 500 ms, the rest of the time. Gameplay detection runs perfectly well at ~100 ms; a HUD is fine at 100 to 200 ms.

2. SQL inside a tick. A database query in a game loop, or in a handler called at high frequency, guarantees periodic freezes. The right model: an in-memory cache loaded when the player connects, writes on events only (end of round, confirmed purchase), never inside a loop.

3. Broadcasting to every player. Firing an event at 100 players several times a second means 100 network serialisations, over and over. Lists (scoreboard, connected players) should be pulled on demand by the client, not pushed to everyone in a loop.

4. Too many entities. Abandoned vehicles, NPCs, props dropped on the ground: every entity costs synchronisation. A server that never cleans up degrades slowly, which makes the problem hard to trace back to a cause.

There’s also a NUI-specific trap: sending a message to the interface every frame. Each message is serialised to JSON and shipped to the embedded browser process. Throttle it, and only send state changes.

What to actually do

If you’re a player:

1. First check whether others have the same thing. That eliminates half the hypotheses in ten seconds.
2. Lower shadows and draw distance before anything else.
3. Go wired if you see packet loss on the netgraph.
4. Clear your FiveM cache if the problem appeared out of nowhere — the steps are in our FiveM crashing guide.
5. If one specific server is sluggish for everyone, all the time: you can’t fix that from your side. Move on or report it.

If you run a server:

1. Run resmon and sort by CPU time. Don’t guess, measure.
2. Stop the most expensive resource and see whether the problem disappears. Blunt bisection is still the fastest method there is.
3. In the offending code, hunt for Wait(0) and SQL queries before anything else.
4. Test under load. An empty server tells you nothing: broadcasts and synchronisation only cost you once there are players in it.
5. Never change two things at once, or you won’t know which one helped.

And above all: a sluggish server loses players faster than a server short on content. It’s the first investment to make, not the last. If you’re building one, our honest guide to creating a FiveM server in 2026 covers what genuinely matters when choosing a machine.

On our side, performance is a writing constraint rather than a cleanup job: Chased is a single standalone resource built for Enhanced, with no asset debt and no permanent per-frame loops. The concept fits in one line — 1v1 hunter-versus-hunted duels in a randomly drawn shared car, where the only variable is your driving. No heavy streaming, no dependencies: when a race is decided by a tenth of a second, smoothness is part of the gameplay. Still weighing up which version to target? Our Legacy or Enhanced comparison will settle it.