DEV Community: GameDevToolLab

A Practical Guide to Unity Addressables Bundle Splitting and LZ4/LZMA Compression

GameDevToolLab — Fri, 19 Jun 2026 11:31:12 +0000

Overview

In the previous article, we looked at Addressables download concurrency, label design, and batch downloads using labels.

One important point there was this:

Labels are only the entry point for specifying what you want to download. The actual files downloaded are AssetBundles.

In other words, even if your label design looks clean, a rough Bundle layout can still cause unexpected assets to be downloaded together.

This time, we will look at how to split AssetBundles and how to choose compression settings.

In particular, this article covers:

Whether Bundles should be split into smaller units or grouped together
How to handle many small files, such as VN / adventure game scenario text files
How to split assets that will keep increasing over time, such as character 3D models
How to think about Pack Together, Pack Separately, and Pack Together By Label
How to choose between LZ4 and LZMA

This is not an introduction to the official features. The focus is on practical decision-making for real projects.

Label design and Bundle splitting must be considered together

In Addressables, you can use Addresses and Labels to specify which assets to load or download.

However, the actual files downloaded are AssetBundles.

For example, suppose you define labels like this:

Label	Purpose
`chapter_01`	Assets used in Chapter 1
`chapter_02`	Assets used in Chapter 2
`character_alice`	Assets related to Alice
`character_bob`	Assets related to Bob

If you only look at the labels, it may seem like the assets are managed in a fine-grained way.

But if the actual Bundle is packed as one large Bundle, downloading only chapter_01 may still download other assets included in the same Bundle.

So, in Addressables, these two concepts need to be considered separately:

Item	Role
Address / Label	Specifies which assets are requested
AssetBundle	The actual unit downloaded, cached, and loaded

Label design alone does not determine the download unit.

Label design and Bundle splitting must be designed together.

What does Bundle splitting affect?

Bundle splitting is not just a way to organize things in the Editor.

In practice, it affects the following:

Affected area	Description
Download unit	Which files are downloaded together
Cache unit	Which units are stored on the device
Update unit	Which Bundles become update targets during content updates
Load unit	Which Bundles are required at load time
Number of files	Affects download requests and file open operations
Management cost	Catalogs, dependencies, and operation rules become more complex

Splitting Bundles into smaller units makes it easier to download only what is needed and reduce update size.

On the other hand, if the number of Bundles increases too much, download requests, cached files, file open operations, catalog complexity, and dependency management cost all increase.

So with Addressables, “smaller is always better” is not the right answer.

The basic approach is:

Group what should be grouped, and split what should be split, based on how the assets are actually used.

Bundle Mode options

In Addressables Group settings, you can choose a Bundle Mode.

The main options are:

Bundle Mode	Description	Suitable cases
`Pack Together`	Packs assets in the group into Bundles together	Small files, or data used together
`Pack Separately`	Packs each Addressable entry in the group into a separate Bundle	Characters, stages, costumes, and other assets with clear update units
`Pack Together By Label`	Packs assets with the same label set together	Cases where you want to manage or download by label

One important detail is that Pack Separately does not mean “one asset per Bundle.”

It means one Bundle per Addressable entry.

If a folder is marked as an Addressable entry, the contents under that folder may be packed into one Bundle.

Also, scene assets are handled as separate Bundles from normal assets. Even with Pack Together, everything is not necessarily packed into a single file.

Avoid casually saying “one address, one file”

In real projects, people sometimes describe Pack Separately as “one address, one file.”

That may be fine for a rough conversation, but it is better to be careful when writing design documents or articles.

As an Addressables setting, the accurate term is Pack Separately.

Pack Separately creates a separate Bundle for each Addressable entry in the group.

So the following cases are not as simple as “one asset = one Bundle”:

A folder is registered as an Addressable entry
Sprite Atlases or Sub Assets are involved
Scenes and normal assets are mixed
Dependencies are moved into separate Bundles

For a rough explanation, “one address, one file” may be understandable.

But for actual design, it is safer to think in terms of Pack Separately.

Cases where grouping Bundles is acceptable

First, let’s look at cases where grouping assets into Bundles is reasonable.

Asset characteristic	How to think about it
Each file is small	Creating individual Bundles may make the file count a bigger problem
There are many files	Download requests and file open operations can increase
They are used together	Splitting does not change the actual load unit much
Individual updates are rare	Fine-grained update units provide little benefit
The management unit is clear	Easy to group by chapter, event, language, and so on

Typical examples include:

VN / adventure game scenario text
Dialogue text
Small .txt files
Small configuration files
Master data
Localization text
Lightweight ScriptableObject assets

For this kind of data, creating one Bundle per file may not be the easiest approach to operate.

Especially when each file is only a few KB to a few dozen KB, and there are hundreds or thousands of them, the downside of increasing the number of files can become more noticeable than the benefit of fine-grained Bundles.

Many small files, such as VN scenario text

VN / adventure game scenario text is an easy example where grouping often makes sense.

For example, suppose you have a structure like this:

Scenario/
  Chapter01/
    scene_001.txt
    scene_002.txt
    scene_003.txt
    ...
  Chapter02/
    scene_001.txt
    scene_002.txt
    scene_003.txt
    ...

If every .txt file is packed into its own Bundle, the number of files increases quickly.

When the file count increases, the following costs also increase:

More download requests
More cached files
More file open operations
More file lookup and management cost
Catalog and dependency checks become more tedious

Of course, if you need to update each scenario file independently, or if you absolutely do not want to download a scenario until the user is about to read it, splitting into smaller units may be valid.

But in many cases, grouping like this is easier to operate:

Grouping unit	Example
Chapter	`scenario_chapter_01`
Event	`scenario_event_summer`
Language	`scenario_ja`, `scenario_en`
Delivery unit	`scenario_initial`, `scenario_update_001`

For scenario text, users often play by chapter or event.

So grouping Bundles by those units usually makes operation easier.

Cases where Bundles should be split

On the other hand, there are also cases where splitting Bundles is better.

Asset characteristic	How to think about it
Each asset is large	Downloading unnecessary data becomes costly
The addition unit is clear	Easy to update by character, costume, or stage
Individual updates are frequent	Update diffs can be kept smaller
The asset may not be used	It can be downloaded only when needed
There is a sales or unlock unit	Works well with DLC, gacha, event rewards, etc.

Typical examples include:

Character 3D models
Character-specific Meshes
Character-specific Textures
Character-specific Materials
Character-specific Animations
Costumes
Weapons
Stages
Large Prefabs
VFX
Voice assets

If you group these too aggressively, operation can become painful.

In particular, assets such as characters and stages often increase over time. Splitting Bundles by the unit in which they are added makes them easier to manage.

Assets that keep increasing, such as character 3D models

Character 3D models are an easy example where splitting Bundles often makes sense.

Suppose all characters are packed into one Bundle:

character_all.bundle
  Alice
  Bob
  Carol
  Dave
  Eve

With this layout, adding just one new character can make the entire character_all.bundle an update target.

Even if a user only needs Alice, they may still download Bob and the other characters because they are in the same Bundle.

On the other hand, if you split Bundles by character, the update and download units become clearer:

character_alice.bundle
character_bob.bundle
character_carol.bundle
character_dave.bundle
character_eve.bundle

With this layout, if only Alice is needed, only Alice’s Bundle can be downloaded.

When adding a new character, you can add a new Bundle and avoid updating existing character Bundles as much as possible.

A character Bundle may contain assets like this:

character_alice.bundle
  Alice.prefab
  Alice.mesh
  Alice.material
  Alice_texture_base
  Alice_texture_normal
  Alice_animation_idle
  Alice_animation_run

This kind of layout is practical because larger assets that are used together are grouped by their addition and update unit.

`Pack Together By Label` is useful, but depends on label design

Pack Together By Label packs assets with the same label set into Bundles.

If your label design is clean, this can make it easier to create Bundles by label.

For example:

Asset	Labels
Alice-related assets	`character_alice`, `initial_download`
Bob-related assets	`character_bob`, `event_001`
Chapter 1 scenario	`scenario_chapter_01`, `initial_download`
Chapter 2 scenario	`scenario_chapter_02`, `update_001`

However, if labels are messy, relying on Pack Together By Label can easily produce an unintended Bundle layout.

For example, if management labels, download labels, event labels, and search labels are mixed together, the number of label combinations increases and the Bundle layout becomes hard to read.

When using Pack Together By Label, it is safer to separate label responsibilities:

Label type	Example	Notes
Download labels	`initial_download`, `chapter_01`	These may affect Bundle splitting
Classification labels	`character`, `scenario`	Decide whether they should affect Bundle splitting
Management labels	`deprecated`, `debug`	Avoid mixing them with runtime labels
Event labels	`event_001`	Also consider what happens after the event ends

Increasing the number of labels is not bad by itself.

But when using Pack Together By Label, the label set directly affects the Bundle layout, so you need operation rules.

How to decide whether to group or split

As a rough guide:

Asset characteristic	Recommendation
Many small files	Group them
Used together by chapter or event	Group them
Little need for individual updates	Group them
Too many files are being created	Group them
Each asset is large	Split them
Addition unit is clear	Split them
Added by character, costume, or stage	Split them
You do not want to download unused assets	Split them
You want to keep update diffs small	Split them

In more practical terms:

Group many small files
Split large assets with clear addition units
Group assets that are used together
Split assets that may not be used
Split assets with different update units

These are the basic rules for Bundle splitting.

Difference between LZ4 and LZMA

Next, let’s look at compression settings.

In Addressables Group settings, you can choose the compression format for Bundles.

The common choices are LZ4 and LZMA.

Compression	Characteristics
LZMA	High compression ratio, useful for reducing download size
LZ4	Chunk-based and easier to handle at load time
Uncompressed	No decompression cost, but file size tends to be larger

LZMA treats the entire Bundle as one compressed stream.

This usually gives a higher compression ratio, but the decompression cost during loading can become larger.

LZ4 compresses data in chunks.

Its compression ratio is usually lower than LZMA, but it is easier to read only the needed parts, and it tends to be lighter to handle at load time.

Cases where LZMA is easy to recommend

LZMA is useful when you want to reduce download size.

However, in real projects, it is safer to decide based on what is inside the Bundle.

As a rule of thumb:

If 1 Bundle is close to 1 asset, LZMA is easy to recommend.
If 1 Bundle contains multiple assets, LZ4 should be the default.

Here, “1 Bundle = 1 asset” means cases like:

One large binary file
One large TextAsset
One video file
One audio file
One Prefab packed into its own Bundle
One Texture packed into its own Bundle

These Bundles are likely to be loaded almost entirely when used.

That makes it easier to benefit from LZMA’s high compression ratio.

On the other hand, be careful with a Bundle like this:

character_alice.bundle
  Alice.prefab
  Alice.mesh
  Alice.material
  Alice_texture_base
  Alice_texture_normal
  Alice_animation_idle
  Alice_animation_run

This is a “one character, one Bundle” layout, but the Bundle still contains multiple assets.

Even if it looks like one unit called Alice at the application level, the Bundle itself is a collection of multiple assets.

So it is safer not to casually decide “one character Bundle means LZMA.”

LZMA is easy to recommend only when the layout is close to 1 Bundle = 1 asset.

Use LZ4 as the default for Bundles containing multiple assets

LZMA treats the entire Bundle as one compressed stream.

So even if you only want to read part of the Bundle, the decompression cost of the whole Bundle can become an issue at load time.

When multiple independent assets are grouped into one Bundle, LZ4 is usually easier to operate.

Bundle layout where LZ4 should be the default	Reason
Bundle containing multiple Addressable entries	You may only read part of it
Bundle containing many small files	The purpose is reducing file count, so partial access matters
Chapter-level scenario Bundle	You may not read every file in the chapter at once
Master data Bundle	Only some data may be referenced
Localization Bundle	Data may be read by language or screen
Character-related asset Bundle	Often contains Prefab, Mesh, Texture, Animation, etc.
Bundle where stable load time and memory behavior matter	Avoiding full-stream decompression is safer

The important point is:

“One character, one Bundle” and “one Bundle, one asset” are different things.

Even if a character has its own Bundle, if that Bundle contains a Prefab, Meshes, Textures, Materials, and Animations, it is still a multi-asset Bundle.

In that case, using LZ4 as the default usually makes load-time behavior more stable.

Cases where LZ4 should be the default

LZ4 is suitable when you care about load-time handling.

In Addressables, it is common to group multiple assets into one Bundle. In practice, LZ4 is usually the default choice for multi-asset Bundles.

Bundle layout	Reason
Bundle containing many small files	You may only read part of it
Chapter-level scenario Bundle	Files are often read in sequence
Master data Bundle	Only some data may be referenced
Localization Bundle	Data may be read by language or screen
Bundle containing multiple Addressable entries	LZMA is more affected by whole-Bundle decompression
Character-related asset Bundle	Often contains multiple assets
Bundle where stable load time matters	Chunk-based compression is easier to operate

For Bundles that group multiple files, such as VN scenario text, LZ4 is often easier to handle.

Group the Bundle to reduce the number of files.

But use LZ4 because you may only read part of the Bundle.

This combination is very practical.

Practical recommended settings

As a starting point, the following rules are easy to work with:

Asset type	Bundle split	Compression
One large TextAsset	1 asset per Bundle	LZMA recommended
One large binary file	1 asset per Bundle	LZMA recommended
One video file	1 asset per Bundle	LZMA recommended, but also consider compression of the video format itself
One audio file	1 asset per Bundle	LZMA recommended, but also consider compression of the audio format itself
One Texture	1 asset per Bundle	LZMA recommended, but judge based on the size after texture compression
VN scenario text	Group by chapter or event	LZ4
Dialogue text	Group by chapter, event, or language	LZ4
Master data	Group by type or update unit	LZ4
Localization	Group by language	LZ4
Character 3D models	Consider one Bundle per character	LZ4 if the Bundle contains multiple assets
Costumes	Consider one Bundle per costume	LZ4 if the Bundle contains multiple assets
Stages	Consider one Bundle per stage	LZ4 if the Bundle contains multiple assets
Large VFX	Split by usage unit	LZ4 if the Bundle contains multiple assets
Voice assets	Split by character, chapter, or event	LZ4 if multiple files are grouped together

The key point is to think about Bundle granularity and compression format separately.

Splitting Bundles, such as one Bundle per character, is useful for reducing download and update units.

However, if that Bundle contains multiple assets, LZ4 should be the default compression choice.

Conversely, if a Bundle contains only one asset, LZMA is easy to recommend.

Condition	Recommendation
1 Bundle is close to 1 asset	LZMA recommended
The whole Bundle is always read	LZMA is easier to recommend
You strongly want to reduce initial download size	LZMA is easier to recommend
Multiple Addressable entries are included	LZ4 by default
You may only read part of the Bundle	LZ4 by default
Many small files are grouped together	LZ4 by default
You want stable load time	LZ4 by default
Web delivery is involved	Start with LZ4 in mind

Of course, the final decision should be based on real device measurements.

Even with “1 asset per Bundle,” the perceived behavior changes depending on asset type, size, device performance, and load timing.

Measure download size, load time, and memory usage on real devices before making the final decision.

Notes on Bundle splitting

There are a few additional things to keep in mind when splitting Bundles.

Duplicate dependencies

When Bundles are split into smaller units, shared dependencies become important.

For example, if multiple characters reference the same Material or Texture, the dependency layout can become complicated depending on how you split the Bundles.

You need operation rules for whether shared assets should be moved into a shared Bundle or kept with each character.

Do not look only at update diffs

Splitting Bundles into smaller units makes update diffs easier to reduce.

