ゲームの読み込みを速くする手順：画像の形式と容量をどう判断するか

なぜ画像が読み込み時間に直結するのか

Webブラウザでゲームを起動するとき、HTMLが読み込まれてからスクリプトと画像が並行して取得されます。スクリプトが小さくても、背景・キャラクター・UIの画像が合計で数MBあれば、その転送が終わるまで画面には何も映りません。とりわけ初回表示（ファーストビュー）に使われる画像はCritical Rendering Pathに乗るため、そこを最初に削ることが全体の体感速度を下げる最短経路です。モバイル回線では転送速度が揺れやすいため、容量の差がそのまま待ち時間の差になります。

最適化を「見た目を犠牲にすること」と捉えると手が止まりがちですが、フォーマットと圧縮レベルを正しく選べば、画質の劣化をほぼ感じないまま容量を半分以下にできるケースがあります。MDNの資料によれば、WebP（ロスシー）は同等の視覚品質においてJPEGより25〜35%小さく、AVIFはさらに高い圧縮率を持ち、JPEGと比べて中央値で50%前後の削減が報告されています（出典：MDN Web Docs「Image file type and format guide」）。ただし圧縮ツールや設定値によって結果は変わるため、自分の素材で試して確認することが前提です。

フォーマットをどう選ぶか：WebP・AVIF・PNG・JPEGの判断基準

画像フォーマットの選択は、コンテンツの性質とブラウザ対応範囲の両方で決まります。以下の方針を出発点にしてください。

• 写真・グラデーションが多い背景画像→ WebP（ロスシー）を第一候補にする。JPEGよりファイルサイズが小さく、透過も扱える。
• 圧縮率を最大化したい場合→ AVIFが有利。ただしエンコード時間が長く、完全にダウンロードされるまで表示が始まらない特性がある。
• ドット絵・UIアイコン・透過が重要な素材→ WebP（ロスレス）またはPNG。ロスシー圧縮はエッジのにじみが出やすい。
• ロゴ・シンプルなアイコン→ SVGを使うと解像度に依存せず容量も小さく抑えられる。

ブラウザ対応について：WebPはChrome・Edge・Firefox・Safariを含む現行ブラウザ全般で利用可能です。AVIFはChrome 85以降・Firefox 93以降・Safari 16.1以降で対応していますが、それ以前の環境へのフォールバックが必要です。両方に対応するには、後述する<picture>要素を使います（出典：MDN Web Docs）。

圧縮の手順：品質値の選び方と確認方法

フォーマットを決めたら、次は圧縮レベルを設定します。品質値（quality）を下げるほどファイルは小さくなりますが、あるラインを超えるとブロックノイズや色の劣化が目立ちます。具体的な値はツールごとに尺度が異なるため、以下の確認手順を毎回行うことを推奨します。

1. オリジナル画像を用意し、ファイルサイズをメモしておく。
2. Squoosh（Google製のブラウザ上で動く変換ツール）や ffmpeg など手元で使えるツールで、品質値を変えた複数バージョンを書き出す。たとえば WebP の quality=80・60・40 の3パターンを作る。
3. 書き出した画像を実際のゲーム画面サイズで表示し、オリジナルと並べて見比べる。気になる劣化が出ない最低品質値がそのゲームにとっての適切な設定。
4. 採用した設定のファイルサイズをオリジナルと比較してメモする。削減率を記録しておくと、後から設定の根拠を確認しやすい。

「品質=75なら必ずOK」という万能の値はありません。写真とドット絵では劣化の出方が全く異なるため、素材の種類ごとに確認を行ってください。

HTMLへの組み込み：フォーマット切り替えと遅延読み込みの書き方

最適化した画像をHTMLに組み込む際、フォーマットのフォールバックと読み込みの優先度を正しく設定することで、対応ブラウザでは最も軽いフォーマットが使われ、未対応ブラウザではJPEGが使われる構成を作れます。

フォーマット切り替えの基本パターン

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="ゲームのタイトル画面" width="800" height="450">
</picture>

