The server simulates the world in ticks; your scripts share that tick budget. Lag appears when something blocks the budget (heavy loops, synchronous queries), floods the network (event spam, oversized payloads), or overloads the client (streamed asset bloat, runaway NUI). Hosting is only the cause when the box is genuinely undersized, which an hour of profiling will tell you definitively.
Quick answer
Profile before you spend: open resmon (F8 → resmon true), sort by CPU msec, and fix the top three offenders, they are usually a script doing work every tick, an unindexed SQL query on a hot path, or an oversized streamed asset pack. Most servers recover more headroom from one resmon session than from a hosting upgrade.
Why FiveM servers lag
Resource timing and resmon
resmon true in the F8 console is your first tool. Read the CPU msec column at idle and under load: above 0.5ms idle deserves a look, above 2ms is a problem, and anything spiking during specific actions (opening inventory, entering a zone) names its own suspect. Screenshot idle and loaded states, the diff is your work list.
The classic offender pattern: a CreateThread loop with Wait(0) doing distance checks against every player, every frame. Raise sleeps adaptively (5–10ms near, 500–1000ms far) and event-drive what you can.
SQL and database hotspots
Database stalls feel like server lag because joins, job actions, and saves block on them. Three checks: enable oxmysql's slow-query warnings and treat anything over 50ms as a bug; ensure indexes on every player-lookup column (identifier, citizenid, license, vehicle plate); and find queries inside loops, a save loop that fires one query per item per player will melt a 200k-row table.
Batch writes, cache reads that cannot change mid-session, and never query in a tick handler.
Streamed asset bloat
Every MLO, vehicle, and clothing pack you stream is download time on join and memory on the client. Audit your stream/ folders: a single 60MB MLO for a building nobody visits is pure cost. Compress textures (most packs ship 4K where 1K reads identically in game), remove duplicate vehicle audio, and delete the packs your city stopped using. Target: a fresh client joins in under two minutes.
Bad script patterns to hunt
The repeat offenders we find in audits: per-frame distance loops without adaptive waits; event handlers registered multiple times (each reconnect adds another); TriggerClientEvent to -1 (everyone) for things only nearby players need; NUI pages running full React apps that re-render on a timer; and 'standalone' scripts that each open their own database pool until the server holds 30 connections.
The checklist
- resmon screenshots: idle and under load, sorted by CPU msec
- Everything above 0.5ms idle listed with an owner and a fix date
- oxmysql slow-query log enabled; zero queries over 50ms on hot paths
- Indexes verified on identifier / citizenid / license / plate columns
- stream/ folders audited; total fresh-join download under target
- Scheduled restarts twice daily; memory graphed between them
- Event audit: nothing broadcasting to -1 that only nearby players need
| Symptom | Likely cause | First check |
|---|---|---|
| Rhythmic hitch every few seconds | Tick-loop script | resmon CPU column |
| Slow or stalling joins | Unindexed SQL / asset bloat | slow-query log, stream size |
| Lag only near certain places | Heavy MLO or zone script | enter zone, watch resmon |
| Degrades until restart | Memory leak / handler stacking | memory graph between restarts |
| Everyone lags when one player acts | Event broadcast to -1 | grep TriggerClientEvent -1 |
Common mistakes
Upgrading hosting before profiling. Blaming the framework for the five scripts added last week. Deleting random resources in panic instead of measuring. Running 30 standalone scripts with 30 database pools. Streaming 4K textures players cannot tell from 1K.
The Quasar recommendation
Optimization is a habit, not an event: profile after every content drop, keep a budget (no script ships above 0.3ms idle), and let data, not vibes, choose what gets fixed. Roughly 80% of the lag tickets we audit are script-side and fixable in a weekend. If your top offenders are paid scripts, ask the authors for patched builds before replacing them.
Latest in this cluster
Is OneSync the cause of my lag?
Rarely. OneSync changes entity ownership behavior, but tick time is dominated by scripts and SQL in almost every audit we run. Profile first.
What is a healthy player capacity for one box?
A clean build holds 64–128 slots comfortably on a modern 4–8 core VPS. Capacity falls to 30–40 on the same hardware when the script stack is unprofiled, which is exactly why profiling beats upgrading.
Do server-side mods like 'anti-lag' scripts help?
Mostly no, many add their own tick cost. Fix causes (loops, queries, assets) rather than installing another resource that promises to fix symptoms.
Want this handled with you, not alone?
Get a concrete plan for your server, or have us look at what you have built so far.