Chrome DevTools、これだけ知っておけば十分だった。

はじめに

お疲れ様です。だいせんせーです。

フロントエンドの開発をしていると、毎日のように開くChrome DevTools。でも「ElementsでCSSを確認して、Consoleでエラーを見る」くらいしか使っていない……という方も多いのではないでしょうか。

実はDevToolsには、知っておくと地味にデバッグ時間が変わる機能がたくさんあります。この記事では、私が「これ早く知りたかった」と思った機能を厳選して紹介します。全部覚えなくていいので、気になるものだけ試してみてください。

① Elementsパネル — CSSをその場で試す

スタイルをリアルタイムで編集する

Elementsパネルの右側に表示される「Stylesペイン」では、CSSをその場で直接編集してリアルタイムに反映を確認できます。コードを書き換えて保存して確認して……という往復がなくなるだけで、CSSの調整がかなり楽になります。

使い方はシンプルで、Stylesペインに表示されているプロパティの値をクリックすると直接編集できます。数値であればマウスホイールで増減させることもできるので、余白やフォントサイズの微調整に特に便利です。また、ペインの一番下の空欄をクリックすると、新しいスタイルを追加することもできます。

ここで試したスタイルはページをリロードすると消えるため、あくまで確認用です。いい感じの値が見つかったら、すぐにコードに反映するようにしましょう。

hoverやfocusの状態を固定して確認する

「hoverしたときのスタイルを確認したいのに、DevToolsにカーソルを移動すると解除されてしまう」という問題、一度は経験したことがあるのではないでしょうか。

Stylesペインの上部にある :hov ボタンをクリックすると擬似クラスの一覧が展開され、:hover や :focus などにチェックを入れると状態を固定して確認できます。カーソルをどこに移動しても状態が維持されます。

対応している擬似クラスは :hover :focus :active :visited :focus-within :focus-visible の6種類です。ボタンのhoverスタイルや、フォームのfocusリングを確認するときに重宝します。

② Networkタブ — 通信の中身を見る

リクエスト・レスポンスの中身を確認する

NetworkパネルではページのHTTPリクエストをすべて記録しています。各リクエストをクリックすると、送信したリクエストの内容やサーバーから返ってきたレスポンスの中身を確認できます。

「APIは叩いているはずなのに何も表示されない」というときに、実際にどんなデータが返ってきているかをここで確認するのが一番早いです。確認できる情報は主に以下の4つです。

• Headers — ステータスコード、リクエストヘッダー、レスポンスヘッダーを確認できる。認証トークンが正しく送れているか、Content-Typeは合っているかなどをチェックできる
• Payload — POSTリクエストで送信したデータの中身を確認できる。フォームの値やJSON形式のリクエストボディが見られる
• Response — サーバーから返ってきたレスポンスの中身を確認できる。APIが返すJSONの構造や、エラーメッセージの詳細を確認できる
• Timing — リクエストにかかった時間の内訳を確認できる。どのフェーズで時間がかかっているかを把握するのに役立つ

また、上部の検索バーでURLやメソッド名でフィルタリングできるので、リクエストが多い場合でも目的のものをすぐに絞り込めます。

Preserve logでページ遷移後もログを残す

通常、Networkパネルのログはページが遷移するとリセットされます。フォーム送信後のリダイレクトなど、遷移をまたいで通信の流れを追いたいときは Preserve log にチェックを入れておくと、遷移後もログが残り続けます。

「送信ボタンを押したらどこかにリクエストが飛んでいるはずなのに確認できない」というケースで、これを知っているかどうかで調査時間がかなり変わります。ログインフォームやお問い合わせフォームの動作確認をするときに特に便利です。

また、Preserve log と合わせて Disable cache にもチェックを入れておくと、キャッシュが効いて古いリソースが使われる問題も防げるので、開発中はセットで有効にしておくことをおすすめします。

低速回線をシミュレーションする

Networkパネルの上部にある「No throttling」のドロップダウンから、回線速度をシミュレーションできます。Slow 3G などを選ぶと、低速回線でのページの見え方や読み込みの遅さを手元で確認できます。

自分の環境では快適に見えても、回線が遅い環境ではローディングが長く表示されたり、画像の読み込みが遅れてレイアウトが崩れることがあります。特に以下のような点を確認しておくと安心です。

• ローディング中にレイアウトが崩れていないか
• 画像が遅れて表示されるときにガタつき（CLS）が起きていないか
• ローディングスピナーやスケルトンスクリーンが意図通り表示されているか

プリセットの回線速度以外にも「カスタム」から任意の速度を設定できるので、ターゲットユーザーの環境に合わせた確認もできます。

③ Consoleパネル — エラー確認だけじゃない

console.tableで配列・オブジェクトを見やすく出力する

デバッグでよく使う console.log() ですが、配列やオブジェクトをそのままlogすると、中身が折りたたまれていて展開するのが手間なことがあります。そんなときは console.table() を使うと、表形式で見やすく出力してくれます。

const users = [
  { name: '田中', age: 28, role: 'admin' },
  { name: '鈴木', age: 34, role: 'editor' },
  { name: '佐藤', age: 22, role: 'viewer' },
];
console.table(users);

上記のように出力すると、名前・年齢・ロールが表の列として並んで表示されます。配列の要素数が多いときでも一覧で比較しやすく、データの確認が格段に楽になります。第2引数に表示したいプロパティ名を配列で渡すと、表示する列を絞ることもできます。

