Why streaming, not scripts, usually controls join time
When a player connects to your FiveM server, the client does two heavy things before they spawn. First it downloads every file your resources mark for streaming. Second it loads those files into GTA V's streaming system so the world, vehicles, peds, and props can render. A server with hundreds of megabytes of textures and models will make players sit on the loading screen far longer than a server with a tight, audited asset set, even if both run identical scripts.
This is the part of optimization that resmon and txAdmin performance graphs will not show you. CPU time per resource matters for in-game stutter, but it has almost nothing to do with how long a fresh player waits to join. Join time is dominated by download size and how the engine ingests your stream folders. If you have ever watched new players quit on the loading screen while veterans get in fine, you are looking at a streaming and caching problem.
How FiveM streams assets
Any file placed in a folder named stream inside a resource is picked up automatically and treated as a game asset, as long as the resource manifest declares the folder. Modern manifests do this implicitly for a top-level stream directory; YTYP archetypes and some map data are additionally registered with data_file entries (for example data_file 'DLC_ITYP_REQUEST'). The common file types are:
- YTD texture dictionaries. These hold the actual texture images for vehicles, clothing, props, and map objects.
- YDR drawables and YFT fragments. These are 3D models. YFT is used for breakable or physics objects like vehicles, YDR for static drawables.
- YMAP and YTYP. Map placement and archetype definitions that tell the engine where objects sit and how they behave.
- YBN, YND, YNV. Collision and navigation data.
On connect, the client compares its local cache against the server manifest. Anything it does not already have, it downloads. Those files land in the client cache (the data\cache\files area inside the FiveM application data folder). On a later join the client reuses cached files, which is why your second connection is faster than your first. The size and number of these files is the single biggest lever on first join time.
Why huge assets slow joins specifically
A 16MB vehicle YTD is not just a slow download. The streaming engine has to decompress and register it, and GTA V's streaming system has a finite memory budget. When you exceed practical limits you get two visible symptoms: long loads, and texture loss or model pop where the engine silently fails to stream something in. People call the second one "texture flickering" or "low res cars," and it is almost always an oversized or over-budget asset problem, not a graphics setting.
Texture dictionary sizes and resolution
Most bloat in custom FiveM content lives in YTD files. A car pack author exports every texture at 4096x4096 because that is the default, when 2048 or even 1024 would be indistinguishable at gameplay distance. A single 4K uncompressed-looking texture can be several megabytes; a vehicle with diffuse, normal, specular, dirt, and detail maps at 4K can blow past 30MB on its own. Multiply that across fifty add-on cars and you have a multi-gigabyte server that takes minutes to join.
The fix is to open YTD files in a tool like OpenIV or CodeWalker, check the per-texture resolution and compression format, and downscale anything larger than it needs to be. Use DXT/BC compression formats rather than uncompressed RGBA. For most map props and clothing, 1024x1024 diffuse textures are plenty. Reserve 2048 for hero vehicles or objects the player gets close to.
On-demand streaming versus preload
FiveM streams assets on demand based on the player's position and what the game engine requests, the same as base GTA V. You do not get to fully "preload" the world. What you control is total catalogue size and how that catalogue is organized. A practical implication: splitting one giant resource into logical resources does not reduce download size, but it does let you disable or stop streaming content you are not using. If your server runs a single map but ships three unused map packs in the resource folder, those still get streamed and downloaded. Remove them.
Caching, and why it cuts repeat join time
The client cache is your friend for returning players and your enemy for first-time joins. You cannot make the first download smaller through caching, only through asset size. But you can avoid breaking the cache unnecessarily. Every time you re-export or re-pack an asset, its hash changes and every player re-downloads it on their next join. Batch your content updates instead of pushing a new car or texture tweak every day, and your regular players stop paying the download tax repeatedly.
Auditing your largest resources
You cannot optimize what you have not measured. Do a size audit before touching anything:
- Sort your
resourcesandstreamfolders by total size on disk. On any OS this is a one-minute job in the file explorer or with a command linedu-style tool. - Inside the biggest offenders, sort by file type. Almost always the YTD files dominate.
- Open the worst YTD files in OpenIV or CodeWalker and read the actual texture resolutions and formats.
- Check for duplicates. Car packs frequently ship the same shared texture in every vehicle folder. Shared textures can often be consolidated.
- Look for assets nothing references. Orphaned YMAP entries, leftover dev props, and old map versions are common.
Keep a simple before/after record of total stream size. Cutting a server from 3GB to 900MB of streamed assets is a realistic outcome on a content-heavy server, and it directly shortens the first join.
Players downloading on join
Every streamed byte travels over your server's connection to each joining client. If your host has limited upload bandwidth, a large stream catalogue means players download slowly and your server's outbound link saturates during peak join times. Two things help: shrink the catalogue (covered above), and consider whether your host's upload capacity matches your content size and concurrent join rate. The asset diet is the part you control directly and should always come first.
Concept to mechanism, one worked example
Say you add a 60-car police pack and joins jump from 25 seconds to 90 seconds. The mechanism: that pack added 1.8GB of YTD and YFT files, so every new player now downloads an extra 1.8GB and the engine has to register all of it. You open the pack in OpenIV, find every livery and body texture exported at 4096, batch-downscale liveries to 2048 and bodies to 1024 with BC compression, and remove three duplicate wheel texture sets shared across all cars. The pack drops to roughly 600MB. First join falls back toward 35 to 40 seconds, repeat joins are near instant from cache, and the low-res-car flicker some players reported disappears because you are no longer fighting the streaming memory budget.