18 日目の記事です。

• DevToolsおれおれAdvent Calendar 2020やります。ひとりで。

たくさんコードを書いて書き足して消して書き直して消して書き換えてって繰り返してると「あれこれまだどこかで使ってるっけ？」みたいになることがあります。近年は VS Code が灰色で表示してくれたり ESLint で検出 できたりもできるけど、でも別ファイルからも使えるようなやつだとそういうのも厳しい感じです。

あと CSS の使われていないスタイルも。

DevTools にはそういうものを検出する機能があります。

先にまとめ

• Coverage パネルを使って未使用箇所や割合を計測
• まともにやるならツールを

未使用コードを検出

1. DevTools の右上 “…” → More tools → Coverage
2. 指示に従い reload ボタンを押す
   • 画面は再読み込みされる
3. 必要に応じてボタンを押すなどの操作

CSS

セレクターが利用されているかで見ているようで、プロパティなどがなくてもグリーンになりました。

JS

色は行単位で付くけど検出は関数単位くらいで見ているのかな？　if (false) みたいな絶対に通らない条件分岐でもグリーンになりました。

実行時も検出してくれる

計測開始すると自動的に画面を再読み込みしましたが、その後も計測というか観測は続行されています。例えばボタンを押したら動く系の処理は最初はレッドだけど、その処理を通すとグリーンに変化します。

ちなみに 1 行にまとめると通ってない処理でもグリーンのマークが付くけど、ちゃんと計測はされてて Coverage パネルの Unused bytes 数字の数字には反映されてました。

その他

source maps は使えない

ので、どでかいファイルが Sources パネルに出てくることになります。つらい。あと実際のソースコードのファイルとずれてるので該当箇所を探すという手間が増えます。まあ仕方ないかあ。

Lighthouse

Lighthouse を使ったパフォーマンス計測にも Unused bytes の数字が反映されます。

• ウェブページの読み込みが遅いときはLighthouseで改善案を見て速度改善する（ひとり DevTools Advent Calendar 2020 – 15日目） | Ginpen.com

Unused bytes の数字自体が点数に直接関係するわけではないようだけど（要は速度が出れば良いので）、速度が出ずファイル転送サイズを減らしたいときは Coverage を参考にコードを削除するとか、依存を減らすとかすると良いと思います。

ちなみに外部ライブラリーをいじるのはお勧めしません。保守に不都合なので。

CSS を自動で削る

DevTools に自動で削るような機能はないのでツールを使ってください。CSS は PurgeCSS というのがたぶん今一番有名？なのかな？

• PurgeCSS – Remove unused CSS

最近ぶいぶい言わせてる Tailwind CSS はその仕組みに PurgeCSS を組み込んでおり、ビルドすると利用しているものだけに絞ったものが出てくるそうです。べんり～。（ちなみに噂には聞いてますが、おれはまだ使ったことはないです。）

purge という設定でやるらしい。

• Optimizing for Production – Tailwind CSS

// tailwind.config.js
module.exports = {
  purge: [
    './src/**/*.html',
    './src/**/*.vue',
    './src/**/*.jsx',
  ],
  theme: {},
  variants: {},
  plugins: [],
}

JS を自動で削る

JS のコードを削るってのもあるのかな。あれば教えてください。webpack には tree shaking という名前で、そういう機能が組み込まれていると聞いたことがあります。

• Tree Shaking | webpack

画面から使われているかはまた別ですけども。

PurgeCSS は npm でモノレポ

全然関係ないんだけど、PurgeCSS のリポジトリーちらと見たら npm v7 で導入された新機能、workspaces を使ってモノレポしてた。ほおー。

• FullHuman/purgecss: Remove unused CSS

おしまい

実際レッドになっていても「本当に使われていないこと」を証明するのってちょっと難しいので考えものです。手順の多い操作の後とか、別ページだとか。関数名でコードベース検索とかでどうにかする感じかな。

ところで Coverage の記事を後回しにしてたらちょうど CodeGrid で PurgeCSS の回が来たのでその勢いに乗りました。ありがとうございます。（？）

参考