But the trade-off is an increased number of Bundles.

If you only look at update size, you may want to split everything. But download requests, cache count, and load-time management cost should be considered together.

Think about initial downloads and additional downloads separately

Assets needed for the initial download and assets downloaded later should not be judged by the same rule.

Type	How to think about it
Initial download	Group assets needed immediately after launch and reduce the number of downloads
Additional download	Download only what is needed by character, stage, or event
Optional download	Download voices, high-resolution textures, etc. only when needed

For initial downloads, grouping more aggressively can be easier.

For additional downloads, making the unit clear is usually easier to operate.

Do not mix the responsibilities of labels and Bundle Mode too much

Labels are useful, but trying to solve everything with labels can break the design.

Labels for specifying download targets
Labels for search or classification
Labels for management
Labels for events
Labels for debugging

If all of these are mixed together and you use Pack Together By Label, the Bundle layout becomes difficult to understand.

When adding labels, consider whether each label is allowed to affect Bundle splitting.

Practical checklist

Finally, here is a checklist for deciding Bundle layout.

Group or split

[ ] Are these assets used together?
[ ] Do you want to download them individually?
[ ] Do you want to update them individually?
[ ] Is each file large?
[ ] Is the number of files getting too high?
[ ] Is there a clear unit such as character, chapter, stage, or event?
[ ] Is this part of the initial download or an additional download?
[ ] Are unnecessary assets being downloaded?

Compression settings

[ ] Is download size the priority?
[ ] Is load time the priority?
[ ] Is the layout close to 1 Bundle = 1 asset?
[ ] Does the Bundle contain multiple assets?
[ ] Is there a chance that only part of the Bundle will be read?
[ ] Did you measure download size on a real device?
[ ] Did you measure load time on a real device?
[ ] Did you measure memory usage on a real device?

Operation

[ ] Does the label design match the Bundle layout?
[ ] Are you relying too much on Pack Together By Label?
[ ] Have you decided how to handle shared dependencies?
[ ] Are you balancing update size and file count?
[ ] Will the design still work after more assets are added post-release?

Summary

With Addressables Bundle splitting, neither “split everything” nor “group everything” is always correct.

The important thing is to decide based on how the assets are used, update units, download units, file count, and load-time cost.

For data such as VN scenario text, where each file is small but there are many files, grouping by chapter or event can be easier to operate.

This is because increasing the number of files also increases download requests, cached files, file open operations, file lookup cost, and management cost.

On the other hand, for assets such as character 3D models, where each asset is large and new assets are likely to be added over time, splitting by character can be easier to manage.

For compression, the rule of thumb is:

If 1 Bundle is close to 1 asset, LZMA is recommended. If the Bundle contains multiple assets, use LZ4 by default.

LZMA is useful when compression ratio is the priority, but because whole-Bundle decompression can become an issue, it is safer to avoid it when multiple independent load targets are grouped into one Bundle.

On the other hand, if the Bundle effectively contains one asset, such as one large TextAsset, one binary file, or one Texture, LZMA is easy to recommend.

In the end, always measure download size, load time, and memory usage on real devices before making the final decision.

Addressables can look complicated if you only look at the settings.

But in practice, the basic idea is simple:

Group small files. Split large assets with clear addition units. For compression, use LZMA when 1 Bundle is close to 1 asset, and use LZ4 by default for multi-asset Bundles.

Starting from this policy makes it easier to build a Bundle layout that does not break down over time.

Practical Tips for Unity Addressables: Concurrent Downloads and Label Design

GameDevToolLab — Fri, 19 Jun 2026 11:29:54 +0000

Overview

Unity Addressables makes it much easier to handle remote asset downloads and cache management.

However, when you use it in a real project, you may run into issues like these:

Calling DownloadDependenciesAsync does not make downloads as fast as expected
Downloading by label pulls in assets you did not expect
Manually managing Address and Label settings becomes painful

This article focuses on the points that are easy to overlook when designing downloads with Addressables:

Configuring the number of concurrent downloads
How to think about concurrent downloads on iOS and Android
Why you should start downloading larger files first
Bulk downloads using labels
The difference between labels and AssetBundle download units
Automating management with Smart Addresser

Bundle splitting and LZ4/LZMA compression will be covered in a separate article, so this article only touches on them where necessary.

Addressables download speed is not determined by a single API call

When pre-downloading assets with Addressables, the API you will often use is:

Addressables.DownloadDependenciesAsync(label);

This is useful because it allows you to download the dependencies associated with a label or address ahead of time.

That makes the user experience more stable than suddenly downloading assets right before a loading sequence.

However, download speed is not determined just by calling this API.

In practice, it depends on factors such as:

The number of concurrent downloads
CDN or server response speed
The user's network condition
AssetBundle size
The number of AssetBundles
Device performance
Decompression and loading cost after download

Especially in mobile games, the number of concurrent downloads and the order in which downloads are started are very important.

Configure the number of concurrent downloads properly

Addressables allows you to control how many web requests run at the same time.

At runtime, you can configure it with the following API:

WebRequestQueue.SetMaxConcurrentRequests(maxRequests);

If the number of concurrent downloads is too low, you may not fully utilize the available network or CDN performance.

On the other hand, if it is too high, you may run into problems such as:

Increased load on low-end devices
Lower frame rate during downloads
More heat generation
Bottlenecks during decompression or loading after downloads
Instability depending on the network condition

In other words, more concurrent downloads do not always mean faster downloads.

You need to tune this based on your target devices, Bundle size, network environment, and loading screen design.

Use 10 on iOS, and switch between 3 and 10 on Android based on device performance

In my projects, I use the following policy based on real-device testing.

Platform	Concurrent downloads
iOS	10
High-end Android devices	10
Low- to mid-range Android devices	3

The important point is that this is not an official fixed recommendation from Unity.

It is a practical policy adopted after testing within a specific project.

:::message
In this article, I use 10 concurrent downloads on iOS and either 3 or 10 on Android depending on device performance, as a practical policy based on real-device testing.

The optimal value depends on your CDN, network condition, Bundle size, and device performance, so make sure to measure it on actual devices.
:::

iOS devices tend to have less variation in performance, so it is easier to use a relatively aggressive setting.

Android devices vary much more, so it is safer to switch the value based on device performance instead of using 10 for every device.

Configure concurrent downloads at runtime

If you want to change the number of concurrent downloads per device, call WebRequestQueue.SetMaxConcurrentRequests() when the app starts.

using UnityEngine;
using UnityEngine.ResourceManagement;

public static class AddressablesDownloadTuning
{
    public static void Apply()
    {
        int maxRequests = GetMaxConcurrentRequests();

        WebRequestQueue.SetMaxConcurrentRequests(maxRequests);

        Debug.Log($"Addressables max concurrent requests: {maxRequests}");
    }

    private static int GetMaxConcurrentRequests()
    {
#if UNITY_IOS
        return 10;
#elif UNITY_ANDROID
        return GetAndroidDeviceScore() >= 3 ? 10 : 3;
#else
        return 10;
#endif
    }

#if UNITY_ANDROID
    private static int GetAndroidDeviceScore()
    {
        int score = 0;

        if (SystemInfo.systemMemorySize >= 6000)
            score += 2;
        else if (SystemInfo.systemMemorySize >= 4000)
            score += 1;

        if (SystemInfo.processorCount >= 8)
            score += 1;

        if (SystemInfo.graphicsMemorySize >= 2048)
            score += 1;

        return score;
    }
#endif
}

Call it during app initialization.

using UnityEngine;

public class AppInitializer : MonoBehaviour
{
    private void Awake()
    {
        AddressablesDownloadTuning.Apply();
    }
}

The key is to configure this before Addressables downloads begin.

It is easier to manage if you call it at a fixed timing, such as during initial app setup or around Addressables initialization.

Adjust Android scoring for your project

In the sample above, the Android device score is calculated using:

System memory
CPU core count
GPU memory

However, this scoring method is only an example.

In practice, the best criteria will differ depending on your project's target devices, Bundle sizes, download-time load, and loading screen design.

For example, you may want to tune it while checking:

Minimum target device specs
FPS during downloads
Memory usage during downloads
Decompression and loading time after downloads
Heat generation
Network conditions
Whether other loading tasks also run during downloads

Android devices vary widely, so you cannot simply say, "This device has a lot of memory, so 10 is fine."

Even if the memory and CPU specs look good, storage performance or network conditions can still make download behavior unstable.

For that reason, device scoring should not be treated as a fixed answer.

It should be adjusted per project based on real-device testing.

Personally, I first decide a safe value for low-end devices, then increase the number of concurrent downloads only for higher-end devices.

Start downloading larger files first when downloading multiple files

When configuring concurrent downloads, there is one more thing to consider: the order in which downloads are started.

If you manage your own queue of multiple Bundles or labels, it is generally better to start with the largest files first.

The reason is that you want to avoid leaving one huge file until the very end.

For example, suppose the maximum number of concurrent downloads is 3 and you have the following download targets.

File	Size
A	300MB
B	20MB
C	10MB
D	8MB
E	5MB

If you start from the smallest files, the download may look smooth at first.

However, if the 300MB file is left until the end, the progress can appear to stall near the end of the loading screen.

Starting from smaller files

[ 5MB ] [ 8MB ] [ 10MB ]
[ 20MB ]
[ 300MB ] <- Only the largest file remains at the end

On the other hand, if you start downloading the larger file first, the 300MB file can progress in the background while smaller files are processed in the remaining request slots.

Starting from larger files

[ 300MB ] [ 20MB ] [ 10MB ]
[ 8MB ] [ 5MB ] <- Smaller files are processed while the larger one is already running

Even with the same number of concurrent downloads, the perceived waiting time can change depending on the order.

This is especially useful when you download multiple additional assets together on a loading screen.

In that case, it is usually better to enqueue larger Bundles first.

However, when you call Addressables.DownloadDependenciesAsync(label) for a single label, it is difficult to precisely control which Bundle is downloaded first internally.

If you want explicit control over the download order, split your download targets by label or key, get their sizes in advance, and then start downloads in descending order of size.

using System.Collections;
using System.Collections.Generic;
using System.Linq;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;

public class AddressablesPreloadQueue : MonoBehaviour
{
    [SerializeField]
    private List<string> preloadLabels = new()
    {
        "scenario_chapter_01",
        "voice_jp_chapter_01",
        "character_hero_001",
    };

    private IEnumerator Start()
    {
        yield return PreloadBySize(preloadLabels);
    }

