How I cut our FiveM server’s memory footprint

A serious-roleplay city accumulates assets the way a garage accumulates junk: slowly, then suddenly you can’t park. Ours had crept past a comfortable streaming budget — longer join times, texture pop-in, and the occasional client crash on asset-heavy areas. This is the cleanup, and the tool I wrote to make it repeatable.

The two culprits

Oversized YTDs. A texture dictionary authored at 4K when the model is a background prop is pure waste — it costs memory on every client that streams it, forever. Vehicle and clothing packs are the worst offenders because creators ship “max quality” by default and nobody downsamples.

Duplicate archetypes. When two resources declare the same archetype, you get non-deterministic behavior and wasted load — and in a big library it happens constantly because packs bundle overlapping props. Left alone it shows up as the classic “why is this object invisible for some players” bug.

Why this is a memory problem, not a disk problem

People assume a big resources folder is fine because storage is cheap. It isn’t about disk. FiveM streams assets into client memory, and GTA’s engine has hard ceilings. Blow past them and you don’t get a graceful slowdown — you get texture corruption and crashes on the lowest-VRAM machines in your player base, which is exactly the players you can least afford to lose. The full diagnosis order is in my server lag guide; this post is the streaming slice of it.

Doing it at scale

You cannot hand-audit thousands of YTDs. So I wrote a small C# utility that walks the resource tree, flags textures above a size threshold, re-encodes them to a sane resolution, and reports the before/after byte delta per resource. A separate pass scans for archetype collisions across every fxmanifest and prints the conflicts so I can pick a winner and strip the rest.

The win wasn’t one dramatic file — it was a long tail of “this 12 MB texture should be 2 MB” repeated a few hundred times. Sum it up and join times dropped, pop-in mostly disappeared, and the low-end crash reports stopped.

The takeaway for other server owners

Optimization on a live city is boring and it compounds. You’re not looking for a silver bullet; you’re looking for a repeatable pass you can run every time you add a pack, so the garage never fills up again. If you’d rather have that pass run for you — audit, shrink, deduplicate, verified against a real city — that’s one of the things I do.