• PurgeCSS – Remove unused CSS
• Optimizing for Production – Tailwind CSS
• Tree Shaking | webpack
• CSSを軽く保つ、PurgeCSS | 前編 PurgeCSSの基本機能 | CodeGrid
• Tailwind CSSで始めるユーティリティファーストCSS | 第2回 開発環境の構築とPurgeCSSについて | CodeGrid
• FullHuman/purgecss: Remove unused CSS
• rfcs/0026-workspaces.md at latest · npm/rfcs

17 日目の記事です。

• DevToolsおれおれAdvent Calendar 2020やります。ひとりで。

ちょっとここおかしいな簡単だからさらりと修正しちゃおうよしほら終わったコミットだデプロイだ、ええとでも反映されないなおかしいな？

そんな経験あると思うんですが、キャッシュって厄介ですよね。DevTools を使ってどうにか強制的に最新版へ更新したりできます。

先にまとめ

• Network パネルの Disable cache を使おう
• それはそれとしてキャッシュ戦略うまくやろう

キャッシュを利用しているかの確認

Network パネルでリクエストを監視して、一覧の Size の項目に出てきます。

“(disk cache)” がブラウザーが保存していたキャッシュファイルを利用した場合です。ネットワークを利用しませんでした。また再読み込みのときに “(memory cache)” になる場合もあって、どうも画像がそうなるので画面表示用に使ってたメモリーを再利用してるのかな。

公式ガイドには言及ないけどたぶんそんな感じだと思う。

最新版へ更新する

強制再読み込み

DevTools を開いた状態でブラウザーの再読み込みボタンを右クリックすると “Force refresh” という項目があります。（DevTools 開いてないと出ません。）

ここからキャッシュの有効期限を無視して読み込むことができる、と思うんだけど Network パネル見てるとディスクキャッシュから読み込んでるものが含まれることがあって、よくわかりません。サードパーティーのスクリプトとかからの読み込みは対象外なのかな。

キャッシュを削除

伝統的な手法。Chrome なら設定 → Privacy and security → Clear browsing data で削除できます。

• Time range: All time
• Browsing history: チェック外す
• Cookies and other site data: チェック外す
• Cached images and files: チェック付ける

これで全てのキャッシュが消えます。他サイトも消えます。できれば他の手段にしたいですね。

サービスワーカーのキャッシュを削除

数年前くらいにウェブページをモバイルアプリみたいに動かす PWA とかそこら辺の技術が盛り上がってたんですが、昨今はぼちぼち落ち着いてきて普通に使われるようになってきました。

Service Worker というのを使うとウェブアプリの側でキャッシュを管理することができるようになります。（他の仕事もあるよ。）　サーバーのファイルを更新してクライアント側でキャッシュを削除しても、その中間で動くこの SW が掴んだままのキャッシュファイルを返してくることがあります。

SW が管理するキャッシュは DevTools の Application パネルで一覧したり削除したりできます。

1. 該当サイトを開く
2. Application パネルを開く
   1. DevTools 右上 “…” → More tools → Application
3. 左側サイドパネル → Cache → Cache Storage を開く
4. 該当するキャッシュ名（というか全部を順に）右クリック → Delete

これで SW が掴んだキャッシュは消えたので、再読み込みで最新版が読み込まれるはず。

サイトにまつわるものだけ全て削除（おすすめ）

キャッシュだけ削除すると変になることもあるのでサイト単位で全部削除したくなるかも。そんなときは Clear storage の方です。

1. 該当サイトを開く
2. Application パネルを開く
   1. DevTools 右上 “…” → More tools → Application
3. 左側サイドパネル → Application → Clear storage を開く
4. “Clear site data” ボタンを押す

Cookie は残した方がログアウト状態にならなくて良さそうだけど、でもまあせっかくなんですぱっと行きましょう。

CDN キャッシュ

これでも駄目ならもうサーバー側の問題かもしれません。DevTools も関係ないや。

ファイルを置いているサーバーとは別に利用者からのアクセスを受け付ける CDN サーバーがある場合、そこがまだ更新されていないことも考えられます。

CloudFlare の場合は以下の手順でキャッシュ削除できます。

1. CloudFlare ログイン → 対象ドメインを開く
2. Caching → Configuration → Purge Cache
3. Purge Everything ボタンを押す

これで CloudFlare が保持するキャッシュが削除されます。一部の URL だけで良い場合は “Custom Purge” から指定して削除してください。

