ブログの記事をリライトして、Search Consoleを見ていた時のこと。
何気なく「ウェブに関する主な指標」を開いたら、見慣れない警告が出ていた。
「LCPの問題：2.5秒超（モバイル）」
対象URL、23。
23？
ほぼサイト全体じゃねぇか。
今まで記事の順位だとか、インデックスされているかだとか、そういうところばかり気にしていた。
今度は表示速度らしい。
ブログって記事書くだけじゃダメなんですか。
ということで今回は、Search Consoleに突然現れた「LCP 2.5秒超」を、WordPress素人なりに一個ずつ調べていった記録を残しておく。
ちなみにこのブログは、
- WordPress
- AFFINGER7
- エックスサーバー
- LiteSpeed Cache
- Site Kit by Google
という環境。
結果から言うと、使っていない機能を消したり、スマホ用画像を用意したりするだけでも数値はかなり変わった。
ちなみに私はブログを始めた時からずっと迷子になっている。
最初期の悩みも書いているのでよければぜひ読んでみてほしい。
そもそもLCPって何なのか
まずここから分からなかった。
LCPは「Largest Contentful Paint」の略。
ざっくり言えば、ページを開いた時、画面内の一番大きな主要コンテンツが表示されるまでの時間らしい。
GoogleではLCPについて、
2.5秒以下なら「良好」
4秒を超えると「低速」という基準を使っている。
評価には実ユーザーの75パーセンタイル値が使われる。
私のSearch Consoleでは、LCP 3.7秒。
「改善が必要」になっていた。
しかも23URL。
ただし、ここで重要だったのが、23記事を一個ずつ直す必要があるとは限らないこと。
Search ConsoleのCore Web Vitalsは、似た構造のページをURLグループとしてまとめて評価する。
私の場合も記事ページがまとめて同じ問題になっていた。
ということは、記事本文というより、テーマや共通設定が怪しい。
ここから調査開始。
Search Consoleだけ見ても、何が遅いのか分からない
Search Consoleでは、「LCPが遅いですよ」までは教えてくれる。
でも、「じゃあ何を直せばいいの？」までは分からない。
そこでGoogleのPageSpeed Insightsを使った。
問題が出ていた記事の一つを入れて、モバイルで計測。
最初の結果がこちら。
| 指標 | 最初の計測 |
|---|---|
| パフォーマンス | 53 |
| FCP | 8.9秒 |
| LCP | 22.7秒 |
| TBT | 170ms |
| CLS | 0 |
LCP、22.7秒。
終わってる。
ただし、この22.7秒はPageSpeed Insightsのラボ環境で行った一回のテスト。
Search Consoleの3.7秒は実際のChromeユーザーのデータをもとにしているので、
「読者全員が22秒待たされている」という意味ではない。
Google自身も、LCPは実環境とラボ環境で差が出ることを説明している。
とはいえ、22秒はさすがに何かおかしい。
詳しく見ていった。
最初のLCPは「記事タイトル」だった
PageSpeed InsightsでLCPの内訳を確認すると、
一番大きな要素として認識されていたのは画像ではなく、
記事タイトルのH1。
文字だった。
画像なら、「画像重すぎたかな」で分かる。
でもタイトル。
しかもサーバーから最初のデータが返ってくる時間自体はかなり短い。
なのに、タイトルが実際に画面へ描画されるまで、約6.46秒。
記事タイトルなんてHTMLを受け取ったらすぐ出てきてよ。
なんで6秒待ってるんだ。
ネットワークの依存関係を見てみた。
そこで見つかったのが、
webfonts.xserver.jp
という通信。
6秒以上かかっている。
犯人その1：使っていなかったTypeSquare Webフォント
WordPressのプラグイン一覧を確認すると、「TypeSquare Webfonts for エックスサーバー」というプラグインが有効になっていた。
エックスサーバーが提供しているWebフォント機能で、モリサワのTypeSquareをWordPressで利用するためのもの。
エックスサーバー公式でも、TypeSquareを使う場合にこのプラグインを有効化する手順が案内されている。
問題は、私は使っている記憶がない。
エックスサーバーの管理画面も確認した。
Webフォント設定、0件。
なんでプラグインだけ働いてるんだ。
ということで無効化。
再びPageSpeed Insightsを見ると、
記事タイトルのレンダリング遅延が、
約6.46秒 → 約2.32秒
まで減った。
さらに依存関係からwebfonts.xserver.jpも消えた。
これはかなり分かりやすい変化だった。
ちなみにエックスサーバー公式も、Webフォントの利用を解除する場合はTypeSquareプラグインの無効化とサーバー側のWebフォント設定解除を案内している。
今回はサーバー側に設定自体がなかったので、プラグインだけ無効化した。
犯人その2：誰も使っていない「Googleでログイン」
次に依存関係を見ていると、
accounts.google.com/gsi/client
accounts.google.com/gsi/style
みたいな通信が出てきた。
Googleログイン？
このブログ、会員制でもなんでもない。
読者にログインしてもらう機能なんて使っていない。
調べると、Site Kit by Googleの「Googleでログイン」が接続済みになっていた。
Site Kitには、WordPressへのログインやユーザー登録にGoogleアカウントを使える「Sign in with Google」機能があり、有効にすると必要なコードもSite Kit側でサイトへ追加される。
しかし私の設定を見ると、
One TapログインはOFF。ユーザー登録もOFF。
何に使っているんだ。
ということで、Search ConsoleやAnalytics、AdSenseの連携は残したまま、
「Googleでログイン」だけ切断した。
その後のPageSpeed Insightsでは、
FCPが、
10.7秒 → 2.2秒
まで改善した。
LCPも、
22.6秒 → 17.4秒。
もちろんPageSpeed Insightsのラボ計測は毎回ブレるので、「Googleログインを消したら必ず8.5秒縮まる」という意味ではない。
ただ、使っていない機能の通信をわざわざ残しておく必要もない。
この辺で、高速化って何かを追加するより、いらないものを消す方が大事なんじゃないか
と思い始めた。
ちなみにアドセンスも昔は本当にわからなかった。
今は何となく理解しているつもり。
こちらも別記事があるのでぜひ読んでみて欲しい。
次にLCPになったのはヘッダー画像
Webフォントなどを外した結果、今度はLCPとして別の要素が出てきた。
サイト上部のヘッダー画像。
このブログではPC用に、2200×500pxのヘッダー画像を使っている。
AFFINGERの設定を確認すると、スマホ専用のヘッダー画像を設定していなかった。
つまりスマホでも、2200×500pxの画像をそのまま読み込んでいた。
そりゃデカい。
ということで、2200×500pxを、1100×250pxへ縮小することにした。
Macの「プレビュー」で、「ツール → サイズを調整」を開く。
幅に1100。
高さに250。
縦横比を固定したまま、2200×500px → 1100×250px。
無事完成。
これをAFFINGERの、「スマホヘッダー画像」に設定した。
PNGからJPEGにも変更した
元の画像はPNGだった。
Macのプレビューでは私の環境だとWebP書き出しが出てこなかったので、今回は無理にWebPへ変換せず、
JPEGで書き出した。
品質もそこまで落とさず、スマホ用ヘッダーとして設定。
するとPageSpeed Insights上のLCPは、17.4秒 → 10.0秒 → 8.0秒まで下がった。
これも測定ごとに条件が変わるので、完全な同条件比較ではない。
それでも、スマホに2200pxのPNGを読ませる必要はなかったという点は変わらない。
PCにはPC用。
スマホにはスマホ用。
今思えば当たり前だけど、設定していなければ当然PC用が使われる。
最後に残ったのが「fetchpriority="high"」
ここまでやると、PageSpeed InsightsのLCP画像に対する指摘はかなり減った。
遅延読み込みされていない。
HTMLからすぐ画像を発見できる。
ここまではOK。
残ったのが、
fetchpriority="high"が付いていない
という指摘。
これはブラウザに、「この画像は重要だから優先して取りに行って」と伝えるための属性らしい。
WordPressでは6.3から、LCP画像になりそうな画像へfetchpriority="high"を自動付与する仕組みが導入されている。
WordPress公式によると、LCP改善で平均5〜10％程度の効果が期待できるとしている。
ただ、私のAFFINGERのスマホヘッダーには付いていなかった。
ここから先はテーマ側の出力や子テーマのコードを触る可能性がある。
……。
もういいか。
となった。
PageSpeed Insightsで100点を取るゲームを始めない
ここ結構大事だと思う。
PageSpeed Insightsを見ると、
赤。
黄色。
「改善できます」。
「このリソースを削減できます」。
こんな文言が大量に出てくる。
全部直したくなるんだけど、触ってテーマが崩れたりプラグインに影響が出ては困る。
本末転倒すぎるし、もう嫌。
もうCSSとか触りたくないし怖い。
今回も最終的なラボ計測ではLCP 8秒だったので、数字だけ見ればまだ良くない。
一方でSearch Consoleの実ユーザーデータでは、元々3.7秒。
GoogleのCore Web Vitalsレポートは実際の利用データを使用する。
だから私は、安全に分かるところまで直したら、いったん待つことにした。
本当に怖い。
今回実際にやったこと
最終的に触ったのはそんなに多くない。
| 改善したところ | やったこと |
|---|---|
| Xserver Webフォント | TypeSquareプラグインを無効化 |
| Site Kit | 不要な「Googleでログイン」を切断 |
| スマホヘッダー | PC用2200×500pxからスマホ用1100×250pxを作成 |
| 画像形式 | PNGからJPEGへ変更 |
| LiteSpeed VPI | 変更せず |
| テーマPHP | 変更せず |
fetchpriority | 今回は触らず |
これくらい。
プラグインを何個も追加したわけでもない。
CSSを全部最小化したわけでもない。
PHPも触っていない。
むしろ、いらないものを消して、デカすぎる画像を小さくしただけ。
最後にSearch Consoleの「修正を検証」を押した
一通り終わったので、Search Consoleへ戻って「修正を検証」を押した。
Googleの現在の案内では、Core Web Vitalsの問題を修正したあと「トラッキングを開始」すると、28日間のモニタリングが開始される。
期間中に対象URLで問題が発生しなければ解決と判定されるらしい。
なので、ここから先は待つ。
今日設定を変えたからといって、明日いきなりSearch ConsoleのLCPが、3.7秒 → 2.1秒！
みたいになるものではないみたいなんだけどね。
表示速度改善で一番分かったこと
ブログを始めた頃は、記事を書けばいいと思っていた。
その後、
SEO。
Search Console。
GA4。
AdSense。
AFFINGER。
画像形式。
今度はCore Web Vitals。
知らんことが無限に出てくる。
ただ、今回やってみて少し分かった。
PageSpeed Insightsで50点が出ても、
いきなり高速化プラグインを追加する必要はなかった。
一番遅いところを見る。
使っていないWebフォントを消す。
誰も使わないログイン機能を消す。
スマホにはスマホサイズの画像を使う。
そしてまた測る。
一個ずつやれば、「何をしたら何が変わったのか」も分かる。
これが結構重要だった。
そして最後には、fetchpriority="high"という知らない単語まで辿り着いた。
正直ここはいまだに訳わかんないから放置しておく。
わかんないことはブログに書けないので。
ブログを始めた頃は、アクセスがないことに困っていた。
その後はAdSenseに落ち、Search Consoleに振り回され、今度はLCPである。
悩みのレベルだけは少しずつ上がっている。
とりあえずGoogleには、「修正しました」と送った。
Googleさんよろしくお願いします。
