Lighthouse満点は「取る」より「保つ」が難しい｜ダークモードのコントラストで96点に落ちた話

このブログはWordPressから静的サイト（Astro）へ移行したときに、Lighthouseの4カテゴリすべてで100点を取りました。そこで満足していたのですが、先日スマホでPageSpeed Insightsを回したら、ユーザー補助が96点に落ちていました。

原因はダークモードのコントラスト不足でした。今日はその特定と修正の記録です。満点は取るより保つほうが難しい、というのが正直な感想です。

96点の内訳は「コントラスト比不足」だけ

PageSpeed Insightsの指摘は1項目のみ、「背景色と前景色には十分なコントラスト比がありません」でした。展開すると3つの要素が挙がっていました。

• トップページの「記事を読む」ボタン
• カテゴリのチップ（IT・個人事業）
• カテゴリとタグを並べた帯

ローカルのLighthouseでは100点だった

ここが今回いちばんの落とし穴でした。

原因を調べようと、手元の環境で同じLighthouse（バージョンも同じ13.4.1）を走らせたところ、ユーザー補助は100点。コントラストの監査も合格と出ました。

同じツール、同じバージョン、同じページなのに結果が違う。こういうとき、どちらを信じるかで作業の方向が決まります。私は実際に色の数値を計算して確かめることにしました。ツールの結果が食い違うなら、計算という一次情報に当たるのがいちばん確実です。

結果はPageSpeed Insightsが正しく、私の手元の環境が見落としていました。おそらく color-mix() という比較的新しいCSS関数の解決に、監査環境ごとの差があったのだと思います。

計算してみたら、想定より根が深かった

このブログはダークモードが初期表示です。つまり評価されるのは常にダーク側の色。そこで、カテゴリ色を文字に使っている箇所をすべて洗い出して、コントラスト比を計算しました。

指摘は3件でしたが、実際には5種類の要素が基準を割っていました。特にカテゴリの印は2.18:1で、基準の半分以下。指摘されていない箇所まで調べてよかったと思っています。

一方でライトモードは全項目6.7〜8.8:1で合格でした。問題はダークだけだったのです。

直し方：色を作り直さず、混ぜる

修正方針で悩みました。カテゴリ色そのものを明るく変えると、合格しているライトモードのほうが崩れます。

そこで使ったのが CSSの color-mix() です。カテゴリ色と本文の文字色を混ぜて、ダークのときだけ明るい側へ寄せました。

/* ダークのときだけ、カテゴリ色を文字色寄りに混ぜる */
:root[data-theme='dark'] .cat-chips a {
  color: color-mix(in srgb, var(--cat-c) 55%, var(--c-text));
}

混合比は数値を計算しながら決めました。70%では4.09:1で足りず、60%で4.94:1、55%で5.42:1。余裕をみて55%を採用しています。

ボタンのほうは考え方を変えました。ダークではアクセント色（朱）が明るくなるので、文字を白から暗い色に反転させています。3.29:1が5.15:1になりました。

修正後の数値がこちらです。

いずれもダークのときだけ適用される上書きなので、ライトモードの見た目は一切変えていません。

結果：4カテゴリ満点に復帰

デプロイ後にPageSpeed Insightsを回し直したところ、パフォーマンス・ユーザー補助・おすすめの方法・SEOのすべてが100点に戻りました。ついでに新カテゴリの「エージェントによるブラウジング」も3/3になっています（こちらは llms.txt を推奨形式に直したためです）。

満点を「保つ」ために学んだこと

今回いちばん効いたのは、スマホで自分のブログを読者として読んでみることでした。同じ日に、図がスマホからはみ出している箇所や、補足ボックスの中のリンクがタップできず文字のまま表示されている箇所も見つかっています。どちらもLighthouseは減点しません。基準を満たしていても、読みにくい場所は残るのです。

満点は一度取ったら終わりではありません。記事を足し、色を調整し、新しい部品を作るたびに、静かに崩れていきます。作ったあとに、読者と同じ環境で読み直す。結局これがいちばん確実な品質管理でした。

このブログを静的サイトへ移行したときの全記録はWordPressをやめて静的サイトに移行した全記録にまとめています。あわせてどうぞ。