ブラウザは上から順に対応しているフォーマットを選びます。AVIFに対応していればAVIFを、WebPに対応していればWebPを使い、どちらも非対応ならJPEGにフォールバックします。

読み込み優先度の設定

ファーストビューに表示されるタイトル画面や背景は、早く読み込まれるほど体感速度が上がります。web.devの解説によれば、fetchpriority="high"をimgに付けると、ブラウザがその画像をCritical Rendering Pathとして高優先度で取得します。反対に画面外のサブ画像にはloading="lazy"を付けると、スクロールして近づくまで取得を遅らせ初期転送量を減らせます（出典：web.dev「Image performance」）。

<!-- ファーストビューの画像：高優先度で取得 -->
<img src="title.webp" alt="タイトル画面" width="800" height="450"
     fetchpriority="high">

<!-- 画面外の画像：近づくまで取得を遅延 -->
<img src="stage2-bg.webp" alt="ステージ2の背景" width="800" height="450"
     loading="lazy">

loading="lazy" はファーストビューの画像に付けると逆効果です。最初に表示される画像には使わないでください。

レスポンシブ対応：srcsetとsizes

スマートフォンとPCで画像の表示サイズが大きく異なる場合、srcsetとsizes属性を使うと端末に合ったサイズの画像を提供できます。例えばPCでは1200px幅の画像が必要でも、スマートフォンでは400px幅で十分なことが多く、大きな画像をそのまま送ると容量を無駄に消費します。

<img
  srcset="title-400.webp 400w, title-800.webp 800w, title-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
  src="title-800.webp"
  alt="タイトル画面"
  width="1200" height="675">

最適化前後で確認すること

変換後に必ず確認したい項目を整理します。これらを確認せずに本番に反映すると、見た目の問題や想定外の動作が起きることがあります。

• 画質の目視確認：実際のゲーム画面サイズで表示し、エッジのにじみやブロックノイズを確認する。特にドット絵は小さなズレが目立ちやすい。
• 透過の確認：透過PNGをWebPに変換した場合、アルファチャンネルが正しく保持されているかを白・黒・柄物の背景上で確認する。
• ファイルサイズの比較：変換前と変換後のサイズを記録し、削減率を把握する。容量が増えた場合は元のフォーマットの方が適している可能性がある。
• ブラウザDevToolsでの確認：NetworkタブでHTTPレスポンスヘッダーのContent-Typeを確認し、意図したフォーマットが配信されているかを見る。
• 複数端末での表示確認：スマートフォンとPCの両方で見た目と読み込みを確認する。高DPI端末では低解像度の画像がぼけて見えることがある。

どこから始めるか：優先順位の付け方

ゲームに含まれる全画像を一度に最適化しようとすると作業量が大きくなります。体感速度への影響が大きい順に優先度をつけると、少ない作業で効果を確認しやすくなります。

1. ファーストビューの画像（タイトル画面・初期背景）：最初に表示される画像のサイズを減らすと、起動待ちの体感が最も変わりやすい。
2. ファイルサイズが大きい画像：100KB以上の画像はDevToolsのNetworkタブで探せる。大きいものから手をつける。
3. 繰り返し使われる素材：複数箇所で読み込まれる共通UIや背景は、1枚の削減効果が回数分積み重なる。
4. アニメーションGIF：GIFは容量が大きくなりやすく、WebPアニメーションや短いCSSアニメーションへの置き換えを検討する価値がある。

最適化の目安として、ゲームの全画像の合計を圧縮前と圧縮後で比較し、削減率を記録しておくと将来の更新でも判断しやすくなります。「どの設定でどれだけ変わったか」を自分のゲームの素材で確認することが、汎用的なガイドラインより確実な根拠になります。アソバースでは更新したZIPやHTMLを再投稿することで、最適化後のバージョンに差し替えられます。軽量化した版を確認してからの差し替えを推奨します。

この記事はClaude（AI）が執筆しました。手順は公式ドキュメントをもとに整理していますが、実際の測定値やツールの操作結果は掲載していません。自分の素材で確認した結果を判断の基準にしてください。