    private IEnumerator PreloadBySize(IReadOnlyList<string> labels)
    {
        var targets = new List<DownloadTarget>();

        foreach (string label in labels)
        {
            var sizeHandle = Addressables.GetDownloadSizeAsync(label);
            yield return sizeHandle;

            if (sizeHandle.Status == AsyncOperationStatus.Succeeded &&
                sizeHandle.Result > 0)
            {
                targets.Add(new DownloadTarget(label, sizeHandle.Result));
            }

            Addressables.Release(sizeHandle);
        }

        targets.Sort((a, b) => b.Size.CompareTo(a.Size));

        var handles = new List<AsyncOperationHandle>();

        foreach (var target in targets)
        {
            Debug.Log($"Download start: {target.Label}, size: {target.Size} bytes");

            var handle = Addressables.DownloadDependenciesAsync(target.Label, false);
            handles.Add(handle);
        }

        while (handles.Any(x => !x.IsDone))
        {
            yield return null;
        }

        foreach (var handle in handles)
        {
            if (handle.Status != AsyncOperationStatus.Succeeded)
            {
                Debug.LogError("Download failed.");
            }

            Addressables.Release(handle);
        }
    }

    private readonly struct DownloadTarget
    {
        public readonly string Label;
        public readonly long Size;

        public DownloadTarget(string label, long size)
        {
            Label = label;
            Size = size;
        }
    }
}

The important point is that WebRequestQueue.SetMaxConcurrentRequests() controls the number of concurrent downloads, while your own queue controls the order in which downloads are started.

For example, if the concurrent request limit is 3, even if you start downloads in descending order of size, only up to 3 web requests will run at the same time.

In short, Addressables bulk downloads become more stable when you think about these three points together:

Match the number of concurrent downloads to device performance
Enqueue download targets from largest to smallest
Design labels and Bundle splitting together

Bulk downloads using labels

Addressables allows you to use labels to handle multiple assets as a group.

For example, if you want to download all assets with the preload label, you can write:

Addressables.DownloadDependenciesAsync("preload");

However, in production, it is usually better to check the download size before starting the download.

Addressables.GetDownloadSizeAsync("preload");

If the assets are already cached, the download size will be 0.

This allows you to implement behavior such as:

Check whether a download is required
Show the download size to the user
Show a Wi-Fi recommendation
Skip the process if the assets are already downloaded

Sample code for DownloadDependenciesAsync

The following sample checks the download size for a label, then downloads it if necessary.

using System.Collections;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;

public class AddressablesPreloader : MonoBehaviour
{
    [SerializeField]
    private string preloadLabel = "preload";

    private IEnumerator Start()
    {
        yield return Preload(preloadLabel);
    }

    private IEnumerator Preload(string label)
    {
        var sizeHandle = Addressables.GetDownloadSizeAsync(label);
        yield return sizeHandle;

        if (sizeHandle.Status != AsyncOperationStatus.Succeeded)
        {
            Debug.LogError($"Failed to get download size: {label}");
            Addressables.Release(sizeHandle);
            yield break;
        }

        long downloadSize = sizeHandle.Result;
        Addressables.Release(sizeHandle);

        if (downloadSize <= 0)
        {
            Debug.Log($"Already downloaded: {label}");
            yield break;
        }

        Debug.Log($"Download size: {downloadSize} bytes");

        var downloadHandle = Addressables.DownloadDependenciesAsync(label, false);

        while (!downloadHandle.IsDone)
        {
            var status = downloadHandle.GetDownloadStatus();
            Debug.Log($"Download progress: {status.Percent:P0}");
            yield return null;
        }

        if (downloadHandle.Status == AsyncOperationStatus.Succeeded)
        {
            Debug.Log($"Download completed: {label}");
        }
        else
        {
            Debug.LogError($"Download failed: {label}");
        }

        Addressables.Release(downloadHandle);
    }
}

In this sample, DownloadDependenciesAsync(label, false) is used, and Addressables.Release(downloadHandle) is called manually after completion.

If you want to display progress or check the result, it is easier to manage the lifetime of the handle yourself.

How to design labels

A label should be designed as a key that represents which group of assets you want to handle together at runtime.

For example, you might use labels like these:

Label	Purpose
`preload`	Minimum assets required on first launch
`scenario_chapter_01`	Scenario text, backgrounds, and character sprites used in chapter 1
`event_2026_summer`	Assets for a limited-time summer event
`character_hero_001`	Assets for a specific character
`voice_jp_chapter_01`	Japanese voice assets for chapter 1

The important point is to design labels based on the actual loading flow.

For example, in an ADV or visual-novel-style game, you might use groups such as:

Common UI required on first launch
Title screen
Tutorial
Scenario assets per chapter
Backgrounds per chapter
Character sprites per chapter
Voice assets per language
Limited-time events

For a game where characters are added over time, labels like these may also work well:

character_hero_001
character_hero_002
skin_hero_001_summer
voice_hero_001_jp

Label design becomes much easier if you work backward from when the user needs each group of assets.

Labels are assigned to assets, but downloads happen per Bundle

This is an easy point to misunderstand.

Addressables labels are assigned to Addressable assets.

However, what actually gets downloaded is the AssetBundle.

:::message alert
A label is a key used to specify which group of assets should be downloaded.

