重いブラウザゲームを軽くする：画像・描画・読み込みを順に測る
遊びをつくる執筆にClaudeを使用しています。
ゲームを公開したあと、「動きが重い」という報告を受けたとき、最初にどこを直すか迷った経験はないだろうか。画像を圧縮してみる、コードを書き直してみる——けれど改善しないまま時間だけ過ぎることがある。重さの原因は複数あり、しかも同時に起きていることが多い。推測で直してもたまたま当たらない限り効果は出ない。この記事では、ブラウザのDevToolsを使って原因を計測で絞り込み、優先順位をつけて直す手順を説明する。
この記事の目次
推測より計測を先にする理由
ブラウザゲームが「重い」と感じられる原因は大きく三種類に分かれる。①読み込みに時間がかかる（ネットワーク・ファイルサイズ）、②描画がカクつく（フレームレート低下）、③操作への反応が遅い（JavaScriptの処理時間）。この三つは症状が似ていても対処法がまったく異なる。たとえば画像を圧縮しても、原因がJavaScriptのループにあれば何も変わらない。だから最初にやることは「どの種類の重さか」を計測で確認することだ。
計測に使うのはブラウザ標準のDevToolsで、追加インストールは不要だ。ChromeであればキーボードショートカットF12（macOSはCmd+Option+I）で開く。本記事で紹介する操作はChrome DevToolsを前提にしている。ただし、ここで計測するのは自分の開発環境での値であり、プレイヤーの端末・回線環境によって結果は異なる。計測の目的は「大きな問題を見落とさないこと」であって、数値の絶対値を追うことではない。
ステップ1：Networkパネルで読み込みの重さを確認する
まずNetworkパネルを開き、ゲームページをハードリロード（Ctrl+Shift+RまたはCmd+Shift+R）する。読み込まれたすべてのファイルが一覧に並ぶ。確認するポイントは三つだ。
- 転送サイズの合計：ページ下部に表示される。画像・音声・スクリプト合計が数MBを超えている場合は読み込みそのものが重い。
- ウォーターフォール列の長いバー：特定のファイルだけ取得に時間がかかっていないか確認する。大きな画像や音声ファイルは個別サイズをSize列で確認できる。
- スロットリングの設定：パネル上部の「No throttling」プルダウンから「Slow 4G」を選ぶと、低速回線での読み込みを再現できる。自分の回線では速くてもプレイヤーには重く見える場合があるため、少なくとも一度は確認しておく。
画像ファイルの転送サイズが大きい場合、WebP形式への変換やCanvas出力サイズの見直しが有効な選択肢になる。ただし音声や大きなJSONファイルが原因の場合もあるため、サイズ上位のファイルを種類ごとに確認してから手を入れる。
ステップ2：PerformanceパネルのFPSチャートで描画の重さを確認する
読み込みが完了した後もカクつく場合は、描画ループ自体に問題がある可能性が高い。Performanceパネルに移り、ゲームを動かしながら数秒間録画する。録画ボタンを押してゲームを操作し、止めるとタイムラインが表示される。
タイムライン上部のFPSチャートに赤いバーが出ている区間が、フレームレートの落ちているタイミングだ。Chrome DevToolsの公式ドキュメントでは、このFPSの赤バーが「ユーザー体験を損なうほどフレームレートが低下しているサイン」と説明されている。60FPSを目標に、赤バーが出た区間を拡大して原因を調べる。
FPSの下にあるCPUチャートが赤く埋まっている場合は、CPUが処理に追われていることを示す。さらに「Main」セクションのフレームチャート（火炎グラフ）を見ると、どの関数が時間を占めているかがわかる。縦に積み上がったブロックの一番上にある広いブロックが、処理の大半を使っている関数の候補だ。
フレームチャートで赤い三角マークが付いたタスクは「Long Task」と呼ばれ、50ミリ秒を超える処理を示す。メインスレッドを長く占有するためゲームの操作感に直結する。Chrome DevToolsのドキュメントではこの赤色ハイライトでLong Taskを識別できると説明している。
ステップ3：ボトルネックのスクリプトを特定して絞り込む
Long Taskや広いフレームブロックをクリックすると、下部の「Summary」タブに関数名とファイル行番号が表示される。そこからソースにジャンプし、処理内容を確認する。よくあるパターンとして、以下の三つが描画ループのLong Task原因になりやすい。
- 毎フレームの重い計算：衝突判定や経路探索を全オブジェクト分ループしているケース。変化がないフレームでは計算をスキップする、結果をキャッシュするなどで削減できる。
- 強制レイアウト（Forced Reflow）：JavaScriptでスタイルを変更した直後にoffsetWidthなどのレイアウト値を読み取ると、ブラウザが再計算を強制される。読み取りと書き込みをまとめて行うようにコードを整理する。
- Canvas全面の再描画：変化していない背景を毎フレームclearRect→drawImageしている場合、背景専用のCanvasレイヤーを分離して変化のある前景だけ再描画することで負荷を減らせる。
コードを変更したら、同じ手順で再度録画して比較する。変更前後のFPSチャートとCPU使用率を並べて見ることで、改善が効いているか、別の問題が残っているかを確認できる。
計測の前に決めておく：パフォーマンスバジェットの考え方
「どの数値になればOKか」を計測前に決めておくと、改善作業に終わりを設けやすい。これをパフォーマンスバジェットという。web.devの解説では、予算はチームが性能とデザインのトレードオフを意図的に判断するための基準として機能すると説明されている。ゲーム向けに実用的な出発点を挙げると次のようになる。
- 初回読み込み合計転送サイズ：スマートフォン・低速回線を意識するなら圧縮後2MB以内を目標にする（ゲームの規模によって調整する）
- フレームレート：アクションや動きのあるゲームは60FPS安定を目標に、FPSチャートの赤バーがゼロであることを確認する
- Long Task：操作に直接関係するフレームでは50ミリ秒超のタスクをなくすか最小化する
これらの数値はゲームのジャンルや対象端末によって変わる。パズルゲームと音楽ゲームでは適切なFPS目標が異なるし、スマートフォン単体で動かすゲームはより慎重なバジェット設計が必要だ。まず一度計測した結果を見てから、自分のゲームにとって現実的な目標を設定するとよい。
計測→修正→公開のサイクルを回す
ここまでの手順をまとめると、次の順番で進める。
- Networkパネルで読み込みサイズと時間を確認し、大きなファイルを特定する
- スロットリングをSlow 4Gに設定して低速回線での読み込みを確認する
- Performanceパネルで録画し、FPSチャートの赤バーとCPUチャートを確認する
- フレームチャートでLong TaskとCPU時間の大きな関数を特定する
- 一箇所だけ変更し、同条件で再計測して効果を確認する
- バジェットの目標値に達したら改善版として公開する
一度に複数を変更すると、どの変更が効いたのかわからなくなる。一箇所変えて計測する習慣をつけると、次のゲームでも原因の切り分けが早くなる。計測ツールはすでにブラウザに入っている。「なんとなく重い」と感じた次の瞬間に開くのが、最初の一歩だ。
なお、本記事で紹介した計測手順はローカルの開発環境を前提にしている。実際のプレイヤーが使う端末や回線は多様であり、自分の開発機での計測結果がそのまま全ユーザーの体験に当てはまるわけではない。計測値は問題の有無を確認する手がかりとして使い、実際のプレイヤーからのフィードバックと合わせて判断することを勧める。
本記事はClaude（Anthropic）が執筆した。引用した操作・仕様・用語はChrome DevTools公式ドキュメントおよびweb.devを参照している。操作画面のスクリーンショットによる実証・ゲーム実機での計測は含んでいない。ブラウザのバージョンアップでUIが変わることがあるため、最新の操作方法は公式ドキュメントで確認することを勧める。