console.table(users, ['name', 'role']); // nameとroleだけ表示

$0でElementsで選択した要素をConsoleから操作する

Elementsパネルで要素を選択した状態でConsoleパネルに移動し、$0 と入力すると、直前に選択した要素をそのまま参照できます。

$0.style.background = 'red'; // 選択した要素の背景を赤に変える
$0.textContent; // 選択した要素のテキストを取得する
$0.classList; // 選択した要素のクラス一覧を確認する

document.querySelector() でセレクタを書かなくても済むので、特定の要素をConsoleパネルからさっと操作したいときに重宝します。また、$1 $2 と数字を増やすと、1つ前・2つ前に選択した要素も参照できます。直近5つまで履歴として保持されています。

さらに、ConsoleパネルではjQueryライクな $() 記法も使えます。$(‘button’) と入力すると document.querySelector(‘button’) と同じ動作をするので、素早く要素を取得できます。

④ Sourcesパネル — console.logを減らす

ブレークポイントでデバッグする

• ※GoogleのTOPページです。

「この変数、このタイミングでどんな値が入ってるんだろう」というとき、console.log() を仕込んでは確認して消して……を繰り返していませんか。Sourcesパネルのブレークポイントを使うと、コードを止めて変数の中身をその場で確認できます。

やり方はシンプルです。SourcesパネルでJavaScriptファイルを開き、止めたい行番号をクリックするだけ。その行に差し掛かったときにコードが一時停止し、そのときのスコープ内の変数を左側のペインで確認できます。一時停止中は以下の操作で処理を進めることができます。

• Resume（F8） — 次のブレークポイントまで処理を再開する
• Step over（F10） — 現在の行を実行して次の行に進む。関数の中には入らない
• Step into（F11） — 関数の中に入って1行ずつ実行する
• Step out（Shift+F11） — 現在の関数を抜けて呼び出し元に戻る

慣れるまで少し取っつきにくいですが、一度使い始めると console.log() だらけのコードから解放されます。

条件付きブレークポイントで特定の状況だけ止める

ループ処理の中で特定の条件のときだけ止めたい、というときは「条件付きブレークポイント」が便利です。行番号を右クリックして「条件付きブレークポイントを追加」を選ぶと、条件式を入力できます。

i === 5 // iが5のときだけ止まる
user.name === '田中' // nameが田中のときだけ止まる
items.length > 100 // itemsの件数が100を超えたときだけ止まる

ループが何百回も回るような処理でも、必要な条件のときだけ止めて確認できるので、デバッグ効率が大幅に上がります。条件を間違えても後から編集できるので、気軽に試してみてください。

⑤ Lighthouseパネル — パフォーマンスを一発確認

レポートの見方と改善ポイントの読み方

LighthouseはページのパフォーマンスやSEO、アクセシビリティを自動で採点してくれるツールです。DevToolsの「Lighthouse」タブから「レポートを生成」ボタンをクリックするだけで、0〜100点のスコアと具体的な改善提案が表示されます。

スコアは以下の5つのカテゴリで評価されます。

• Performance — ページの読み込み速度や表示の安定性を評価する。LCP・CLS・FIDなどのCore Web Vitalsが含まれる
• Accessibility — スクリーンリーダーへの対応や色のコントラスト比など、アクセシビリティの観点で評価する
• Best Practices — HTTPSの使用やコンソールエラーの有無など、Web開発のベストプラクティスに沿っているかを評価する
• SEO — メタタグやモバイル対応など、検索エンジンに正しくインデックスされるかを評価する
• PWA — プログレッシブウェブアプリとしての要件を満たしているかを評価する

特に見ておきたいのが「Performance」のスコアです。スコアが低い場合は、その下に「改善の機会」として具体的な原因が一覧で表示されます。「画像のサイズが大きすぎる」「レンダリングをブロックするリソースがある」といった形で、何を直せばいいかが明確にわかります。

注意点として、Lighthouseのスコアは実行するたびに多少ばらつくことがあります。シークレットモードで実行すると拡張機能の影響を排除できるので、より安定した結果が得られます。リリース前やパフォーマンスが気になったときに一度回しておくと、見落としていた問題が見つかることがあります。

やってみてわかったこと

これらの機能を覚えて一番感じたのは、「原因を特定するまでの時間」が体感でかなり変わったということです。

以前はとにかく console.log() を仕込みまくって、確認しては消して……という作業を繰り返していました。でもブレークポイントやNetworkパネルを使い始めてから、「何が起きているか」を直接確認できるようになって、無駄な往復が減った気がします。

特に効果を感じたのはNetworkパネルです。「画面には何も表示されないけどAPIは叩いているはず」という状況で、レスポンスの中身をすぐ確認できるようになったことで、「フロントの問題かバックエンドの問題か」の切り分けが格段に速くなりました。

全部を一気に覚える必要はないので、まず1つ気になった機能を次のデバッグで試してみてください。使える場面が来たときに「あ、これが使えるやつだ」とわかるだけで、だいぶ変わります。

おわりに

今回紹介した機能はあくまで一部です。DevToolsはアップデートのたびに新しい機能が追加されていて、最近ではAIアシスタントがConsoleパネルのエラーを解説してくれる機能まで登場しています。

まずは今日紹介した機能を1つ試してみて、「DevToolsってこんなこともできるんだ」という発見を楽しんでもらえると嬉しいです。
次回以降の投稿でさらに深堀っていきます！