However, the actual download unit is the AssetBundle.

So even if you assign a label to an asset, it does not necessarily mean only that specific asset will be downloaded in isolation.
:::

For example, suppose you have the following setup:

A.prefab has the preload label
B.prefab does not have the preload label
But A.prefab and B.prefab are included in the same AssetBundle

In this case, even if you download using the preload label, the AssetBundle that contains A.prefab will be downloaded.

If B.prefab is also included in that same AssetBundle, B.prefab will effectively be downloaded as well.

In other words, labels are the entry point for selecting download targets, but the actual file unit that gets downloaded is the AssetBundle.

Design labels and Bundle splitting together

Even if your labels are finely designed, the download unit remains large if your Bundles are grouped too broadly.

On the other hand, if you split Bundles too aggressively, the number of files increases.

An increased file count can lead to issues such as:

More requests
More complex catalog and dependency resolution
A large number of tiny Bundles
Higher file lookup and management cost

For this reason, label design and Bundle splitting should always be considered together.

For example, assets like ADV or visual-novel-style scenario files often have many small files.

In that case, splitting every scenario text file, small JSON file, or small configuration file into its own Bundle can create too many files and directly increase download or loading overhead.

For this kind of data, it is often more stable in practice to group assets by chapter or event.

On the other hand, assets like character 3D models are often added over time.

For those, a design close to one Bundle per character may be more suitable.

If characters are added, updated, or removed on a per-character basis, it is easier to operate when they can be downloaded in that same unit.

I will cover this in more detail in the next article.

Manual label management is error-prone

For small projects, manually managing Addressables from the Addressables Groups window is usually fine.

However, as the number of assets grows, manual management becomes painful.

Common problems include:

Forgetting to assign labels
Inconsistent label naming
Old labels remaining unintentionally
Address naming rules becoming inconsistent
Assets being placed in unintended Groups
Forgetting to clean up assets after an event ends

This becomes especially problematic in live-service games, where assets increase with each event or new character.

If every Address and Label is managed manually in that situation, mistakes are almost guaranteed to happen eventually.

Addressables is powerful, but it can become hard to maintain if your operational rules are unclear.

Use Smart Addresser

If you want to manage Address and Label settings through rules, a tool like Smart Addresser can help a lot.

Smart Addresser is an Addressables support tool published by CyberAgentGameEntertainment.

It is not an official Addressables feature, but it can automate management through rules, including:

Automatic Address assignment
Automatic Label assignment
Version management
Rule validation
CLI-based application

Manual management is enough for small projects.

However, once the number of assets grows, it is safer to generate Address and Label settings from rules instead of assigning them by hand.

In team development, it is especially important to make sure the same Address and Label settings are generated no matter who works on the assets.

Recommended practical setup

In practice, the following setup is easy to operate.

Configure concurrent downloads at startup

Call WebRequestQueue.SetMaxConcurrentRequests() when the app starts.

Use a fixed value for iOS, and switch based on device performance for Android, depending on your project.

Assign the `preload` label only to the minimum required assets

Include only the assets required for first launch or the title screen in preload.

If you put too many assets into this label, the initial download becomes heavy.

It is better to keep preload limited to assets that are absolutely required at the beginning.

Split labels by chapter, event, or character

Design labels based on the loading flow.

scenario_chapter_01
scenario_chapter_02
event_2026_summer
character_hero_001
voice_jp_chapter_01

Labels are easier to manage when they match the actual game progression.

Check the download size before downloading

Before a bulk download, use GetDownloadSizeAsync() to check the size.

If the size is large, you can show a confirmation dialog or recommend Wi-Fi.

If the assets are already cached, the size will be 0, so you can skip unnecessary download processing.

Start larger downloads first when downloading multiple targets

If you manage your own download queue for multiple labels or Bundles, start from the largest one.

This helps avoid the situation where only a huge Bundle remains at the end, reducing the feeling that progress has stalled near the end of the loading screen.

Design labels and Bundle splitting together

Even if your labels are cleanly separated, the actual download unit stays large if the Bundle is large.

On the other hand, splitting Bundles too finely increases the number of files.

That is why labels and Bundle splitting should be designed together.

Summary

When designing downloads with Addressables, the number of concurrent downloads and label design are important.

Simply calling DownloadDependenciesAsync does not determine download speed or operational stability.

The number of concurrent downloads should not be increased blindly.

It needs to be tuned based on device performance, network conditions, and Bundle size.

In my projects, I use 10 on iOS and either 3 or 10 on Android depending on device performance, based on real-device testing.

Also, when you manage your own queue for multiple download targets, starting from larger Bundles first helps avoid leaving one huge file until the end.

Labels make bulk downloads easy.

However, labels are only keys used to select download targets.

The actual download unit is the AssetBundle.

For that reason, label design and Bundle splitting should be considered together.

As the number of assets grows, manual Address and Label management becomes more error-prone.

In that case, using a rule-based management tool such as Smart Addresser can make operations much easier.

Next: Bundle splitting and LZ4/LZMA

In the next article, I will cover Addressables Bundle splitting and compression settings.

In particular, I plan to cover topics such as:

Whether many small files, such as ADV scenario files, should be grouped together
Whether character 3D models that will increase over time should use one Bundle per character
Download and lookup overhead caused by increasing the number of files
The downsides of splitting Bundles too finely
How to choose between LZ4 and LZMA