ちなみに、キャッシュが削除されるとリソース初回アクセス時にファイルを元サイトから取りに行くためちょっと時間がかかります。また JS/CSS の自動 minify を設定している場合、削除直後は元のファイルがそのまま飛んでくるようなので minify かかるまでしばらく待つ必要があります。速度計測するならは気を付けてね。

サーバーにファイルはあるのか確認

そもそもサーバーに本当にデプロイされてるか、ログなどで確認しましょう。手作業でやってるなら git pull してないとか、あるいは手元の方で git push してないとか。

あと URL 間違えてないかとか。

匿名ウィンドウで開く

普段使いのウィンドウからクッキーやキャッシュを引き継がず、さらにウィンドウを閉じるとそれらを削除するモードがあります。開発時はよく使うよね。

ブラウザーごとに名前が違う。

• Chrome: incognito window
• Edge: InPrivate window
• Firefox: Private window
• Safari: Private window

ウィンドウを開いている間は引き継ぐので、匿名ウィンドウを一度全て閉じてから開きなおすとまたファイルを読み込むようになります。

キャッシュ無効化（おすすめ）

というかですね、Network パネル上部の “Disable cache” にチェックを入れておくと、DevTools を開いている間はキャッシュを無効化することができます。閉じると通常通りキャッシュを利用します。

開発中は基本的に常時オンにしといて良いと思う。逆にキャッシュ有効の時にだけ起こる不具合というのもあるので、試験する際はオフにしましょう。

その他

Application Cache

Application パネルの Cache Storage の隣にある Application Cache って何かなと思ったら Deprecated な仕様らしい。

• View Application Cache Data With Chrome DevTools  |  Google Developers

近々 API も削除されるそうで、そしたら DevTools からも消えるんだろな。

おしまい

キャッシュ強すぎ問題は昔からよくあるけど今もまだあるよね。

参考

• View Cache Data With Chrome DevTools  |  Google Developers
• View Application Cache Data With Chrome DevTools  |  Google Developers
• window.applicationCache – Web API | MDN

16 日目の記事です。

• DevToolsおれおれAdvent Calendar 2020やります。ひとりで。

コンソールでカタカタやることは多いんですが、そんなときに便利な機能が用意されています。普通の JavaScript の実行環境じゃなくてコンソールでだけ利用できるやつらです。

本稿で触れる分はだいたい Chrome/Edge、Firefox、Safari のいずれでも利用可能です。

copy() で良い感じにコピー

読んで字のごとくコピーです。

普通の JS でコピーするなら、今は navigator.clipboard.writeText() が主流でしょうか、あるいは document.execCommand('copy') が引き続き使いやすい感じなんでしょうか。

DevTools のコンソールでは、copy() が使えます。

copy('Hello World!');

オブジェクトや配列を良い感じにコピー

オブジェクトを渡すと、良い感じに整形されインデントの付いた JSON になってコピーされます。すごい。

obj = { hoge:11, fuga:[22], piyo:33 }
copy(obj)

{
  "hoge": 11,
  "fuga": [
    22
  ],
  "piyo": 33
}

要素

要素を与えると HTML になって返ってきます。<html> を与えるとページ全体のソースがごそっと取れますね、JS とかでいじってなければ。

copy(document.documentElement)

実装

debug(JSON.stringify) （後述）で潜ってみるとこんなコードが出てきました。要素を渡したときの e は 'node' 。なるほどなるほど。

function(e) {
  if ("node" === e)
    return this.outerHTML;
  if (e && void 0 === this)
    return e + "";
  try {
    return JSON.stringify(this, null, "  ")
  } catch (e) {
    return "" + this
  }
}

$0 とかで要素

こちらも便利です。Elements パネルの要素へアクセスできます。

$0

Elements パネルで選択している要素になります。Ctrl+Shift+C で Inspect 対象を指定した直後によく使ってます。

$1, $2, $3, $4

$0 の遷移を記録しています。

要素を選択すると $0 に入っていたものが $1 へ移り、同時に $1 のものは $2 へ、という塩梅です。

Safari で使えない？

古いドキュメントには掲載されていたんですが、今試したら使えないみたいです。$1 は $0 と同じ？　$2 以降はない？

$5

そんなものはない。

