Unity WebGLの読み込みが遅い：ビルドサイズを半分にする方法
遊びをつくる執筆にClaudeを使用しています。
Unity WebGLのビルドをそのまま公開すると、何もしていないプロジェクトでも数十MBのファイルが生成されることがあります。プレイヤーはゲームを開いた瞬間から長いロード画面と向き合うことになり、その間に離脱が起きます。「読み込みが遅い」という問題の大半は、ビルドサイズそのものが原因です。 この記事では、Unity WebGLのビルドサイズを削減するための具体的な設定と判断基準を整理します。「なぜ重くなるのか」を把握してから、効果の高い手順を順に試すことで、ファイルサイズを半分前後まで抑えられるケースが多くあります。ツールの選択や凝ったコーディングより、まずビルド設定の見直しから始めるのが最短ルートです。
なぜUnity WebGLのビルドは大きくなるのか
Unity WebGLのビルドフォルダには、主に次の要素が含まれます。
- framework.js：UnityのランタイムをJavaScriptに変換したファイル
- wasm（WebAssembly）ファイル：C#コードをコンパイルした実行バイナリ
- dataファイル：シーン・テクスチャ・音声などのアセット一式
このうちwasmはC#コードの量に比例して増え、dataはアセットの総量で決まります。frameworkはUnityのバージョンやビルド設定によって変わります。
多くのプロジェクトでサイズが膨れる主な原因は、未使用アセットの混入と圧縮設定の未適用の2点です。Unityはデフォルトで、プロジェクトに存在するアセットのうちシーンから参照されるものをすべてビルドに含めます。使わないつもりでもResourcesフォルダに置いてあるファイルは全部入ります。さらに、圧縮なしのビルドはgzip圧縮済みのものと比べて3〜5倍のサイズになることも珍しくありません。
効果が大きい設定を優先順に試す
削減効果の高いものから順に試すのが効率的です。1ステップごとにビルドして差分を確認しながら進めてください。
1. 圧縮形式をBrotliに切り替える
Player Settings → Publishing Settings → Compression Format を Brotli に設定します。デフォルトが Gzip になっているプロジェクトでは、Brotliに変えるだけでビルド後のファイルが10〜20%小さくなることがあります。ただしBrotliは展開に若干のCPU負荷がかかるため、ターゲットデバイスがローエンドのスマートフォン中心であれば、Gzipとの比較を実機で確認しておくことをお勧めします。
サーバー側の設定も必要です。WebサーバーがBrotliのContent-Encodingヘッダを正しく返せる構成かどうかを確認してください。設定が合っていないと、ブラウザが圧縮ファイルを解凍できずエラーになります。アソバースのようなプラットフォームにZIPとして投稿する場合は、プラットフォーム側の配信設定に従ってください。
2. IL2CPPのコードストリッピングを最大に設定する
Player Settings → Other Settings → Managed Stripping Level を High にします。IL2CPPはC#コードをC++経由でwasmに変換しますが、このとき使われていないクラスやメソッドが大量に残ります。ストリッピングレベルを上げると、それらが除去されてwasmが小さくなります。
注意点として、ストリッピングレベルを上げるとリフレクションを多用するコードが実行時に壊れることがあります。ビルド後は必ず動作確認を行い、エラーが出た場合は link.xml ファイルを使って必要なクラスを除外対象から保護してください。
3. Resourcesフォルダを整理する
Unityは Resources フォルダ内のファイルをすべてビルドに含めます。「とりあえず置いた」テクスチャ・音声・プレハブがここに眠っていないか確認してください。実際には Addressables（アドレサブルアセットシステム）やAssetBundleに移行するのが根本的な解決ですが、まず不要ファイルをResourcesから外すだけでも大幅な削減につながることがあります。
4. テクスチャの圧縮設定を見直す
WebGLでは ASTC または DXT（BC） 形式のテクスチャ圧縮が有効です。テクスチャの Inspector → Texture Type で Default、Format を Automatic にしていると、WebGL向けに最適化されない場合があります。
特にUIの大きな背景画像やスプライトシートは非圧縮のまま入ることが多く、そこだけで数MBの差が出ることもあります。テクスチャを選択して Max Size と Compression を確認し、用途に合わせて下げることをお勧めします。品質の変化はUnity EditorのPreviewで確認できます。
5. 音声ファイルの設定を変える
音声は見落とされやすいサイズの原因です。BGMなど長い音声ファイルは Streaming に、短いSEは Compressed In Memory に設定するのが基本です。音声ファイルを選択して Inspector → Load Type と Compression Format を確認してください。Decompress On Load のまま放置されているファイルがあると、ビルドサイズだけでなくメモリ消費にも影響します。
削減効果を数字で把握する判断フロー
手順を試す前後でビルドフォルダのファイルサイズを記録しておくと、どの施策が効いたか判断できます。Unityの Build Report を使うと、アセットごとの容量内訳を確認できます。2021以降のバージョンでは Window → UI Toolkit → Build Report Inspector（またはサードパーティの「Build Report Tool」）が利用できます。
判断の目安として次の順序をお勧めします。
- ビルドレポートで上位10件のアセットを確認する
- 圧縮設定（Brotli・ストリッピング）で変わるサイズを計測する
- 上位アセットのうちテクスチャ・音声が占める割合が大きければ、それぞれ個別に設定を変えて再計測する
- wasmが全体の大半を占めているなら、コードの整理やストリッピングの強化を検討する
どの施策を組み合わせても10MB未満に収まらない場合は、Addressablesを使った動的ロードへの移行を検討するフェーズです。ただしその実装コストは高いため、最初から目指す方針ではなく「一通り設定で削れなかったとき」の次の選択肢として捉えてください。
よくある落とし穴と対処
Development Buildのままにしている：開発中の利便性のために Development Build チェックをオンにしたまま公開用ビルドを出すと、デバッグ情報やプロファイラ関連のコードが含まれてサイズが増えます。公開前は必ずチェックを外してください。
例外処理の設定を見落としている：Player Settings → Other Settings → Exception Support が Full になっていると、例外スタックトレース用のコードがwasmに大量追加されます。パフォーマンス重視の公開ビルドでは Explicitly Thrown Exceptions Only または None に下げることを検討してください。ただしデバッグが難しくなるため、開発中は戻す運用が必要です。
WebGL 1.xと2.xの選択：現在のUnityではWebGL 2.0がデフォルトです。ターゲットブラウザの対応状況を確認したうえで、不要であればWebGL 1.xに戻さないよう注意してください（古い設定が残っているプロジェクトでの話です）。
次の行動
まずUnityのBuild Reportを開き、ビルドに含まれるアセットの上位10件とwasmのサイズを書き出してください。それだけで「どこを削るか」の方針が決まります。圧縮設定とストリッピングを変えた後に再ビルドして差分を測り、効果を確認してから次の施策に進むのが最も確実な手順です。軽くなったゲームはアソバースへのZIP投稿でそのまま公開できます。
参考資料
- Unity公式ドキュメント「WebGL: Deploying compressed builds」
- Unity公式ドキュメント「Managed code stripping」
- Unity公式ドキュメント「Build Report Inspector package」
- Unity公式ドキュメント「Audio Clip Import Settings」
