Intermédiaire ⏱ 12 min Mis à jour le 29 juillet 2026

Réduire le lag et optimiser votre serveur FiveM avec resmon

Un serveur FiveM qui lag ruine l'immersion RP. Bonne nouvelle : resmon vous montre exactement quel script pose problème. Voici comment diagnostiquer et optimiser.

D’où vient le lag sur un serveur FiveM ?

Optimiser un serveur FiveM commence par identifier la nature exacte du ralentissement. Un manque de fluidité ne vient pas toujours de l’hébergement : les scripts mal optimisés, les requêtes SQL lentes, les entités trop nombreuses et les interfaces chargées sont souvent responsables.

Il faut distinguer plusieurs problèmes :

Symptôme	Cause probable
Baisse des FPS chez un joueur	Script client, interface NUI, mapping ou véhicule lourd
Ralentissement pour tous les joueurs	Script serveur, surcharge CPU, base SQL ou trop d’entités
Actions exécutées avec retard	Hitch serveur, boucle bloquante ou requête lente
Joueurs ou véhicules désynchronisés	OneSync, réseau ou script d’entités
Chargement très long	Ressources trop volumineuses ou fichiers mal optimisés

resmon analyse principalement les ressources exécutées sur le client du joueur. Il est donc très utile pour trouver un script qui consomme trop de temps CPU côté client, mais il ne remplace pas la surveillance du serveur dans txAdmin.

Pour un diagnostic complet, combinez :

resmon pour les scripts côté client ;
la console pour les erreurs et hitch warnings ;
txAdmin pour l’utilisation globale du CPU et de la RAM ;
le profiler FiveM pour rechercher une fonction ou une ligne de code précise.

Ajouter de la RAM ne corrige pas une boucle exécutée inutilement à chaque image. Il faut d’abord trouver la ressource responsable.

Ouvrir `resmon` dans FiveM

Connectez-vous au serveur, puis appuyez sur F8 pour ouvrir la console du client FiveM.

Saisissez :

resmon true

Le moniteur de ressources s’affiche à l’écran. Il présente les ressources actives et plusieurs indicateurs, notamment :

leur consommation CPU en millisecondes ;
leur utilisation de la mémoire ;
l’évolution de leur activité ;
leur nom exact.

Pour fermer le moniteur :

resmon false

Laissez resmon ouvert pendant que vous reproduisez le problème. Par exemple, ouvrez le menu qui fait chuter les FPS, sortez un véhicule, approchez-vous du mapping concerné ou utilisez le métier qui semble provoquer le ralentissement.

Une mesure réalisée en restant immobile dans une zone vide n’est pas suffisante. Certains scripts deviennent gourmands uniquement lorsqu’une action précise est déclenchée.

Les résultats peuvent varier selon l’ordinateur du joueur. Testez si possible avec plusieurs clients afin de distinguer un problème général d’une configuration locale insuffisante.

Si la console affiche un refus d’accès à la commande, votre version du client peut exiger l’activation du mode développeur. Pour un diagnostic courant, commencez toutefois par vérifier que FiveM est à jour et que la commande exacte resmon true est utilisée.

Lire les millisecondes par ressource

La valeur en millisecondes indique le temps CPU consommé par une ressource lors de ses exécutions répétées. Plus cette valeur reste élevée, plus le script peut réduire la fluidité du client.

Un tick correspond à un cycle d’exécution. Certains scripts effectuent une vérification à chaque image, tandis que d’autres attendent plusieurs centaines de millisecondes entre deux traitements.

Les valeurs doivent être interprétées comme des repères, et non comme des limites absolues :

Valeur observée	Interprétation indicative
Moins de `0,10 ms`	Ressource généralement légère
De `0,10 à 0,50 ms`	Consommation souvent acceptable
De `0,50 à 1 ms`	À surveiller si la valeur reste constante
Plus de `1 ms`	Ressource à examiner
Plus de `2 ms` en continu	Impact client potentiellement important

Une pointe occasionnelle n’est pas forcément inquiétante. Un menu peut consommer davantage lors de son ouverture, puis revenir immédiatement à une valeur faible.

En revanche, une ressource affichant continuellement 1 à 2 ms, même lorsqu’elle n’est pas utilisée, mérite une vérification. Plusieurs scripts consommant chacun une petite quantité peuvent également produire un ralentissement cumulé.

Exemple :

script_metier       1,40 ms
inventaire          0,85 ms
telephone           0,70 ms
hud                  0,55 ms

Aucune ressource ne semble catastrophique isolément, mais l’ensemble représente déjà une charge importante.

Les couleurs de resmon permettent de repérer rapidement les ressources les plus actives. Ne vous contentez toutefois pas de la couleur : observez la valeur, sa durée et l’action qui la déclenche.

La mémoire doit aussi être surveillée. Une utilisation élevée n’indique pas automatiquement une fuite, mais une valeur qui augmente continuellement sans redescendre peut révéler des textures, objets ou interfaces qui ne sont jamais libérés.

Identifier et traiter les scripts gourmands

Commencez par noter le nom exact des ressources les plus consommatrices. Désactivez ensuite une ressource suspecte sur une instance de test afin de vérifier si le problème disparaît.

Depuis la console txAdmin :

stop nom_de_la_ressource

Pour la relancer :

start nom_de_la_ressource

Ou pour la redémarrer :

restart nom_de_la_ressource