$_ で最後の戻り値

コンソールで何か実行するとその戻り値も出力されます。この $_ はその最後の戻り値を記録します。

実行するごとに更新されるので、$_ を利用した表現を 2 回続けて利用すると結果は異なることでしょう。$_ + 1 とか。

Bash の $? みたいな感じ

ですか？

$(selector) で要素検索

jQuery みたいなやつらです。Firefox

$() が document.querySelector() と同じく CSS のセレクターで要素を取得できます。

$$() というのもあって、こちらは document.querySelectorAll() とだいたい同じで複数の要素を取得します。なおqSA の戻り値が配列風の NodeList であるのに対しこの $$() は配列を返します。

（2020/12/16 追記）「$$() は qSA と等価」としていましたが誤りでした。公式ドキュメントに This command is equivalent to calling document.querySelectorAll(). とあったので誤認しました。にゃーん。（追記おわり）

なお jQuery などで window.$ が利用されている場合はそちらが優先されます。

検索元を指定

これも jQuery みたいですが、第 2 引数にノードオブジェクトを与えることで、検索開始する位置を document 以外に設定することもできます。

$0 を組み合わせて、現在 Elements パネルで選択している要素以下から検索、みたいにできます。

el = $('[title]', $0)

XPath

$x() という XPass で要素取得するものもあります。もう誰も XPath 使ってない気がするけど。

debug() でブレイクポイントを設置

これは Chrome/Edge のみ。先ほど copy() の実装っぽいコードを掲載しましたが、あれを取得するのに使いました。

debug(JSON.stringify)

このよう↑に書くと、JSON.stringify() を利用している箇所で実行停止して Sources パネルでデバッグできるようになります。自前のコードなら普通にブレイクポイント設置した方が良さそうだけど、呼び出し箇所の見当がつかないときに便利かも。

undebug() でブレイクポイントを解除

使い終わったら undebug() で解除できます。

解除しない場合は画面を再読み込みしても設置されたままになります。DevTools の再読み込み (Alt+R) でようやく消えます。

Firefox、Safari では使えない

Firefox では使えません。

Safari では別の意味になります。console.debug() というログ出力の別名かな？

queryObject() で存在する全てのオブジェクトを取得

これは強力。

コンストラクターを指定して queryObject(Foo) のようにすると、コンソールのコンテキスト（Console パネル内上部の左の方、Top とかの選択欄）上に存在する全ての Foo インスタンスをログ出力します。

queryObjects(HTMLElement)

プロトタイプチェインで参照されているコンストラクター、継承しているクラスも全部出てきます。queryObjects(Object) とかやるとやばいことになってやばいです。

ちなみにログ出力なので戻り値ではないです。出力まではわりと時間がかかることがあります。Twitter ウェブ版みたいに巨大なウェブアプリで HTMLElement の検索とかしてみるとわかりやすい。

Firefox では使えない

だめでした。Safari はいけるっぽい。

おしまい

他にも色々あるんですが、おもしろそうなのをいくつか挙げてみました。全部見たいなら公式ドキュメントをどうぞ。

参考

• Console Utilities API Reference  |  Chrome DevTools  |  Google Developers
• The Console
• Bash Reference Manual

更新履歴

• 2020/12/16
  • 初出
  • 「$$() は document.querySelectorAll() と等価」は誤りなので修正
  • Firefox、Safari の言及がなかったので追加

15 日目の記事です。

• DevToolsおれおれAdvent Calendar 2020やります。ひとりで。

ウェブクライアント側のパフォーマンスは主に読み込み時と実行時のふたつに分けることができます。今回はそのうち読み込み時のパフォーマンス改善について。

Lighthouse パネルのボタン一発で改善案が出てきます。その指示に従うと良いでしょう。

先にまとめ

• DevTools Lighthouse パネルを使う
  • ボタン押すだけ
  • 速度以外にもアクセシビリティとか SEO とか計測できるツール
  • 改善案を提示
• 改善前に計測して、改善後と比較する
• ファイルサイズを減らすのが基本方針

Lighthouse を使った計測

さて計測なんですが、Lighthouse が初手として一番簡単かつ最後まで効果的です。なんてったってボタンを押すだけ。

