※スマホ対応はしてません。

カテゴリー: Web

視覚特性に考慮してアクセシビリティを高めるためのツール(ひとり DevTools Advent Calendar 2020 – 19日目)

カテゴリー: Web

19 日目の記事です。

背伸びしてる感あって怖い気もするんですが、DevTools でやれることの話です。ARIA の話は出てきません、わかんないので……。

先にまとめ

  • Lighthouse で検出 (”Background and foreground colors do not have a sufficient contrast ratio”)
  • Elements パネル → Styles の色選択ポップアップで適切なものに
  • Rendering パネル → Emulate vision deficiencies で視覚特性エミュレート
  • Rendering パネル → Emulate CSS media feature prefers-reduced-motion でアニメーションを減らす OS 設定エミュレート

Lighthouse で問題のある箇所を探す

Lighthouse の Accessibility 節で確認するのが一番簡単です。

  1. DevTools → Lighthouse パネルを開く
  2. Accessibility にチェックを入れた状態で Generate report ボタンを押す
    • 他はあってもなくても
  3. Contrast 節以下の該当項目を確認
    • “Background and foreground colors do not have a sufficient contrast ratio”
    • = 背景と前景の色に十分な明度比がない
    • 見えない場合はたぶん Passed audits 節に含まれていて、問題なしということ

項目を開くとどの要素で問題かもわかります。クリックすると Elements パネルで開けるので、そのまま調整に入りましょう。

Lighthouse での確認結果。問題のある要素も一覧で示してくれる。

なお画像で文章を表現している場合は、まあ当たり前ではありますが、検出されません。作るときに気を付けないといけないですね。Lighthouse による検出で経験詰んで慣れてくれば画像編集の際にも意識が向いてきそう。

Elements パネルで色を調整

Elements パネルの Styles ペインで、四角い色のプレビューが出るのは見たことがあると思います。実はこれクリックできて、ポップアップで色編集ができます。

さらに color プロパティなど場合、そのポップアップに Contrast ratio という項目が表示され、件の「十分な明度比」の確認ができます。(border-color とかには出ません。)さらにさらに、問題がある場合は問題のない色の提案までしてくれます。べんり~。

Elements パネルで、色のプレビューから出せるポップアップ。パレットから色を選択できる他、色の表現方法 (HEX, RGB, HSL) を変えたり、適切な明度比の提案も。

Render パネルで視覚特性のエミュレート

Rendering パネルの一番下に Emulate vision deficiencies という項目があって、ここでぼやけるやつや P 型、D 型といった特性をエミュレートできます。

エミュレーションをしていない状態。黄土色と緑色の二色を利用している画面。

P 型のエミュレーションを利用した状態。色の差がなくなった。

ちなみにこのエミュレーション、SVG フィルターを使って実装しているらしい。

Render パネルでアニメーションを減らす状態のエミュレート

Twitter みたいにアプリ単位で機能を持っているものもありますが、主要な OS で全体的に設定できるようです。例えば iOS なら「設定 → 一般 → アクセシビリティ → 視覚効果を減らす」とのころ。

MDN のページにデモがあるのですぐ試せます。またどこから設定できるかも掲載されているので、そっちを試してみるのも良いかもしれません。

その他

CSS Overview で確認

Lighthouse で確認する他に、CSS Overview という機能からも確認できるようになりそうです。

現在はこの機能は未完成で、Experiments として提供されています。試したところ Lighthouse で検出されるものより数が減ってたり何も出てこなかったりしました。違う計算方法なのかな?

明度比専用の機能ではないんだけど、まあ興味あれば試してみてください。

おしまい

アクセシビリティ方面は詳しくなく経験も全然ないのでわかんないことが多いですが、Lighthouse が出してくれる情報に沿っていけばある程度(今回の明度比以外も)良い感じにやれるようです。完璧からはほど遠いんだろうけれど、初手としては良いんじゃないですか。知らんけど。

あと最近ます P さん達がウェブアクセシビリティの検証ツールを作っておられるそうなので、そういうのも試すと良いのかも。

ところで「視覚特性」という呼び方は大丈夫ですか?

参考

Coverageで使ってないコードを検出(ひとり DevTools Advent Calendar 2020 – 18日目)

カテゴリー: Web

18 日目の記事です。

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

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

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

先にまとめ

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

未使用コードを検出

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

