Optimisation d'un serveur FiveM : réduire le lag et gagner en performances

Rien ne tue une communauté roleplay plus vite que le lag. Les joueurs pardonnent les fonctionnalités manquantes ; ils ne pardonnent pas le rubber-banding en pleine course-poursuite. La bonne nouvelle : la plupart des problèmes de performances sur FiveM se corrigent dès qu’on sait les mesurer. Ce guide vous montre comment.

D’abord, apprendre à mesurer : resmon

On ne peut pas optimiser ce qu’on ne voit pas. Le moniteur de ressources intégré à FiveM est votre outil le plus important.

Ouvrez la console et lancez :

resmon

Vous verrez chaque ressource en cours et son temps CPU par frame en millisecondes (ms). C’est ce chiffre qui compte. Quelques repères :

• Sous 0,5 ms — sain pour un script actif.
• 0,5–1,0 ms — acceptable, à surveiller.
• Au-dessus de 2–3 ms en continu — un problème ; profilez-le.

Comprendre les deux faces des performances

Les performances FiveM ont un versant serveur et un versant client.

• Le coût serveur touche tout le monde et vient souvent des requêtes en base, des grosses boucles et du spam d’événements.
• Le coût client touche les FPS de chaque joueur et vient d’UI lourdes à rendre, de boucles Citizen.Wait(0) permanentes et d’entités sans culling.

Une ressource peut être légère côté serveur et massacrer les FPS client, ou l’inverse. Vérifiez toujours les deux.

Les gains les plus importants et les plus courants

1. Supprimez les boucles serrées

Le tueur de performances classique sur FiveM, c’est un thread qui tourne à chaque frame sans en avoir besoin :

-- Mauvais : tourne à chaque frame, indéfiniment
CreateThread(function()
  while true do
    Wait(0)
    -- vérifications de distance, dessin de marqueurs, etc.
  end
end)

La plupart peuvent attendre plus longtemps, dormir quand le joueur est loin, ou passer en événementiel. Faire passer Wait(0) à Wait(500) quand rien ne se passe peut réduire le coût d’une ressource de 90 %.

2. Remplacez le polling par des événements

Si un script vérifie en permanence si quelque chose s’est produit, voyez si le framework peut le lui dire. Le code événementiel dort jusqu’à ce qu’on ait besoin de lui et ne coûte rien au repos.

3. Corrigez vos habitudes en base de données

Interroger MySQL dans une boucle, ou à chaque tick joueur, met à genoux un serveur chargé. Groupez les requêtes, mettez en cache les valeurs qui bougent peu, et utilisez correctement les patterns asynchrones d’oxmysql.

4. Auditez vos UI les plus lourdes

La NUI (la couche d’interface basée navigateur) est puissante et facile à maltraiter. Un HUD qui se re-rend en continu, ou un inventaire qui ne limite jamais ses mises à jour, grignote les FPS client en silence. Les systèmes bien construits ne mettent à jour le DOM que quand les valeurs changent vraiment.

Choisissez des ressources centrales optimisées dès le départ

La vérité qui dérange : les ressources que vous choisissez pèsent plus que n’importe quel réglage appliqué ensuite. Votre inventaire, votre HUD et les autres systèmes toujours actifs tournent pour chaque joueur, en permanence : leur coût par frame fixe votre plancher.

Pour évaluer une ressource toujours active, cherchez :

• Une valeur resmon basse et stable en charge (pas seulement au repos).
• Une NUI efficace, qui se met à jour au changement et non sur minuterie.
• Une logique serveur qui groupe le travail en base.
• Une maintenance active et un historique d’optimisation.

C’est exactement pour ça que beaucoup de communautés établies standardisent un petit ensemble de systèmes premium éprouvés — un inventaire bien optimisé comme Quasar Inventory, par exemple, est conçu pour garder une empreinte faible même dans une ville pleine, ce qui libère votre budget de performances pour le reste. Nous détaillons les meilleures options dans notre guide des meilleurs inventaires.

Un flux d’optimisation reproductible

1. Mesure de référence. Notez votre resmon total à un nombre de joueurs réaliste.
2. Triez par coût. Identifiez les cinq ressources les plus lourdes.
3. Profilez la pire. Utilisez resmon et le profiler serveur.
4. Corrigez ou remplacez. Optimisez la boucle, ou passez à une alternative plus légère.
5. Re-mesurez. Confirmez le gain, puis recommencez.

Faites-le tous les mois et votre serveur reste rapide en grandissant, au lieu de se dégrader lentement jusqu’au départ des joueurs.

Checklist rapide d’optimisation

• Aucune ressource au-dessus de 2–3 ms sans raison.
• Wait() modulé par la distance sur les scripts de proximité.
• Logique événementielle plutôt que polling permanent.
• Requêtes en base groupées et mises en cache.
• NUI légère et pilotée par le changement pour le HUD et l’inventaire.
• Audits resmon réguliers à pleine charge.

L’optimisation n’est pas une tâche ponctuelle — c’est une habitude. Prenez-la tôt, choisissez des ressources centrales efficaces, et votre ville roleplay restera fluide quelle que soit sa taille. Ensuite, assurez-vous que vos fondations sont bonnes avec notre comparatif de frameworks.