• DevTools 内にあり、ボタンを押すだけで手軽
• 結果が 100 点満点で数値化されわかりやすい
• 改善案の提示が具体的

ご覧のこのページで今すぐ試してみてください。幸か不幸か改善点が盛沢山なので見応えがあると思います。（もうしばらくは改善なしでこのままです……。）

こんな結果画面が表示されます。パフォーマンス（速度）以外もアクセシビリティとかの計測が出ますね。（計測開始時点の設定でオフにしていなければ。）

Metrics

測定結果。右側のスイッチを押すと説明文が表示されます。

First Contentful Paint

First Contentful Paint marks the time at which the first text or image is painted. Learn more.

Speed Index

Speed Index shows how quickly the contents of a page are visibly populated. Learn more.

Largest Contentful Paint

Largest Contentful Paint marks the time at which the largest text or image is painted. Learn More

Time to Interactive

Time to interactive is the amount of time it takes for the page to become fully interactive. Learn more.

Total Blocking Time

Sum of all time periods between FCP and Time to Interactive, when task length exceeded 50ms, expressed in milliseconds. Learn more.

Cumulative Layout Shift

Cumulative Layout Shift measures the movement of visible elements within the viewport. Learn more.

Opportunities

見込み、可能性。どんな問題があり、それを解決すると何秒くらい高速化されそうか表示してくれます。

例えば “Remove unused JavaScript” を開くと画面表示完了までの間に利用のなかった部分の大きい JS ファイルが並びます。他の画面で使ってるとかボタン押したら動くとかそこら辺も unused 扱いになるっぽいけど。Coverage パネルでも見られます。

基本的には上から順に見て行って、やりやすい順に対応していくと良いかと。

Diagnostics

診断。その他の改善案です。

Opportunities 同様、やれるところからやっていきましょう。

Passed audits

問題なかった項目です。おめでとう！

英語が読めないんですが！？！？！？

いったん HTML 出力（次節参照）してやると普通に文字を選択できるので、コピペして翻訳ツールに突っ込んでやりましょう。

計測結果を保存、読み込み

計測して改善案を出してもらったら次はそれに沿って改善していくわけですが、改善作業の前の計測結果は必ず保存しておきましょう。作業の前後でどう変化（改善）したかを計測するためです。

保存

（DevTools ではなく）Lighthouse の右上の “…” → “Save as HTML” あるいは同 JSON から保存できます。

読み込み

HTML は普通にブラウザーで開けます。画像も Data URL で埋め込まれています。

JSON の方は DevTools の Lighthouse パネルへドロップすると開くことができます。こちらも画像が含まれています。

その他の計測

Network を使った計測

このパネルを表示した状態で画面を再読み込みすると、最初から記録が取れます。

読み込みの進捗の図を見てファイルが大きすぎて遅いとか、サーバー側のこの API の応答が遅いとか判断します。

Performance を使った計測

計測して生データを得る的なやつ。Lighthouse の内部でもこの機能を使っている、はず。

実行時の方の計測でも使うけど、読み込み時の計測の方でも使えます。再読み込みっぽいボタン “Start profiling and reload page (Ctrl+Shift+E)” を押してください。

前述のように FCP や LCP も計測できます。

Coverage を使った計測

使ってないコードを検出できます。これも Lighthouse が内部で利用していると思う。

<script> を並べるような昔ながらのサイトだと捗るかなと思うんですが、JS と CSS のうち利用されなかったコードの割合が多い順に見せてくれます。

1. Coverage パネルを表示
   1. DevTools 右上の “…” → More tools → Coverage
2. パネルの中の再読み込みボタンを押す
3. 画面内を操作する

そのページ用のファイルで未使用のものがあれば、更新とかのタイミングでの削除し忘れかも。

共通モジュールなんかは間違って他のページでは利用している部分を削除しないようご注意ください。

そのうちソースマップ対応してバンドルしたファイルでも見えるようになるといいなあ。

その他

LCP ……？

ページを開いて最初に見える範囲のうち、一番領域の大きな要素が表示されるタイミングのことです。今は画像か文章のいずれかが選択されるようです。（動画はいずれとのこと。）

• Largest Contentful Paint (LCP)

What is LCP?

The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport.

ここでいうビューポート (viewport) は最初に見える範囲、画面最上部のうちスクロールなしで見える部分を指すと思います。違ったらごめん。

