Unity WebGLの容量を27%削る方法（10.1→7.4MB）

ブロック崩しの Web ビルドが約10MB ありました。スマホで開くと重い。

削りにいったところ、設定を2つ変えるだけで 21.7%、さらに使っていないパッケージを外して合計 27.3% 小さくなりました。ビルド時間まで短くなっています。

結果（2段階）

第1弾は設定を2つ変えただけ。第2弾は使っていないものを外しただけです。コードは1行も書いていません。

変えた設定は2つだけ

1. Managed Stripping Level：Minimal → High

C# のコードのうち、使っていない部分を削る強さです。Minimal は最小限しか削りません。High にすると、到達しないコードをかなり積極的に削ります。

これが wasm.br に効きました。

2. IL2CPP Code Generation：速度優先 → サイズ優先

IL2CPP が C# を C++ に変換するときの方針です。既定は実行速度を優先しますが、サイズ優先に切り替えられます。

ブロック崩し程度の処理では、速度の差を体感できませんでした。60fps は維持しています。

UnityEditor.PlayerSettings.SetManagedStrippingLevel(wt, UnityEditor.ManagedStrippingLevel.High);
UnityEditor.PlayerSettings.SetIl2CppCodeGeneration(wt, UnityEditor.Build.Il2CppCodeGeneration.OptimizeSize);

変えなかった設定と、その理由

削ったあとが本番：壊れていないかを確認する

Managed Stripping の High には副作用があります。使っていないと判断されたコードが削られるので、リフレクション経由で呼んでいる処理や、JsonUtility、Addressables から参照している型が消えることがあります。

やっかいなのは、エディターでは動くのにビルドしたものだけ壊れる点です。自動テストも通ってしまいます。

なので、ビルド後は必ずブラウザで確認しました。

今回はすべて問題なしでした。もし壊れていたら、link.xml で「この型は残す」と指定して作り直すことになります。

ついでに直したこと

ブラウザのタブに Unity Web Player | breakout と出ていました。Player Settings の Product Name が既定のままだったからです。ゲーム名と運営名を設定して、ブロック崩し に変わりました。

小さいことですが、共有されたときに目に入る場所です。

第2弾：何が入っているかを数えてから削る（2026-09-16 追記）

7.9MB のうち何がどれだけ占めているのか。当てずっぽうで設定をいじる前に、ビルドレポートを数えました。

Unity は毎回 Library/LastBuild.buildreport にビルドの内訳を残しています。これを読むと、アセット1つずつのサイズが出ます。

UnityEditor.AssetDatabase.LoadAssetAtPath<UnityEditor.Build.Reporting.BuildReport>(path)
  → report.packedAssets[].contents[] に packedSize と sourceAssetPath

数えた結果はこうでした。

そして Texture2D の中身の内訳が、これです。

Unity のロゴ1枚で、アセット全体の72%。

2Dのブロック崩しに画像素材は1つも入れていないので、入っているのはテンプレートとエンジンのものだけです。

効かなかった：スプラッシュ画面の停止

Unity 6 では Personal でもスプラッシュ画面を止められます。手元で確かめました。

UnityEditor.PlayerSettings.SplashScreen.show = false;

止めてビルドし直した結果がこれです。

1バイトも減っていない。むしろ 1,319 バイト増えた。

理由は単純で、ロゴのような画像は Brotli でほとんど消えるからです。ビルドレポートが出すのは圧縮前のサイズなので、「大きい順に並べて上から潰す」をやると、こういう空振りをします。

なお、スプラッシュ自体はそのまま止めています。サイズではなく、起動してから遊べるまでの時間が短くなるためです。

効いた：使っていないパッケージを外す

残るのは wasm（コード）とシェーダーです。ここに効くのは、そもそもプロジェクトに入れているものを減らすことでした。

Packages/manifest.json を開くと、テンプレートが入れた依存が 55件ありました。2Dのブロック崩しに必要ないものが並んでいます。

外したのは 39件です。

残したのは16件だけ。URP・Input System・uGUI・2D 物理・オーディオ・Test Framework・CLI の Pipeline などです。

あわせて、テンプレートが置いていった Assets/Welcome（チュートリアル用の画面）とサンプルシーン2つも消しました。

結果

ビルドレポート側でも、シェーダーが 426,632 → 356,420、スクリプトが 256,276 → 145,760 に減っていました。パッケージが持ち込んでいた分です。

壊れていないかの確認（第2弾）

パッケージを消すのは、設定を変えるより乱暴です。確認はこの順でやりました。

1. 1

   エディターを開き直す

   コンパイルエラー0・警告0
2. 2

   EditMode テスト

   44/44 合格
3. 3

   PlayMode テスト

   5/5 合格（ビルド対象は WebGL のまま）
4. 4

   ローカルで遊ぶ

   タイトル → 開始 → 発射 → ボールが動くまで
5. 5

   コンソールを見る

   ブラウザのエラー0
6. 6

   本番に差し替えて同じ確認

   公開 URL でもう一度

消しすぎていれば、たいていはコンパイルか起動で落ちます。今回は落ちませんでした。

で、どれだけ速くなったのか

測りました。起動が 約705ms → 約569ms（−19%）、本番の回線ではダウンロード 0.76秒＋起動 0.62秒で遊べます。展開後の wasm が 38.3MB → 23.7MB（−38%）と、ダウンロード量より大きく減っていたのが効いています。

計測の方法とつまずいた点はUnityのWebゲームの読み込み時間を測るにまとめました。

第3弾：使っていないシェーダーを落とす（2026-09-18 追記）

パッケージを39件外しても、URP 本体が持っているシェーダーは残ります。ビルドレポートで圧縮前の大きい順に並べると、2D のブロック崩しでは1回も使わないものが並んでいました。

IPreprocessShaders で、これらを含む9本の変種を全部落としました。

public void OnProcessShader(Shader shader, ShaderSnippetData snippet, IList<ShaderCompilerData> data)
{
  if (EditorUserBuildSettings.activeBuildTarget != BuildTarget.WebGL) return;
  if (!Drop.Contains(shader.name)) return;
  data.Clear();   // この shader の変種を全部落とす
}

圧縮前で 130KB 以上あったものが、圧縮後では 63KB の差にしかなりません。シェーダーはテキストに近く、Brotli がよく効くためです。第1弾・第2弾に比べると小さい効果ですが、ビルド時間も 109秒まで下がりました。

次に残っている手

• 例外サポートを None にする：数十KB。障害調査とのトレードオフなので保留
• スマホ実機での計測：PC（60Hz）では 60.1fps で上限に張り付いています。エディターで垂直同期を切って測ると 1フレーム 2.03ミリ秒（60Hz の 16.67ミリ秒に対して 14.64ミリ秒の余裕）でした。実機での数字は別に測ります

ここまでで 10,143,315 → 7,311,364 バイト（−27.9%）。コードはゲーム側に1行も書いていません（足したのはビルド時に効くエディター用のスクリプトだけです）。

ビルドしたものを自分のサーバーで配る手順はUnityのWebゲームを自前サーバーで公開するに、ビルドを AI に回させる手順はAIにUnityのテスト・動作確認・ビルドまで回させる手順にあります。検証に使ったゲームの公開は終了しましたが、当時の実測値と画面はこの記事に残しています。