Bundle splitting is one of the areas where practical Addressables operation differs greatly between projects.

Next time, I will organize more concrete decision criteria.

Fast File Loading Techniques in Unity

GameDevToolLab — Fri, 19 Jun 2026 11:26:02 +0000

Temporarily Switch to 60 FPS During Loading and Load Multiple Files in Parallel

Even if your main gameplay runs at 30 FPS or another frame rate lower than 60 FPS, temporarily switching to 60 FPS during loading can improve loading times when reading multiple files.

Also, when loading multiple files, it is more efficient to start all load operations first and then wait for all of them to finish, rather than waiting for each one sequentially.

using System.Threading.Tasks;
using UnityEngine;
using UnityEngine.AddressableAssets;

public class LoadSample : MonoBehaviour
{
    async void Start()
    {
        int prevFps = Application.targetFrameRate;
        int prevVSync = QualitySettings.vSyncCount;

        // Switch to 60 FPS only during loading
        QualitySettings.vSyncCount = 0;
        Application.targetFrameRate = 60;

        // Start multiple load operations at the same time
        var playerTask = Addressables.LoadAssetAsync<GameObject>("Player").Task;
        var enemyTask  = Addressables.LoadAssetAsync<GameObject>("Enemy").Task;
        var uiTask     = Addressables.LoadAssetAsync<GameObject>("BattleUI").Task;

        // Wait until all load operations are complete
        await Task.WhenAll(playerTask, enemyTask, uiTask);

        var playerPrefab = playerTask.Result;
        var enemyPrefab  = enemyTask.Result;
        var uiPrefab     = uiTask.Result;

        // Restore the FPS settings after loading is complete
        Application.targetFrameRate = prevFps;
        QualitySettings.vSyncCount = prevVSync;

        Instantiate(playerPrefab);
        Instantiate(enemyPrefab);
        Instantiate(uiPrefab);
    }
}

There are two key points.

// Start everything first
var taskA = LoadA();
var taskB = LoadB();
var taskC = LoadC();

// Then wait for all of them at the end
await Task.WhenAll(taskA, taskB, taskC);

If you load them sequentially, like this:

await LoadA();
await LoadB();
await LoadC();

the waiting time accumulates.

On the other hand, if the load operations do not depend on each other, starting them at the same time and waiting for all of them together may reduce the total loading time.

However, loading many large assets at the same time can increase memory usage or cause spikes during asset expansion, so it is better to group them reasonably by screen or use case.

Run Network Requests and File Loading at the Same Time

When transitioning to a specific screen, you may need both of the following:

Fetch data from a network API
Load the prefab used to build the screen

If you load the prefab only after the network request finishes, the waiting time is added together.

var apiResult = await CallApi();
var prefab = await LoadPrefab();

If the network request and the loading process do not depend on each other, it is more efficient to start them at the same time.

var apiTask = CallApi();
var prefabTask = LoadPrefab();

await Task.WhenAll(apiTask, prefabTask);

var apiResult = apiTask.Result;
var prefab = prefabTask.Result;

Because the waiting time for the network request and the file loading overlaps, you can reduce the amount of time the user has to wait.

DEV Community: GameDevToolLab

A Practical Guide to Unity Addressables Bundle Splitting and LZ4/LZMA Compression

Overview

Label design and Bundle splitting must be considered together

What does Bundle splitting affect?

Bundle Mode options

Avoid casually saying “one address, one file”

Cases where grouping Bundles is acceptable

Many small files, such as VN scenario text

Cases where Bundles should be split

Assets that keep increasing, such as character 3D models

Pack Together By Label is useful, but depends on label design

How to decide whether to group or split

Difference between LZ4 and LZMA

Cases where LZMA is easy to recommend

Use LZ4 as the default for Bundles containing multiple assets

Cases where LZ4 should be the default

Practical recommended settings

Notes on Bundle splitting

Duplicate dependencies

Do not look only at update diffs

Think about initial downloads and additional downloads separately

Do not mix the responsibilities of labels and Bundle Mode too much

Practical checklist

Group or split

Compression settings

Operation

Summary

Practical Tips for Unity Addressables: Concurrent Downloads and Label Design

Overview

Addressables download speed is not determined by a single API call

Configure the number of concurrent downloads properly

Use 10 on iOS, and switch between 3 and 10 on Android based on device performance

Configure concurrent downloads at runtime

Adjust Android scoring for your project

Start downloading larger files first when downloading multiple files

Bulk downloads using labels

Sample code for DownloadDependenciesAsync

How to design labels

Labels are assigned to assets, but downloads happen per Bundle

Design labels and Bundle splitting together

Manual label management is error-prone

Use Smart Addresser

Recommended practical setup

Configure concurrent downloads at startup

Assign the preload label only to the minimum required assets

Split labels by chapter, event, or character

Check the download size before downloading

Start larger downloads first when downloading multiple targets

Design labels and Bundle splitting together

Summary

Next: Bundle splitting and LZ4/LZMA

Fast File Loading Techniques in Unity

Temporarily Switch to 60 FPS During Loading and Load Multiple Files in Parallel

Run Network Requests and File Loading at the Same Time

`Pack Together By Label` is useful, but depends on label design

Assign the `preload` label only to the minimum required assets