Coverage パネルで調査したところ。右側の棒グラフがファイルサイズと、そのうち赤色の部分が未使用コードの量を表す。また Sources パネルでコードを表示すると、行ごとに赤色、緑色のマークを付けて表現してくれる。

CSS

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

画面で利用されているコードがグリーン、そうでないものがレッドで表示されている様子。空の宣言 :root {} はグリーンになっている。

JS

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

JS ファイルの様子。ほとんどグリーンになっているが、クリック時のイベントハンドラーはレッド。if (false) は、内包する関数自体が利用されているためかグリーンに。

実行時も検出してくれる

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

クリック時のイベントハンドラーの内容がグリーンになった様子。

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

その他

source maps は使えない

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

Lighthouse

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

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

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

CSS を自動で削る

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

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

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

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

JS を自動で削る

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

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

PurgeCSS は npm でモノレポ

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

おしまい

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

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

参考

ファイルが更新されないときのキャッシュの消し方いろいろ(ひとり DevTools Advent Calendar 2020 – 17日目)

カテゴリー: Web

17 日目の記事です。

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

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

先にまとめ

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

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

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

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

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

Network パネルに “(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 でキャッシュを削除する画面。

これで 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 な仕様らしい。

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

おしまい

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

参考

$0とかcopy()とか、コンソールでだけ使える表現(ひとり DevTools Advent Calendar 2020 – 16日目)

カテゴリー: JavaScript

16 日目の記事です。

コンソールでカタカタやることは多いんですが、そんなときに便利な機能が用意されています。普通の 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 対象を指定した直後によく使ってます。

Elements パネルでパスワード入力欄を選択し、コンソールでその入力値を得る様子。

$1, $2, $3, $4

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

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

Safari で使えない?

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

$5

そんなものはない。

関羽「そんなものはない」
ないものはない。

$_ で最後の戻り値

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

console.log() 実行後、ログ出力とは別に戻り値 undefined が出力される様子。

実行するごとに更新されるので、$_ を利用した表現を 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 はいけるっぽい。

おしまい

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

参考

更新履歴

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

カテゴリー: Web

15 日目の記事です。

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

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

先にまとめ

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

Lighthouse を使った計測

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

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

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

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

Lighthouse による計測結果画面。あまり良い数値は出ていない。

Metrics

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

First Contentful Paint

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

First Contentful Paint

First Contentful Paint は最初のテキストか画像が描画された時間を示します。詳しく。

Speed Index

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

Speed Index

Speed Index はページの内容がどれだけ速く視覚的に出力されたかを表します。詳しく。

Largest Contentful Paint

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

Largest Contentful Paint

First Contentful Paint は最大のテキストか画像が描画された時間を示します。詳しく

Time to Interactive

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

Time to Interactive

Time to Interactive はページが十分にインタラクティブになるのにかかる時間量です。詳しく。

Total Blocking Time

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

Total Blocking Time

FCP と Time to Interactive の間の時間の合計です。タスクの長さが 50ms を越える場合はミリ秒で表現されます。詳しく。

Cumulative Layout Shift

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

Cumulative Layout Shift

Cumulative Layout Shift はビューポート内にある可視要素の動きを計測します。詳しく。

Opportunities

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

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

Opportunities に表示されている Remove unused JavaScript を開いたところ。どのファイルがどれ程のファイルサイズを削れるか示されている。

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

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 のうち利用されなかったコードの割合が多い順に見せてくれます。

Coverage を利用して未使用コードを検出した例。Sources パネルで表示したコードの行頭に色が付き、使用と未使用が一目瞭然となる。

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

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

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

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

その他

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.

LCP とは

Largest Contentful Paint (LCP) メトリックは、ビューポート内に表示される一番大きな画像かテキストブロックの描画時間を示します。

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

ニュースサイトの読み込み進捗スクリーンショット。計測対象の箇所が枠で示され、それが進捗に伴い見出しの大きな文字から画像へ移ったことがわかる。Largest Contentful Paint (LCP) より。

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

Performance で確認できます。

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

Performance パネルで LCP のタグ?にカーソルを乗せる要素がハイライトされる様子。

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

Lighthouse 単体で実行

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

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

$ npx lighthouse https://example.com

lighthouse は「灯台」のこと

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

RAIL の 4 分類

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

以下の頭文字です。

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

おしまい

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

参考