How to Optimise Your FiveM Server for Performance [2026]

Why Does FiveM Server Performance Matter?

A laggy, poorly optimised FiveM server kills roleplay. High ping, stuttering, script errors, and random crashes drive players away faster than anything else. Performance optimisation is the difference between a server players recommend to their friends — and one they quietly leave.

Poor server performance is caused by:

• Too many poorly written scripts running simultaneously
• Unoptimised database queries causing bottlenecks
• Missing or bloated MLO/vehicle assets causing client lag
• Memory leaks from scripts that never clean up after themselves
• No scheduled restarts — servers degrade over time without them
• Overpowered features running on underpowered hardware
• Streamed assets that are too large or too numerous

The good news: most performance issues are fixable. This guide walks you through every layer of FiveM server optimisation — from hardware to code.

Why Server Optimisation Should Be a Priority

Did you know? All scripts and MLOs on FiveVault are reviewed for quality and optimisation before being listed. Poorly coded resources won't make it onto the platform. Browse all resources →

Prerequisites

Step 1: Audit Your Resource List

The single biggest performance drain on most servers is running too many resources — especially ones that are broken, duplicated, or simply unused.

Open your server.cfg and go through every ensure line:

# Ask yourself for each resource:
# 1. Is this actually used by players?
# 2. Is there a newer, lighter alternative?
# 3. Are two resources doing the same thing?
# 4. Was this installed for testing and never removed?

-- Old, abandoned ESX resources with no updates since 2021
-- Duplicate notification systems (esx_notify AND mythic_notify)
-- Multiple phone scripts running at the same time
-- Test resources left over from development
-- Three different admin menus when you only use one

Pro tip: Use txAdmin's Resources tab to see exactly which resources are running, which have errors, and how long each one took to start. Resources that take 5+ seconds to start are worth investigating.

Step 2: Replace Heavy Scripts With Lightweight Alternatives

Many popular older scripts were written before performance was a priority. Swapping them out for modern equivalents is one of the highest-impact changes you can make.

Step 3: Optimise Your Database

The database is the most overlooked performance bottleneck on FiveM servers. Every inventory save, character load, and job check goes through it.

ensure oxmysql
ensure es_extended   # or qb-core

Add these optimisation settings to your server.cfg:

set mysql_connection_string "mysql://user:password@localhost/fivem_db?charset=utf8mb4"
set mysql_slow_query_warning 200

-- Remove old, unused character data
DELETE FROM users WHERE last_login < DATE_SUB(NOW(), INTERVAL 180 DAY);

-- Optimise all tables
OPTIMIZE TABLE users;
OPTIMIZE TABLE user_accounts;
OPTIMIZE TABLE user_inventory;
OPTIMIZE TABLE owned_vehicles;

Pro tip: Add database indexes to columns your scripts query frequently. The identifier column in users should always be indexed — most frameworks handle this automatically, but always double-check.

Step 4: Fix Lua Performance Issues in Scripts

Badly written Lua is a major cause of server tick rate drops. The two biggest offenders are infinite loops and unthrottled event handlers.

Citizen.CreateThread(function()
    while true do
        Citizen.Wait(0)   -- runs 60 times per second, always
        checkSomething()
    end
end)

Citizen.CreateThread(function()
    while true do
        Citizen.Wait(1000)   -- runs once per second
        checkSomething()
    end
end)

-- ❌ Firing events to "all players" every second
TriggerClientEvent('myScript:update', -1, data)

-- ✅ Only trigger to the specific player who needs it
TriggerClientEvent('myScript:update', playerId, data)

Pro tip: Any script with Citizen.Wait(0) inside a permanent loop is a red flag. Open the Lua files and search for Wait(0) across your resources — every hit is a potential frame-rate killer.

Step 5: Optimise Streamed Assets

Every custom vehicle, MLO, ped, and weapon adds to your client download size and streaming overhead. Too many assets causes:

• Long join times for new players
• In-game texture pop-in and stuttering
• Client-side memory pressure on lower-end PCs

resources/
└── [vehicles]/
    ├── police-pack-2026/    ← keep packs bundled, not 50 individual cars
    └── civilian-pack/

└── [mapmods]/
    ├── police-station/
    └── hospital/

