I Cut My Build Size by 38% in Three Nights - Texture Compression + Addressables

This is not a magic trick. It is a boring checklist executed with discipline.

The project was a small Unity action game headed for PC first, with a mobile port on the roadmap. The first standalone Windows build was larger than the team expected, install friction on Itch looked bad, and CI uploads were slower than they needed to be. Instead of rewriting systems, we spent three focused evenings on textures and Addressables packaging. The player-facing build dropped by about 38% compared with the baseline, measured on the same commit after a clean rebuild.

If you are a solo dev or a tiny team, this workflow is built for you. You can parallelize some steps, but the order below matters.

What “38 percent” actually means

We compared:

• Baseline - default import settings on dozens of textures, most content in Resources or direct references, one monolithic build
• After pass - platform-specific texture overrides, crunch where appropriate, and Addressables for large content buckets

We measured compressed download size of the shipping folder Unity produced for Windows x64, not editor disk usage. Your exact numbers will differ, but the levers stay the same.

Night 1 - Baseline, blame list, and quick wins

Step 1 - Generate a build you trust

Turn off development build, match the scripting backend you ship with, and run Build Report or a similar size breakdown (Unity’s Build Profiles and Build Report tooling in modern versions make this fast). Export a CSV or screenshot so you are not guessing.

Step 2 - Sort assets by footprint

Textures almost always dominate indie builds that are not audio-heavy. Sort by uncompressed import size and by serialized file size. Anything in the top 20 list that is not a logo or hero art deserves scrutiny.

Step 3 - Kill obvious waste in one pass

• Duplicate imports - same PNG referenced twice with different import settings
• Oversized sources - 4K plates used on props that render at 128 pixels tall
• Alpha channels you do not need - RGBA where RGB would do

Pro tip: Fix source files when you can. Import settings are powerful, but a 8K PSD flattened to PNG will always fight you.

Step 4 - Standardize naming and folders

We moved “ship” textures under Art/Textures/Game and kept concept art out of Resources entirely. That alone prevented accidental inclusion in player builds.

For a clean art-to-engine handoff mindset, see our Blender to Unity and Godot export checklist.

Night 2 - Texture compression that survives a real build

Pick formats per platform, not “whatever defaulted”

On PC, BC7 or DXT-family formats are common for realistic content. On mobile, ASTC block sizes trade quality for size in a predictable way. The mistake is leaving Automatic on everything and hoping the build pipeline sorts it out.

Max size overrides beat endless manual tweaks

Use Max Size aggressively on small UI icons, VFX sheets, and noise masks. A 512 cap on a minor decal is often invisible in motion but measurable in the build.

Crunch compression for disk size

When quality allowed, enabling Use Crunch Compression on supported formats reduced on-disk size sharply. We paired crunch with a short in-engine review on target hardware so banding stayed acceptable.

Common mistake: Crunching normal maps without checking tangent-space artifacts. Test materials under your real lighting setup, not a flat gray scene.

Streaming and mip bias

For large backgrounds, confirm Generate Mip Maps is on where it should be, and consider Streaming Mipmaps if you use the Memory Profiler and see spikes. This night was mostly about import rows, but mip policy is the bridge to runtime stability.

A quick reference for mobile ASTC choices

When you add Android or iOS targets, block size is the dial you turn most often:

• 4x4 - sharper, heavier
• 6x6 - common default for balanced 3D
• 8x8 - softer, smaller

We did not chase perfection per texture on night two. We set sane defaults per folder (characters vs UI vs VFX), then spot-checked hero assets in play mode.

Sprite sheets and padding

2D teams often forget that tight sprite packing plus padding changes how much empty texel space ships. If you pack atlases inside Unity, re-run the build report after each atlas change. One regenerated atlas moved a surprising amount of bytes in our test project because several sheets had been rebuilt at 2K after an art pass.

Night 3 - Addressables without rewriting the game

We did not convert every prefab on day one. We scoped Addressables to the heavy buckets:

• Audio banks for music and long ambiences
• Environment bundles per chapter
• Cosmetic variants players unlock late

Anything that still needed to load in the first ten seconds stayed in the core build on purpose. The goal was player-perceived download size, not ideological purity.

Why we did not touch code first

Gameplay code was stable and demo-ready. Refactoring singletons into async loaders would have taken a week and risked regressions. Addressables let us mark assets and re-bucket them with a smaller blast radius. Script changes were limited to load calls at chapter boundaries where designers already expected a short hitch.

If you are still on Resources.Load for large audio clips, you are often paying startup cost and build size together. Moving those clips first is a high-confidence move with minimal scene rewiring.

Group design that stays debuggable

• One group per logical slice you might update alone (Chapter 2 art, Seasonal cosmetics)
• Consistent address strings documented in a single enum or static class
• Labels for platform when mobile and PC diverge

Build steps you must not skip

After moving assets, run Addressables build before the player build. If keys drift, you will see failures early. Our team keeps a short smoke scene that loads one asset from each new group.

If you hit invalid keys at runtime, our Unity Addressables invalid key troubleshooting guide walks through the usual causes.

Optional remote content later

We kept everything local for this pass. The win came from not shipping unused groups and splitting content so the base player download shrank. Remote hosting is a follow-up task, not a prerequisite for a smaller first build.

Results at a glance

What I would do differently next time

• Run the texture audit before vertical slice freeze, not after marketing asked for a demo build
• Automate a build size budget in CI with a hard fail on regressions
• Pair audio with compression presets in the same sprint so music does not become the next hidden giant

For a broader shipping checklist, the build pipeline lesson in our Unity 2026 course ties player settings and smoke tests together.

FAQ

Will Addressables always reduce build size?
Not automatically. If you mark everything must-load-at-startup, you mainly changed tooling, not download size. The win comes from deferring or splitting content.

Is Crunch always safe?
No. It is a lossy step. Use it where artifacts are acceptable and keep source PNGs for re-export if quality regresses.

Do I need Addressables for a jam game?
Often no. For jams, aggressive max size rules and fewer textures beat architectural churn.

What about Addressables and source control?
Commit group configs and address entries, and document the build order for teammates. Nothing secret here, just consistency.

Where can I read official docs?
Start with Unity’s documentation on Addressables and the Texture Import Settings reference (search from the Unity Manual home). Those pages stay current with your editor version.

How do I prove the 38 percent number on my machine?
Zip the player build folder with the same tool each time, or compare Build Report totals before and after. Use one branch, two sequential builds, and write down editor version and scripting backend so the comparison is honest.

What if shaders or meshes are the problem?
They can be. This case study happened to be texture-heavy. If meshes dominate, run Mesh Compression and LOD passes, and watch Read/Write flags you do not need. Audio-heavy games should profile import load type and compression formats in parallel.

Does this help Steam depot size?
Usually yes for the game bytes you upload, but Steam also wraps your content. Smaller raw builds still mean faster uploads, cheaper backups, and happier collaborators on slow connections.

Conclusion

Smaller builds are mostly inventory discipline plus a few powerful import toggles. Addressables then let you stage what ships first without rewriting gameplay.

If this saved you an evening of guesswork, bookmark it and share it with whoever owns your next release branch. When you are ready to go deeper on data and loading patterns, compare approaches in our ScriptableObjects vs JSON vs SQLite write-up so your content pipeline matches your team size.