Chrome DevToolsで実際に使っている機能だけの話｜LCP計測とCanvasゲームのデバッグ
DevToolsのテクニック集は数あれど、毎回開くパネルは少ない。このブログのLCP計測と自作Canvasゲームのデバッグで本当に使っているNetwork・Performance・Memory・デバイスモードの使いどころを実例で書く。
「DevTools上級テクニック◯選」みたいな記事は世の中にいくらでもあるし、正直この記事の初版もそういう網羅型だった。でも読み返してみると、自分自身が15個のうち日常的に使っているのは半分もなかった。それでは意味がないので、全面的に書き直す。
このブログ（clvr.lol）のCore Web Vitals改善と、自作のブラウザゲームや画像圧縮ツールのデバッグ。この2つの作業で自分が実際に繰り返し開いているパネルと、そこで何を見ているかだけを書く。使っていない機能を使っているとは書かない。
Networkタブ: 「どの画像が犯人か」を特定する場所
このブログのLCP改善は、要するに「重い画像を探して潰す」作業だった（経緯は画像圧縮でLCPを直した話に書いた）。そのとき最初に開くのがNetworkタブで、見るのはほぼ3箇所に決まっている。
- 「Disable cache」にチェック。これを忘れると2回目以降の読み込みがキャッシュから返ってきて、初訪問ユーザーの体験と全然違う数字を見ることになる。昔これを忘れて「もう十分速いじゃん」と勘違いしたことがある
- 「Img」フィルタ + Sizeカラム。画像だけに絞ってサイズ順に眺めると、犯人は一瞬でわかる。うちの場合は3.8MBのPNGが堂々の1位だった
- Throttlingを「Slow 4G」に。手元の光回線では何を読んでも一瞬なので、遅い回線を再現しないと差が見えない。ちなみにこのプリセット、少し前のChromeまでは「Fast 3G」という名前だった（中身はほぼ同じで名前が現実に追いついた）
やることはこれだけで、正直Networkタブの機能の大半は使っていない。でもこの3点セットだけで「何が遅いか」の当たりはつく。
Performanceパネル: LCPの正体を目で確かめる
Lighthouseのスコアだけ見ていると「LCPが遅い」はわかっても「何がLCP要素なのか」を勘違いすることがある。Performanceパネルで録画すると、タイムライン上にLCPのマーカーが出て、クリックすればどの要素がLCPとして扱われたかが確認できる。うちのブログでは想定どおりアイキャッチ画像だったが、ページによってはヒーローのテキストブロックだったりするので、思い込みで最適化する前に一度は確かめた方がいい。
最近のChromeだと、Performanceパネルは録画しなくても開いた瞬間にLCP・CLS・INPのローカル計測値が表示されるようになった。「今このページを自分の環境で開いたらどうか」をサッと見るだけなら、もう録画すら要らない。改善作業中に何度もリロードしながら数字の変化を追うのに重宝している。
ゲームのデバッグでは使い方が変わって、録画してフレームの中身を見る。Canvasのゲームで動きがカクつくとき、疑うのはrequestAnimationFrameのコールバックが1フレーム分の時間（60fpsなら約16ms）に収まっているかどうか。録画のメインスレッドの帯で、長く伸びているタスクをクリックすると、どの関数が時間を食っているかが階層で出る。感覚で「ここが重いはず」と当たりをつけるより、録画を見る方が確実に早い。
Memoryパネルとイベントリスナー: リスタートで増殖するバグ
ゲームで一度やらかしたのが、リスタート処理のリスナー解除漏れだ。ゲームオーバーからリスタートするたびにkeydownのリスナーが増えていって、キー入力に二重三重に反応する。プレイ中は気づきにくく、何度かリスタートして初めて挙動がおかしくなるタイプのバグだった。
このとき役に立ったのが2つ。ひとつはConsoleで使えるgetEventListeners(document)。DevToolsのConsole専用のユーティリティ関数で、その要素に登録されているリスナーが種類ごとに一覧で出る。リスタートを繰り返して配列が伸びていくのを見た瞬間に原因が確定した。
もうひとつがMemoryパネルのHeap snapshotで、これは「リスナーは解除したはずなのにメモリが増え続ける」ときの最終手段。操作の前後でスナップショットを2枚撮ってComparisonで差分を見ると、解放されていないオブジェクトが残っているのがわかる。正直、Heap snapshotを開くのは年に数回で、たいていはgetEventListenersとコードの見直しで片がつく。でも「疑わしいときに確かめる手段がある」と知っているだけで、当てずっぽうの修正をせずに済む。
デバイスモード: Canvasゲームのモバイル確認はここから
ゲームもツールも、アクセスの半分以上はスマホからなので、モバイル表示の確認は毎回やる。Cmd+Shift+M（WindowsはCtrl+Shift+M）でデバイスモードに切り替えて見るのは主に2つ。
- タッチ操作の挙動。デバイスモード中はクリックがタッチイベントとして扱われるので、スワイプ操作のゲーム（2048のような）が実機なしでもある程度確認できる。ただし過信は禁物で、慣性やマルチタッチの感覚は実機と違う。最終確認は自分のスマホでやる
- DPR（Device Pixel Ratio）を変えたときのCanvasのにじみ。CanvasはCSS上のサイズと描画バッファのサイズが別物なので、DPRを考慮せずに実装すると高解像度端末でぼやける。デバイスモードでDPRを切り替えると、この問題を実機を並べずに再現できる
レイアウト崩れの確認は言うまでもないとして、Canvasを扱うならDPRの切り替えができるだけでデバイスモードを開く価値がある。
Lighthouse: 定点観測用。ただし素の状態で回す
LighthouseはDevToolsに統合されているので、改善の前後で回してスコアの変化を見る定点観測に使っている。うちのブログが50点台から90点台に上がっていく過程は、全部これで追った。
ひとつだけ注意点があって、拡張機能が動いているプロファイルで回すとスコアが汚れる。広告ブロッカーやパスワードマネージャがページに注入するスクリプトも計測に含まれてしまうからだ。自分はシークレットウィンドウ（拡張機能が基本無効）で回すようにしてから、数字のブレが減った。
正直、使っていない機能
網羅記事へのアンチテーゼとして、有名だけど自分は使っていない機能も書いておく。
- Workspaces（DevToolsからローカルファイルを直接編集）: エディタとViteのHMRで完結するので出番がない
- Coverage（未使用コード検出): Astroの静的ビルドだとそもそもJSが少なく、削るものがない
- Snippets: 保存するほど定型のデバッグコードがない。Consoleの履歴で足りている
これらが不要な機能だとは思わない。単に自分の作業（静的サイト＋ブラウザ内で完結するツールとゲーム）には合わなかったというだけだ。逆に言えば、DevToolsは「自分の作業で繰り返し発生する調査」に対応するパネルを2〜3個深く使えれば十分で、15個覚える必要はまったくなかった。この記事の初版を書いた自分に教えてやりたい。