Open your server.cfg right now and scroll the resource list. Somewhere in there is a script you ensured eight months ago for a feature you abandoned, two MLOs fighting over the same building, a notify system you replaced but never removed, and a vehicle pack nobody’s spawned since launch week. Every server over a year old is carrying this dead weight, and it’s not harmless — it eats your tick budget, confuses your load order, and hides the actual gaps your players keep complaining about. Auditing your fivem server assets is the unglamorous quarterly chore that makes everything else faster, and almost nobody does it until performance forces the issue.
Why asset libraries always bloat
Bloat isn’t a failure, it’s the default outcome of running a server. It accumulates from impulse buys during a sale, free downloads you grabbed “to test,” scripts whose original author vanished and stopped updating, half-finished features you ensured and then lost interest in, and the eternal lie: “we might use it someday.” Someday never comes, but the resource stays in the manifest, loads on every boot, and quietly competes for the same single-threaded budget your gameplay scripts need. A year of that and your server is hauling around a junk drawer it mistakes for a feature set.
The inventory step: list and tag everything
You can’t cut what you haven’t catalogued, so start with a brutal, complete inventory. Pull every resource out of your server.cfg and cross-reference it against what’s actually sitting in your resources folder — you’ll find both ensured-but-missing entries and folders that exist but were never ensured. Put all of it in a spreadsheet and tag every single resource into one of four buckets:
- Core. Framework, database wrapper, ox_lib, voice, the spine everything depends on. Untouchable.
- Actively used. Players interact with it weekly and you can name when they last did.
- Dead. You can’t remember the last time anyone used it, or it’s for a feature you killed.
- Duplicate. It overlaps something else doing the same job.
The act of tagging is where the discovery happens. You will be genuinely surprised how many resources you cannot honestly file under “actively used.”
Finding the FPS bloat
Tagging tells you what’s unused; resmon tells you what’s expensive. The two lists are different, and the overlap is where your worst offenders live. Open resmon 1 on a populated server, not an empty one, and sort by CPU time. Now compare that against your “actively used” tags. A script costing 1.5ms a tick that’s also tagged dead is a pure, free win — delete it and hand that budget back to gameplay. A heavy script that’s genuinely core needs optimizing, not removing. The villain you’re hunting is the resource that’s both costly and untouched: the standalone job nobody works, the always-on weather sync you forgot you doubled up on, the prop streamer for a map you removed. Each of those is paying rent in your tick budget and contributing nothing.
Duplicates and overlap
Duplication is sneakier than dead weight because every copy looks legitimate in isolation. Hunt these specifically:
- Two MLOs at one location. You bought an upgraded police station and never pulled the old one — now both stream, props clip through each other, and you’ve doubled the load for one building.
- Three notify scripts. A framework’s built-in notify, plus ox_lib’s, plus a standalone one a single script pulled in. Consolidate to one and rewire the stragglers.
- Redundant vehicle packs. Overlapping car packs that ship the same models under different spawn names bloat your stream folder and your handling files for zero player benefit.
- Overlapping targets and menus. qb-target and ox_target both loaded because different scripts assumed different ones. Pick one direction and migrate.
Building the cut list and removing safely
Now you have a kill list. Don’t go on a deleting spree at peak hours — removing assets carelessly is how you trade a bloat problem for an outage. Work the safe sequence:
- Back up first. Full copy of the resources folder and the database before you touch anything. Non-negotiable.
- Disable before deleting. Comment out the ensure line in server.cfg, restart, and run the server live for a few days. If nothing breaks and nobody screams, then delete the folder.
- Watch for dependencies. The export another script quietly calls, the shared SQL table, the item definition that lives in a resource you’re about to cut. Search your codebase for the resource name before you pull it, and read the console on restart for the “could not find” errors that tell you what depended on it.
- Cut in small batches. Remove a handful, restart, verify, repeat. A 40-resource purge in one restart leaves you with no idea which removal broke the spawn screen.
When a cut leaves a real hole — you remove a clunky old script and now genuinely need a better one — that’s the moment to replace deliberately rather than re-clutter. The replacement and upgrade scripts on scripts-tebex.io are where a focused swap beats keeping the dead version “just in case.”
Finding the gaps and buying with intent
An audit isn’t only subtraction. The other half is finding what players keep asking for that you don’t have. Scrape your Discord suggestions channel, your support tickets, and what people complain about in-character, and you’ll see patterns — “there’s nowhere to hang out on the south side,” “we need a proper tuner shop interior,” “the police garage is empty.” Those are your real gaps, and they convert the whole exercise from cleanup into a focused buying plan. Instead of the next impulse purchase during a sale, you buy against a list players actually generated: an interior to fill that dead district from assets-tebex.io, or the vehicle category your community keeps requesting from cars-tebex.io. That’s the difference between a library that grows on purpose and one that grows by accident. Run this on a cadence — once a quarter, calendar it — and your server stays lean, fast, and stocked with what people use instead of bloated with what you forgot you bought. The audit is a little brutal by design. That’s exactly why it works.