どの要素が LCP 計測対象か確認する

Performance で確認できます。

1. Performance パネルを開く
2. 計測して再読み込みボタン (Ctrl+Shift+E) を押し、計測
3. Timings の中の “LCP” を探す
4. LCP にカーソルを乗せると、ページ内で強調表示される

Lighthouse で計測した場合はスクリーンショット付近の “View Original Trace” ボタンから計測結果を Performance パネルで開きなおすことができます。

Lighthouse 単体で実行

Google Chrome DevTools の管理下ですがこの Lighthouse 自体は独立したオープンソースなプロジェクトです。

• GoogleChrome/lighthouse: Automated auditing, performance metrics, and best practices for the web.

CLI もあります。手元の Windows/WSL で試したときうまく動かなかったけど。使い方は --help とか見てください。

$ npx lighthouse https://example.com

lighthouse は「灯台」のこと

light の house と分けるとわかりやすい。

• lighthouseの意味・使い方・読み方 | Weblio英和辞書

RAIL の 4 分類

記事冒頭で読み込み時と実行時の 2 つに分けましたが、Google はパフォーマンスについて RAIL という 4 分類を提案しています。

• Measure performance with the RAIL model

以下の頭文字です。

• Response – 応答
• Animation – アニメーション
• Idle – 待機
• Load – 読み込み

おしまい

うちもこれ見てそのうち改善します……。その前にやることが多くて（言い訳）。

参考

• Largest Contentful Paint (LCP)
• Measure performance with the RAIL model
• Defining the Core Web Vitals metrics thresholds
• lighthouseの意味・使い方・読み方 | Weblio英和辞書
• PageSpeed InsightsとLighthouse。よく似てるツールの違いを比較表でチェック！ – アイデアマンズブログ
• GoogleによるWebサイトパフォーマンス測定ツール「Lighthouse」入門 | さくらのナレッジ
• Lighthouse  |  Tools for Web Developers  |  Google Developers
• Why is my Lighthouse score different from PageSpeed Insights?
• Shunya Shishido on Twitter: “Core Web Vitals は毎年アップデートされていく予定ですが、FCP の追加、FID の閾値変更、滞在時間が長いサイトでのCLSの改善が検討されています。Progressive Loading のサンプルとして、日経の事例を掲載させていただきました！ / Exploring the future of Core Web Vitals https://t.co/seKvkhbBZA https://t.co/tCmUHDKret” / Twitter

• DevToolsおれおれAdvent Calendar 2020やります。ひとりで。

DevTools は独立ウィンドウで表示することができます。外部モニターもあるのでそうやって別に出して使うことが多いんですが、複数のページを並行して開いていて「あれどのタブだっけ」みたいになることがあるかもしれません。いやないか？　あるでしょ、あるということにします。

そんなときは “Focus debuggee” を実行すると、DevTools で見ているページのタブにフォーカスが移ります。たとえ他のデスクトップ（左右にひゅんひゅん動くやつ）にあったとしても見つけてくれます。

DevTools が見ているページのタブを開く

独立ウィンドウの右上 “…” からすぐです。なお DevTools をブラウザーのウィンドウに格納している場合は出てきません。

ショートカット

Settings → Shortcuts の一覧には載ってるんですが、設定されたキーはないです。

自分でショートカットを設定すれば良いんですが、残念ながらまだショートカット設定の機能は一般開放されてません。Settings → Experiments から有効化すると使えるようになります。

変更するやつはこちら。

• DevToolsのショートカット一覧と変更方法（ひとり DevTools Advent Calendar 2020 – 13日目） | Ginpen.com

使えない場面も？

ショートカット設定したんですが、コンソールの入力欄にフォーカスがある状態だと、この Focus debuggee を利用できませんでした。不具合なのか制限なのかは判断付かない。

ブラウザー側から DevTools を探す

逆にページを開いている側から対応する DevTools のウィンドウを探す場合、通常の DevTools を開く操作、ショートカット (Ctrl+Shift+I) でフォーカスを移せます。

おしまい

昔は DevTools を同じブラウザーのウィンドウに格納した状態で使ってましたが、常時外部モニターを利用するようになった現在では別ウィンドウで利用しています。