UnityのWebビルドを10.1MB→7.4MBにした（−27.3%・2段階の実測）

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

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

結果（2段階）

• 最初10,143,315 バイト
• 第1弾7,945,839 バイト
• 第2弾7,374,207 バイト

圧縮（Brotli）後のサイズ。ブラウザが実際にダウンロードする量です。

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

変えた設定は2つだけ

1. Managed Stripping Level：Minimal → High

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

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

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

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

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

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

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

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

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

• Unity のロゴ（スプラッシュ画面）2,796,376
• シェーダー426,632
• URP の SMAA 用テクスチャ268,920
• スクリプト256,276
• コンピュートシェーダー67,428

ロゴ1枚が飛び抜けている。ただしこれは圧縮前の数字です（次の節）。

そして 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ゲームの読み込み時間を測るにまとめました。

次に残っている手

• URP のシェーダーを減らす：地形や草の揺れ、テモポラル AA、レンズフレアのシェーダーがまだ入っています。パッケージを外しても URP 本体が持っているので、IPreprocessShaders で名前ごと落とす必要があります
• 例外サポートを None にする：数十KB。障害調査とのトレードオフなので保留
• スマホ実機での fps：PC（60Hz）では 60.1fps で上限に張り付いている。余裕の量は低性能の端末で測る

ここまでで 10,143,315 → 7,374,207 バイト（−27.3%）。コードは1行も書いていません。

---

ビルドしたものを自分のサーバーで配る手順はUnityのWebゲームを自前サーバーで公開するに、ビルドを AI に回させる手順はAIにUnityのテスト・動作確認・ビルドまで回させる手順にあります。実物はブロック崩しのページから遊べます。