Ne désactivez pas au hasard un framework, un inventaire ou une ressource essentielle sur un serveur public. Effectuez vos essais pendant une maintenance ou sur une copie de test.

Des sauvegardes automatiques sont incluses pour vous aider à restaurer. Conservez aussi vos propres exports réguliers : vous restez responsable de vos données.

Si la consommation baisse après l’arrêt de la ressource, vérifiez :

si une version plus récente existe ;
si sa configuration permet de réduire la fréquence des vérifications ;
si des fonctions inutilisées peuvent être désactivées ;
si le développeur propose une correction ;
si une alternative mieux optimisée est disponible.

Une boucle Lua mal conçue peut ressembler à ceci :

CreateThread(function()
    while true do
        Wait(0)
        verifierToutesLesEntites()
    end
end)

Wait(0) demande une exécution à chaque image. Si la vérification est lourde et n’a pas besoin d’être instantanée, un délai plus long réduit fortement la charge :

CreateThread(function()
    while true do
        Wait(1000)
        verifierToutesLesEntites()
    end
end)

La fréquence doit être adaptée à la fonction. Une interface nécessitant une réaction immédiate ne peut pas toujours attendre une seconde, mais un contrôle périodique de proximité n’a généralement pas besoin de s’exécuter à chaque image.

Les optimisations fréquentes consistent à :

augmenter raisonnablement les délais des boucles ;
ne lancer les calculs que lorsque le joueur est concerné ;
mettre en cache les données réutilisées ;
éviter de parcourir toutes les entités en permanence ;
limiter les messages envoyés aux interfaces NUI ;
regrouper les requêtes SQL ;
supprimer les événements déclenchés inutilement.

Comprendre l’importance du CPU par cœur

FiveM utilise plusieurs threads, mais certaines tâches critiques restent très sensibles aux performances d’un cœur principal. Une fréquence élevée et une bonne performance par cœur comptent donc souvent davantage qu’un grand nombre de cœurs peu rapides.

Lorsqu’un traitement principal prend trop de temps, le serveur peut afficher un hitch warning. Les joueurs observent alors des actions retardées, des téléportations, des véhicules qui réagissent mal ou des scripts qui répondent plusieurs secondes trop tard.

La puissance du CPU devient particulièrement importante lorsque le serveur utilise :

de nombreux scripts actifs ;
beaucoup de joueurs simultanés ;
une grande quantité d’entités ;
des systèmes économiques complexes ;
des traitements fréquents côté serveur ;
des requêtes SQL synchrones ou mal optimisées.

Cela ne signifie pas que le matériel est toujours responsable. Un script bloquant peut saturer un excellent processeur, tandis qu’un serveur correctement optimisé peut accueillir davantage de joueurs avec une consommation maîtrisée.

Dans txAdmin, surveillez l’utilisation du CPU, de la RAM et les redémarrages. Consultez également la console à la recherche de messages comme :

server thread hitch warning

SCRIPT ERROR

query took

Pour apprendre à surveiller et administrer FXServer, consultez le guide pour démarrer avec txAdmin.

Autres optimisations pour réduire le lag FiveM

Une fois les scripts gourmands identifiés, vérifiez l’ensemble de la configuration.

Limiter les entités

Les véhicules abandonnés, PNJ, objets et props permanents augmentent le travail de synchronisation. Configurez vos scripts pour supprimer les entités inutiles et éviter les créations en double.

Configurer correctement OneSync

OneSync améliore la gestion serveur des joueurs et des entités, mais les scripts doivent être compatibles. Une ressource ancienne peut créer des doublons ou effectuer des traitements inutiles pour tous les joueurs.

Garder les artifacts à jour

Des artifacts FXServer obsolètes peuvent provoquer des incompatibilités ou vous priver de corrections importantes. Utilisez de préférence une version recommandée et testez toute mise à jour avant de l’appliquer en production.

Optimiser la base de données

Les requêtes répétitives ou mal indexées peuvent ralentir les actions liées aux personnages, inventaires, véhicules et métiers. Vérifiez les avertissements SQL et évitez de solliciter la base à chaque tick.

Réduire les ressources inutiles

Le nombre de scripts n’est pas le seul indicateur important, mais chaque ressource ajoute des traitements, des événements et des fichiers à charger. Supprimez les anciens scripts, les doublons et les fonctionnalités jamais utilisées.

En résumé

Pour optimiser un serveur FiveM, commencez par distinguer un problème client, serveur, réseau ou SQL.
Ouvrez la console avec F8, puis saisissez resmon true.
Utilisez resmon false pour fermer le moniteur.
Reproduisez le ralentissement pendant que le moniteur est affiché.
Une ressource dépassant continuellement 1 à 2 ms doit être examinée.
Une pointe occasionnelle est moins préoccupante qu’une consommation élevée permanente.
Désactivez temporairement la ressource suspecte sur une instance de test pour confirmer le diagnostic.
Recherchez les boucles trop fréquentes, les traitements d’entités et les mises à jour NUI inutiles.
Surveillez également les hitch warnings, le CPU, la RAM et les requêtes SQL dans txAdmin.
Privilégiez une bonne performance CPU par cœur, sans considérer le matériel comme l’unique solution.
Limitez les entités, maintenez OneSync et les artifacts à jour, puis retirez les scripts inutilisés.
Pour optimiser un serveur FiveM avec une infrastructure hébergée en France, un stockage NVMe, un panel de gestion et un Anti-DDoS L3/L4/L7 inclus, consultez l’offre serveur FiveM TalCloud.