• Vehicle .ytd files should ideally be under 10MB each
• MLO stream/ folders over 100MB are considered large — check for uncompressed textures
• Avoid duplicate .ytd files — the same texture pack loaded twice doubles the RAM cost

Pro tip: Use OpenIV to inspect .ytd texture files. Textures larger than 2048x2048 are overkill for most RP use — resizing to 1024x1024 can cut file sizes by 75%.

Step 6: Set Up Scheduled Restarts

Servers accumulate memory leaks, orphaned threads, and database connection buildup over time. No matter how well-optimised your scripts are, a server running for 48 hours straight will perform worse than one that restarted 6 hours ago.

04:00 AM  →  Restart  (quietest time — minimal disruption)
10:00 AM  →  Restart
04:00 PM  →  Restart
10:00 PM  →  Restart

Enable restart warnings in txAdmin so players get notified 15 minutes, 5 minutes, and 1 minute before each restart.

Pro tip: Pair scheduled restarts with a Discord webhook notification so your community always knows when a restart is coming — this reduces player complaints significantly.

Step 7: Tune Your server.cfg for Performance

Several server.cfg settings have a direct impact on performance. Add or update these:

# Limit max clients to what your hardware can handle
sv_maxclients 64

# OneSync — required for 32+ player servers
onesync on

# Endpoint binding — explicit is faster than automatic
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# Steam tickets — disable if you don't need Steam auth
sv_authMaxVariance 1
sv_authMinTrust 5

# Reduce heartbeat spam
sv_heartbeat 30

# License key — always keep this set correctly
sv_licenseKey "your_key_here"

Step 8: Monitor Performance Over Time

Optimisation isn't a one-time job — it's ongoing. Use these tools to keep an eye on your server health:

• Watch the player count vs. CPU graph — if CPU spikes with more players, you have script-level scaling issues
• Check the memory usage — if it climbs steadily without restarting, you have a memory leak

resmon 1

This enables the resource monitor — it shows CPU time per resource in milliseconds. Any resource using more than 1ms consistently is worth investigating.

netgraph 1

This shows network stats — useful for spotting scripts that are sending too much data to clients.

Pro tip: Screenshot your resmon output on a fresh server restart and again after 6 hours of uptime. Resources that grew significantly are your leak suspects.

Performance Checklist

Troubleshooting Common Performance Issues

❌ Server ping is high for all players

❌ Server crashes after 6–12 hours of uptime

❌ Players experience rubber-banding during peak hours

❌ resmon shows one script using 5ms+ consistently

❌ New players take 5+ minutes to load in

❌ Database queries timing out

Recommended Performance Tools & Scripts

Final Tips

• ✅ Run resmon 1 in your console regularly — know your resource costs
• ✅ Replace mysql-async with oxmysql — this alone can dramatically improve DB performance
• ✅ Enable OneSync — it's not optional for any serious server above 32 players
• ✅ Schedule 4 restarts per day — no script is leak-free forever
• ✅ Audit your resource list every month — remove anything you're not actively using
• ✅ Keep streamed assets under 2GB total — your players' load times depend on it
• ✅ Source scripts from FiveVault — every resource is quality-checked before listing
• ✅ Test changes on a dev server — never optimise directly on your live production server

Frequently Asked Questions

A: There's no hard limit — it depends on script quality and your hardware. A server with 50 well-written scripts will outperform one with 150 poorly written ones. Focus on quality over quantity.

A: No. OneSync is free and built into FiveM. You just need to add onesync on to your server.cfg. It's enabled by default on most modern hosting setups.

A: txAdmin's scheduler includes automatic warnings — players get notified 15, 5, and 1 minute before the restart. Most players plan around it and the disruption is minimal.

A: Run resmon 1 in your Live Console. It shows CPU time in milliseconds for every running resource. Anything above 1ms consistently is worth investigating.

A: If you've optimised scripts, database, and assets but still have issues at peak player counts — yes. Hardware is the ceiling; optimisation raises how close you can get to it.

A: MLOs are mostly client-side, so they affect player FPS rather than server tick rate. However, MLOs with broken portals or excessive draw calls can cause client crashes that flood your server with reconnect attempts.