Snel antwoord: Resmon is de client-side resource monitor van FiveM. Open de F8-console en voer resmon true uit om de resourcekosten op de client te inspecteren. Gebruik het om dure scripts, maps, HUDs en UI-resources te vinden voordat je gokt wat een lage FPS veroorzaakt.
Laatst bijgewerkt: 25 juni 2026
Open Resmon
- Voeg je server toe.
- Pers
F8. - Voer uit:
resmon true
Als de toegang wordt geweigerd, vermeldt de Cfx.re-documentatie dat de ontwikkelaarsmodus mogelijk vereist is voor sommige diagnostiek. Test op een ontwikkelclient of gebruik de profiler voor diepere debugging.
Wat Resmon je vertelt

| Kolom/signaal | Betekenis |
|---|---|
| CPU msec | Hoeveel client-CPU-tijd een resource verbruikt. |
| Geheugen | Hoeveel geheugen de resource op de client gebruikt. |
| Spikes | Korte uitbarstingen die kunnen optreden tijdens UI, streaming of loops. |
| Constante hoge kosten | Een resource die waarschijnlijk code- of assetwerk nodig heeft. |
Praktische testmethode
- Ga op een rustige locatie staan en noteer de duurste resources.
- Ga naar een druk stadsgebied, MLO of een locatie met veel voertuigen.
- Open menu's, inventaris, telefoon, HUD en job UI één voor één.
- Noteer welke resource piekt en welke actie dit veroorzaakte.
- Schakel één verdachte resource uit in de staging en herhaal dezelfde test.
Wanneer de profiler gebruiken
Gebruik Resmon voor snelle triage. Gebruik de Cfx.re-profiler wanneer je regel- of diepere resource-debugging nodig hebt. De profiler is beter wanneer een resource consistent duur is, maar de reden niet duidelijk is uit de gameplay.
Veelvoorkomende oorzaken van hoge Resmon-waarden
- Loops zonder voldoende
Wait()tijd. - NUI scripts die elk frame updaten.
- Grote map- of kledingpakketten in de buurt van dichte gebieden.
- HUDs controleren te vaak te veel spelerstatussen.
- Client events die server-werk doen.
Gerelateerde optimalisatiegidsen
- FiveM server optimalisatie
- Hoe toon ik FPS in FiveM
- Los FiveM thread-hitch waarschuwingen op
- Officiële Cfx.re profiler gids
Hoe lees ik Resmon zonder te overdrijven
Een korte piek is niet altijd een bug. Het openen van een telefoon, inventaris, kledingmenu of kaart kan kortstondig meer CPU kosten. Het probleem is een resource die duur blijft terwijl deze inactief is of elke paar seconden piekt tijdens normaal spelen.
Nuttige testnotities
- Test elke keer met dezelfde route door de stad.
- Schrijf de top drie resources op voordat je iets verandert.
- Schakel één verdachte resource tegelijk uit.
- Test opnieuw na een volledige herstart, niet alleen een hot reload.
- Controleer zowel een laag aantal spelers als een druk aantal spelers.
Ontwikkelaarsoplossingen die meestal werken
Verhoog wachttijden in loops, vermijd constante NUI updates, cache herhaalde opzoekingen, verplaats server-only werk uit clientcode en stop met elke frame elke spelerstatus te controleren. Als een script moet reageren op events, gebruik dan events in plaats van pollen wanneer mogelijk.
Hoe te beslissen wat eerst te repareren
Verwijder niet zomaar resources omdat één getal er even hoog uitziet. Test eerst dezelfde route door de stad, schrijf de top drie dure resources op en verander dan één ding tegelijk. Een telefoon, inventaris of kledingmenu kan alleen pieken terwijl het open is; dat is anders dan een script dat duur blijft terwijl de speler inactief is.
Veelvoorkomende oplossingen die ontwikkelaars moeten controleren
- Verhoog wachttijden in loops die geen controles per frame nodig hebben.
- Cache herhaalde opzoekingen van spelers, voertuigen of entiteiten.
- Verminder constante NUI-berichten van HUD- en telefoonresources.
- Verplaats server-only validatie uit client-loops.
- Gebruik events waar polling slechts een gemaksoplossing is.
Wat Resmon niet kan bewijzen
Resmon is client-side. Het helpt bij het identificeren van resources die de frametijd van een speler kosten, maar het vervangt geen serverlogs, databaseprofilering of txAdmin-monitoring. Een resource kan er goedkoop uitzien op de client en toch server-side database-druk veroorzaken. Gebruik Resmon voor clientgevoel, gebruik vervolgens servertools voor backend-problemen.
Notities voor en na
Maak een screenshot of noteer msec-waarden voordat je code wijzigt. Test na elke oplossing dezelfde route opnieuw met hetzelfde aantal spelers indien mogelijk. Zonder een herhaalbare test wordt prestatieoptimalisatie giswerk.
Wanneer het probleem intermitterend is, noteer dan de tijd, het aantal spelers en de locatie. Dat helpt bij het vergelijken van Resmon-gegevens met txAdmin-logs en recente resourcewijzigingen.
Houd voor gedeelde teams één kleine prestatielogboek bij, zodat ontwikkelaars kunnen zien wat er veranderde voordat de piek verscheen.
Goede notities maken optimalisatie sneller dan giswerk.
Ze maken het ook gemakkelijker om de exacte resource-update terug te draaien die de regressie veroorzaakte.
Houd de notities kort genoeg zodat personeel ze daadwerkelijk gebruikt.
