Core Web Vitalsの改善方法｜LCPを遅くしていたのは画像ではなくフォント読み込みだった

PageSpeed Insightsのレポートを開いたら、LCP(最大コンテンツの描画)が「要改善」の黄色になっていた。
真っ先に疑ったのはトップページのメインビジュアル画像だった。
容量を測ってみると、実はとっくにWebP化されていて、サイズも軽い部類に入っていた。
犯人は画像ではなかった。
レポートの詳細タブを開いて初めて、本当の原因が見えてきた。

Core Web Vitalsが見ているのはページの「体感速度」

Core Web Vitalsは、表示の速さ・反応の良さ・見た目の安定性という3つの指標でページ体験を数値化する仕組みで、Googleの検索順位にも影響する。
主要な指標はLCP(表示の速さ)・INP(反応の良さ)・CLS(見た目の安定性)の3つで、この中でLCPは「ユーザーが最初に大きなコンテンツを目にするまでの時間」を測る。
数字が悪いということは、サーバーが遅いか、途中で何かが読み込みを邪魔しているということになる。

指摘されたLCPの数値と、最初に立てた仮説

うちのトップページのLCP実測値は2.9秒で、Googleが目安とする2.5秒をわずかに超えていた。
LCP要素として特定されていたのは、ヘッダー直下の見出しテキストだった。
画像ではなくテキストが最大要素として選ばれていたので、最初は意外に感じた。
テキストなら表示は一瞬のはずだと思っていたからだ。

疑ったのは画像、実際の犯人はフォント読み込みだった

詳細を追っていくと、そのテキストにはGoogle Fontsで配信しているウェブフォントが指定されていた。
フォントファイルはページのCSSとは別のドメインから配信されるため、ブラウザはCSSを読み終えてからフォント用のドメインに接続し、フォントを取得し、それからやっとテキストを描画する。
このドメイン接続からファイル取得までの一連の待ち時間が、LCPの数値にそのまま積み上がっていた。
画像を何度圧縮し直しても数値が動かなかった理由が、ここでようやく分かった。

preconnectを1行足すだけでは終わらなかった

外部ドメインへの接続をあらかじめ済ませておくResource Hints(dns-prefetch・preconnect)を、フォント配信元のドメインに対して指定した。
うちのコーディング規約では外部CDNへのResource Hintsは元々必須にしていたはずだったが、このページのテンプレートだけ追加時期が古く、指定が漏れていた。
1行加えただけでLCPは2.9秒から2.2秒まで縮み、目安の2.5秒を下回った。
規約に書いてあることと、実際に全ページへ反映されていることは、別の話だと思い知った。

ついでに見直したWebP変換の設定

原因はフォントだったが、これをきっかけに画像側も点検し直した。
コンテナのWebP画像最適化機能は、アップロード時に自動でWebPへの変換とリサイズを行うが、機能を有効化する前にアップロード済みだった古い画像は変換対象から漏れていた。
対象外だった画像を一括で洗い出し、あらためて変換をかけたところ、フォントの修正ほどの伸びしろではなかったものの、ページ全体の転送量は目に見えて減った。

表示速度は一度直して終わりにしない

今回の一件で学んだのは、体感速度を落としている犯人は、見た目に重そうな要素とは限らないということだ。
テキストの表示ひとつをとっても、フォントの配信元、CSSの読み込み順、Resource Hintsの有無まで確認しないと、本当の原因にはたどり着けない。
うちでは主要ページのPageSpeed Insightsのスコアを月次で確認する習慣に変えた。
数値が動いたときに、何が原因かをすぐ言えるようにしておくためだ。

画像の最適化については、WebP画像最適化の機能ページで詳しく紹介している。