ページスピードインサイト（Page Speed Insights）は活用していますか？

2018年Googleはモバイル検索においてページの表示速度をランキングの要素として取り入れる、通称「スピードアップデート」を実装しました。
さらに、2021年5月以降スピードアップデートをさらに進めて、単に表示速度だけでなくページ読み込み中のユーザー体験を示す指標であるコアウェブバイタルをランキング要因に取り入れることを発表しています。

参考：Googleランキング要因になるCore Web Vitalsとは？概要から改善方法まで徹底解説！
https://www.sakurasaku-marketing.co.jp/labo/blogs/core-web-vitals

このようなことから、弊社クライアント様をはじめ、周囲では表示速度やコアウェブバイタルに関する関心は非常に高まっていると感じています。

この記事ではページスピードインサイトを活用してコアウェブバイタルを改善する方法を紹介します。
コアウェブバイタルについてあまりご存知でない方は、まず上記の記事を読むことをおすすめします。

参考＞UI/UXコンサルティングサービス（費用・事例紹介・無料相談・お見積り）の詳細はこちら
https://www.sakurasaku-marketing.co.jp/labo/services/uiux-consulting

改善するにあたっての考え方

いきなり改善を行う前に、ウェブサイトの状況を把握し、改善を行うべきかどうかをチェックしましょう。

改善が必要かどうかを判断する

運営サイトのコアウェブバイタルの状況はまず、サーチコンソールで確認しましょう。

改善が必要であるかを判断し、必要なのであればどのようなページのどのような指標改善から着手するかの目星をつけるためです。
詳細をクリックすれば各指標についてどのようなページが不良や要改善なのかがわかるようになっています。

以下をふまえて考えるとよいかと思います。

• コアウェブバイタルはまだランキング要因ではない
• 表示速度は現在もランキング要因であるが、ランキングへの影響は微々たるもの
• コアウェブバイタルの改善はUXに大きく影響することがわかっている

Google社員の金谷氏によると、「高速化されているサイトがさらなる高みを目指すというよりは、遅いサイトにこそ気づいて対策してほしい」といった発言がされています。
https://www.youtube.com/watch?v=NCz5cJPKzFk&t=3513s

なお、現時点では非常に遅いサイトを除き、コアウェブバイタルを改善しても検索順位が上がることはありません。
SEOに注力していて、より多くのセッションや高い検索順位を獲得しようとしているのであれば、コアウェブバイタルの改善より優先度の高い施策があるのではないでしょうか。
一方、ユーザーにより快適にウェブサイトを利用してもらうためなのであれば、ページスピードインサイトが指摘してくれる項目を改善することはよい選択でしょう。

スコアにこだわりすぎないことが大切

ページスピードインサイトでは、100点満点のスコアがまず表示されます。
特にモバイルではたいていの場合50点に到達するのも難しいのではないでしょうか？

ページにログインやアクセス解析などの機能を持たせるためにJavaScriptを使用しているとスコアは簡単に低下していまいます。
しかし、そのような場合であってもコアウェブバイタルの基準をクリアしているケースも少なくありません。
スコアが悪い（ように見える）からといって改善しなければならないというわけではないのです。

※モバイルで31点しか取れていないのにコアウェブバイタルを全て満たしている事例

ここから改善に着手してさらなるスコアアップを目指す場合、機能やUXを犠牲にする必要が出てくるかもしれません。
速度低下によって明らかにユーザー行動が悪化しているのでなければ、そのような選択はあまり好ましくありません。
「スコアが悪いから改善する」といった動機は見直した方が良いでしょう。

とはいえ、スコアが悪ければ改善したくなり、その際何かしら目安があった方が取り組みやすいのも事実です。
ページスピードインサイトを使ってコアウェブバイタル改善に向き合うのであれば以下のように考えてみてはどうでしょうか。

• すでにランキング要因である表示速度に影響するLCPを優先して改善する
• 比較的改善しやすいCLSを優先して改善する
• コアウェブバイタル３指標の不良（poor）をなくす
• スコアにこだわる場合はまずはモバイル40点を目指す
• PVが多い、CVに近いなど重要なページから改善する

AMP対応できるか検討する

唐突かもしれませんが、コアウェブバイタルの改善に取り組む場合、AMPは非常に相性がいいフォーマットです。

コアウェブバイタルの改善のためだけにAMPを導入するのは現実的ではないかもしれませんが、改善は一筋縄ではいかないこともあるため、AMPを導入してしまったほうが手っ取り早く推奨値を満たすことができる場合も少なくありません。

AMPは高速表示はもちろんのこと、コアウェブバイタルの面からも高いユーザーエクスペリエンスの実現を可能にするHTMLフォーマットです。
AMPでは以下のような観点からコアウェブバイタルの悪化が抑制されています。

• Google検索ではAMPキャッシュが使われるため、サーバー応答時間に左右されない
• AMPキャッシュではプリロードによりダウンロードやレンダリングの高速化が可能
• ページを開いた時に読み込むリソース（画像や広告）がファーストビュー内やすぐにスクロールされる範囲に限定されている
• 非同期JavaScriptのみが許容されているため、ユーザーのクリックを妨げない
• 遅延レイアウトにより、すぐに表示されないコンテンツのために応答がブロックされない
• 画像などテキスト以外のコンテンツはあらかじめ幅と高さを指定されていて読み込み中にずれが発生しない
• ユーザーアクションなしにレイアウト変更が起きない
• 外部フォントの読み込みは禁止されている（インライン限定）のため、ぐらつきやずれが抑制される

ただし、AMPでない従来のページを残す場合、非検索ユーザーやPCユーザーは引き続きそちらを閲覧しますので、従来ページを改善する必要性が全くないわけではありません。
とはいえ、検索からのユーザーが多い場合は特に、AMP導入は非常に有効です。

AMP導入をせずに従来のページを改善していく場合はページスピードインサイトをもとに改善を行います。

ページスピードインサイトの見方

ページスピードインサイトにURLを入力すると以下のように結果が出力されます。

ページスピードインサイトの仕組み、見方やフィールドデータ・ラボデータの意味について押さえておきましょう。

フィールドデータ

フィールドデータとは、実際のユーザーから取得したデータのことで、ページスピードインサイトではChrome Experience reportをもとにしています。

参考：Chrome User Experience Report – Google Developers
https://developers.google.com/web/tools/chrome-user-experience-report

Googleはこのフィールドデータをもとに、ランキング要因となっている表示速度を判定しています。
そしておそらく将来的にコアウェブバイタルについても同様にこのデータが使用されるものと思われます。

フィールドデータのサンプルは実際のユーザーです。
ユーザーはさまざまな回線やデバイス環境にてウェブサイトにアクセスしています。
ユーザーの中にはwifiや有線LANでアクセスしているユーザーもいれば、遅い3G回線でアクセスしているユーザーもいるでしょう。
また、高性能なデバイスを使っているかもしれませんし、安くてスペックの低いスマホを使っているかもしれません。

ページスピードインサイトではこのように様々な環境のユーザーのデータを集計し、28日間の累計データがフィールドデータとして表示されています。

そのため、改善を行ったとしてもここのフィールドデータはすぐには反映されません。
一方、サーチコンソールでは日次での表示が可能ですので、フィールドデータの変化を見たい場合はこちらを参照しましょう。
（ただしサーチコンソールは太平洋時間で取得されていますので多少の時差があります）

ラボデータ

ラボデータとはフィールドデータとは逆に特定の環境（自分のPCなど）で測定したデータのことです。
ページスピードインサイトでは、LightHouseという計測ツールが使われています。

特定の環境での計測結果ですので、改善を行えばすぐさま反映される一方で、フィールド環境の状況は必ずしも反映していません。
修正さえすれば、必ずフィールドデータも改善されるというわけではないということに留意しておきましょう。

また、1回のみの計測結果ですので、サーバーの状況などに応じて多少スコアが変わることがあります。

表示速度スコアと配点

ページスピードインサイトに表示されるスコアは、LightHouseがその都度採点しています。

配点は以下のようになっているとのことです。

参考:Lighthouse Scoring Calculator

• FCP（最初のコンテンツ描画）：15%
• SI（速度インデックス）：15%
• LCP（最大コンテンツの描画）：25%
• TTI（インタラクティブになるまでの時間）：15%
• TBT（ブロック時間）：25%
• CLS（レイアウトのずれ）：5%

上４つの指標が表示速度に関するもので、配点の実に70%を占めます。
しかも、前述のラボデータの部分を見るとこの速度に関する各指標が赤く表示されているサイトが多いのではないでしょうか？
そのため、ほとんどのサイトではLCPなど表示速度を改善することで、ページスピードインサイトのスコアが改善されると考えられます。

速度に直接関連しない指標では、TBTはコアウェブバイタルであるFIDに関連した指標で、配点は25%です。
CLSもコアウェブバイタル3指標の１つですがその配点はわずか5%となっており、スコアだけを見るならばレイアウトのずれを改善してもページスピードインサイトのスコアはほとんど変わらないでしょう。

ページスピードインサイトの以下の部分をクリックすれば、測定したページで各指標がどれだけの点数がついているかを確認することが可能です。

スコアにこだわるのであれば特に失点の大きな指標に注目するとよいでしょうが、モバイルの場合高得点を取るのはかなり難しいです。
加えて、前述のとおりスコアが悪いように見えたからといってコアウェブバイタルが悪いとも限りませんし、このスコア自体はラボデータでありGoogleのランキング要因ではありませんので、最終スコア自体にはあまりこだわる必要はないと考えています。

ページスピードインサイトをもとに改善を行っていくのであれば、これら6指標の値が改善によってどう変わったかを記録しておくとよいのではないでしょうか。
なお、ラボデータの特性上、何度か測定していると多少スコアが変動することがあります。

ページスピードインサイトをもとにした改善方法

ページスピードインサイトではLightHouseのデータをもとにして警告や指標改善のためのアドバイスが表示されます。

改善していくコアウェブバイタル指標が決まっているのであれば、各指標に対応するメッセージが出ていないかを確認しながら修正していくとよいでしょう。

以下に各指標に対応するメッセージを、各メッセージごとに解説して改善方法についてご紹介します。

LCP（最大コンテンツの描画）の改善方法

LCPはファーストビュー内で最も大きなコンテンツが表示されるまでの速度を指すものです。
コアウェブバイタルの3指標のうち、いわゆる「表示速度」を表す指標です。

「最大コンテンツの描画」要素

ファーストビュー内の最大コンテンツは読み込みに応じて変化することがあります。

※参考：読み込みの進捗に応じて変化する最大コンテンツ

上図では緑で囲まれた部分がそれまでの最大コンテンツを示しています。
途中までは記事のタイトル部分が最大コンテンツでしたが、最終的には最後に表示された画像が最大コンテンツとなっています。

ページスピードインサイトに表示されるこの項目ではどの要素が最大コンテンツとして認識されたかを教えてくれます。（「診断」内に表示されます。）

ページ内でどのコンテンツの表示がLCPを左右しているのかを押さえてよくとよいでしょう。
もしかするとLCP改善のヒントになるかもしれません。
たとえばそれが画像なのであれば、画像の最適化によってLCPを改善できる可能性があります。

ページスピードは大きく、データの生成、データの転送、描画の3つから成り立つ

ページの要素が表示される前のプロセスについても押さえておきましょう。

LCPに限らず表示速度を考える際には以下の３フェーズに分けて考えることができます。

1. データの生成
2. データの転送
3. 受け取ったデータの描画

各要素はそれぞれ、サーバーでHTMLを生成するフェーズ、ネットワークを通じて各ファイルを転送するフェーズ、ブラウザが受け取ったファイルを使ってページをレンダリングするフェーズに対応します。LCPのスコアはこの3つのフェーズの総合得点で決まります。

まずはデータ生成フェーズに関するメッセージです。

最初のサーバー応答時間を速くしてください

ページを表示させるためにはまずサーバーにアクセスしてHTML情報を受け取る必要があります。HTMLを作成する（データを生成する）時間であるサーバー応答は表示速度の根幹を成すものです。ここで警告が出ている遅いサーバーでは早いページスピードは実現できませんので、LCPの改善やスコアアップを目指すのであればサーバー応答の警告解消は避けて通ることはできません。

サーバーの応答速度は、Googleは0.2秒以内、LightHouseでは0.6秒以内が推奨されています。

コアウェブバイタルにおいてLCPが良好と判定される閾値は2.5秒ですが、LightHouseによるスコアリングではLCPなど速度関連の4指標は1秒以上になると減点され始めてしまうかなりシビアなものです。（そのため特にモバイルでは高得点が難しい）
サーバー応答で時間がかかってしまっているページがスコアを獲得しようとすると、後のフェーズである転送やレンダリングにほとんど時間がかけられなくなってしまいます。
ですので、サーバー応答時間はできるだけ早めておきたいところです。

なお、サーバー応答速度はTTFBという指標で表すことができます。
TTFBはTime To First Byte の略で、最初の1バイトが到着するまでの時間＝最初のデータが到着するまでの時間になります。厳密にサーバ側の処理時間のみではありませんが、近いデータということで参考にします。

サーバー応答速度は重要ですが、改善が難しいということも現実です。
その理由は、サーバ側の処理は外から見えず、ページスピードインサイトだけでは原因がわからないこと、また原因がわかったとしてもチューニングすることは難しいことがあります。
応答時間が長い場合、以下を元にエンジニアに確認してもらうべきでしょう。

・検索結果ページなどデータベースをたくさん使用するページが遅い傾向がある
⇒DBのチューニング、SQLのチューニング、データベースサーバのスペックアップなど

・WordPressなどでプラグインが多い、処理が遅いテーマやプラグインを使用している
⇒テーマ・プラグインの代替や不要プラグインの削除を検討

・サーバが古い、安いサーバ、アクセス数に対してスペックが足りていないなど
⇒ウェブサーバのチューニング、ウェブサーバのスペックアップ

なおTTFBはページスピードインサイト以外に、Chrome Developer Toolsなどを使用して個別のファイル単位で見ることも可能です。こちらの場合、個別ファイルごとに見ることができ、画像ファイルばかりTTFBが高いなどの個別の事象も捉えることができますのでおすすめです。

※Chrome Developer Tools を使用してTTFBを調査

検証：TTFBがスコアに与える影響

TTFBがどの程度影響を与えるか調査した結果を以下に公開します。(※この検証は2019年のものです)
スコアが100、速度インデックスが0.9のページに対して、意図的にTTFBを5秒遅延させたページのスコアを計測してみました。

実験の結果、TTFBの遅延によりスコアと速度インデックスを悪化させる形になり、TTFBの悪化がスコアに大きく影響することがわかりました。

複数のページ リダイレクトの回避

リダイレクトは別ページへの転送を意味します。つまり、HTMLデータを生成すべき最終的なURLを決めるまでに時間がかかるため、データ生成が始まるまでの時間を遅らせてしまいます。
そのため、リダイレクトは極力減らすことが望まれます。

ページスピードインサイトで調査する際は最終的なURLを入力するでしょうから、この警告が出ることは少ないかもしれませんが、ユーザーのサイト閲覧中には何らかのリダレイレクトを生じて表示速度が遅延している可能性があります。

上記キャプチャは1回だけリダイレクトが行われているページを調査したものです。
1回だけですので警告にはなっていませんが、780ミリ秒短縮できるとのメッセージが添えられています。
リダイレクトにかかる時間はサイトによって様々ですが、表示速度の面から損失が大きいことがうかがえます。

リダイレクトが起きうるシチュエーションやそれを減らすための対応としては以下のようなものが考えられます。

• URLの変更を行ってリダイレクトをせざるを得ない場合は複数回のリダイレクトを1回にまとめる
• 内部リンクにリダイレクトされるような古いURLを記載している場合は、リダイレクトが不要な最終的な正規URLにリンク先を変更する

なお、これはページスピードの観点だけでなく、クローラビリティ（クロールバジェット）の面からも推奨されることです。
これを機に内部リンクやサイトのリダイレクト設定を見直してみましょう。

以上がデータ生成フェーズの主なメッセージと改善ポイントでした。
ここからはデータ転送フェーズの改善です。

データ転送フェーズの改善

ほとんどのページでは、表示に必要なファイルはHTMLファイルだけではなく、追加で画像やCSSやJavaScriptなどの各ファイルを読み込むよう指示されていることがほとんどです。

それらの追加で必要とされるファイルのダウンロードにかかる時間が転送フェーズにあたります。
ここにかかる時間を短縮するためには、ファイルサイズを削減するのが鉄則となります。

ここからはデータ転送関連のメッセージの内容を解説します。
なお、一般的なWebページでは、画像が全リソースのうち60%以上を占めるとのことなので、画像の最適化がカギとなります。

過大なネットワーク ペイロードの回避

転送フェーズに改善余地があるかどうかは、まずこのメッセージを探してみましょう。

このアラートが出ている場合、ページを表示させるためにダウンロードする必要のあるリソースの合計サイズが大きすぎます。
メッセージをクリックすると対象ファイルが一覧化されていますので、実際にどのファイルのサイズが大きいのかを確認しましょう。

おそらくほとんどの場合は画像が該当するのではないでしょうか。

原因ファイルの種類がわかったら、それぞれに対応するエラーメッセージを探します。

効率的な画像フォーマット

画像圧縮によりファイルサイズ削減の余地がある際に出るアラートです。

見た目を変えないロスレス圧縮であればクオリティを落とすこともありませんので圧縮された画像を表示できるようにしましょう。

画像圧縮できるWebサービスやWordPressプラグインは数々あります。
圧縮された画像のみをアップロードするように運用を変えるか、サーバー上で自動圧縮するシステム（プラグイン等）を導入するかについては状況に合ったものを採用するのがよいかと思います。

圧縮サイトの例
TINY Ping https://tinypng.com/

画像圧縮可能なWordPressプラグインの例
EWWW Image Optimizer https://ja.wordpress.org/plugins/ewww-image-optimizer/

適切なサイズの画像

画像ファイルのサイズが大きくなればファイルサイズも大きくなってしまいます。
スマートフォンなど小さな端末であればPC向けほど大きな画像はいらないので、ブラウザ上の表示領域の大きさに応じてリサイズした画像をロードすることで余計なデータ量を削減します。

メディアクエリを使用したりレスポンシブ画像を使用するなどの方法があります。
参考：レスポンシブ画像
https://developer.mozilla.org/ja/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images

検証：ファイルサイズが表示速度に与える影響

ファイルサイズの大きさがどれほど表示速度に影響を与えるのか実験してみました。

今回は画像だけを表示するページを用意しました。
①3.8MBの画像を表示するページ
②それを無劣化圧縮して840KBにしたページ
③さらにリサイズにより167KBにしたページ
それぞれページスピードインサイトで調べて比較しています。
結果、ファイルサイズのLCPへの影響は非常に高いことがわかります。

なお、①から②で圧縮した場合のスコアはLCPの変化ほど大きく改善されていませんが、この場合は圧縮後もまだまだサイズが大きくてLCPに時間がかかっており、減点が大きかったためです。
この実験ではわかりやすさのためにファイルサイズの大きな画像を使用しましたが、単体で840KBもの画像を使うことはあまりなく、もともと適切なサイズの画像を使っていた場合は圧縮だけでも十分な効果が期待できるものと考えられます。
実際この場合でも、167KBまでサイズを落とすことで指標やスコアは大きく改善されました。

特に今まで画像の最適化を行っておらず、かつ画像使用数の多いページでは、画像の圧縮やリサイズは比較的楽にスコアアップが可能な施策であると考えられます。

次世代フォーマットでの画像の配信

従来のPNGやJPGよりも高い圧縮効率を実現できる画像フォーマットの使用を推奨するアラートです。

ただし注意点があります。

まず、JPEG2000やJPEG XRについては多くのブラウザではサポートされていないようなので、汎用的に使用できません。これらについては考慮しなくてよいでしょう。

また、ここに記載がありませんが、SVGもファイルサイズの削減が可能なフォーマットです。
特にベクター画像と呼ばれる、シンボルやロゴなどに適していますので、そのような場合は以下のWebPより優先して検討するとよいでしょう。

参考：ベクター画像とラスター画像
https://ja.wikipedia.org/wiki/ベクター画像

さて、残りはWebPについてです。
WebPは「ウェッピー」と読みます。

前述のとおりSVGがベクター画像のファイルサイズ削減に優れていますので、WebPは写真などのラスター画像に使うとよいかと思います。

WebPは同じ大きさの画像であれば、PNGやJPGに比べて約20%ほどのファイルサイズ削減が可能になります。

使用する際には通常の画像圧縮と同様にWebP変換を行ってくれるWebサービスやプラグイン等がありますので、新規でWebP画像を用意する必要はありません。

が、WebPも全てのブラウザでサポートされているわけではありません。

https://caniuse.com/?search=webp

本稿作成時点での最大の懸念は、Safariです。
iPhoneを中心としたiOS端末ではサポート済みであるものの、PC版のMacOSではいまだサポートされていないようです。
また、ブラウザシェアは低下しているものの根強く使われているIEもサポートされていません（対応予定さえなし）。

これについて以下のような選択が考えられます。

• 保留してより多くのブラウザで対応した際に検討する
• 未対応ブラウザにおいては既存の画像フォーマットでフォールバックを行う
• 未対応ブラウザにおいては.htaccessによる出し分けを行う
• 未対応ブラウザは無視してWebPを使用する

2番目のフォールバックについては、以下のように記述することで、対応ブラウザではWebPを、非対応ブラウザではjpgを表示することができます。

<picture>
  <source type="image/webp" srcset="flower.webp">
  <source type="image/jpeg" srcset="flower.jpg">
  <img src="flower.jpg" alt="">
 </picture>

3番目の.htaccessによる出し分けについては、Chromeなど対応ブラウザにはWebPを、対応していないブラウザには既存のjpgなどを出力する方法です。
フォールバックに比べてソースコードが複雑にならずに済むというメリットがあります。

例：
対応ブラウザ向け

<img src="flower.webp" alt="">

非対応ブラウザ向け

<img src="flower.jpg" alt="">

フォールバックによって対応するにしろ、.htaccessによって出しわけるにしろ、同じ画像を表示させるように注意するようにしましょう。

なお、4番目のWebPに統一する案については、未対応ブラウザのシェアは少ないもののやや強硬手段のように思います。
運用が楽になるメリットはあるのですが、最低限別のブラウザで閲覧するよう誘導するなど配慮するとよいのではないでしょうか。

いずれの方法でも対応が難しい場合はペンディングとなるでしょうが、画像による影響が大きいと思われるページであれば、少なくとも前述の圧縮やリサイズはきちんとやっておくことをおすすめいたします。

テキスト圧縮の有効化

ここからはCSSやJSなどのテキストベースのファイルの削減についてです。
これらのテキストファイルは画像と比べるとファイルサイズが小さいため、最適化余地としては小さいものとなります。
また、自分ではコントロールできないサードパーティのリソースが含まれていることもあります。

ただし、テキスト圧縮については一度仕様を決めて設定すればよいものなので、自サイトのファイルに対してメッセージが出ている場合は対応するとよいでしょう。

圧縮フォーマットについては、BrotliのほうがGZIPよりも高い圧縮効率を実現できますので、ブラウザや使用中のサーバーの対応状況も合わせて確認して導入を検討しましょう。

ブラウザ対応状況

https://caniuse.com/brotli

参考：Enable text compression – web.dev
https://web.dev/uses-text-compression/

検証：Brotli圧縮 vs Gzip圧縮

html,css,JavaScript,画像だけの簡単なページを作成して圧縮効果をChrome Dev Toolにて比較しました。
なお、Brotli圧縮を有効にするためにサーバー上の設定を行う必要があり、一般に広く使われていて設定の必要がなかったGzipとは異なり、設定のためにやや工数を要しました。
（ソースからビルドする必要があり、やや専門知識が必要）

２つの圧縮形式により、ファイルサイズの比較を行ったのが以下の表です。

Gzipより顕著な圧縮効果が見られたファイルに赤い目印をつけています。

圧縮効果はファイルによって差が出ましたが、今回検証したテキストファイルにおいて、Brotli圧縮ではGzip圧縮よりもさらに6～8割ほどに圧縮できているファイルもみられました。

一方、画像についてはいずれの形式でもほとんど圧縮できませんでした。
こちらについてはすでに述べたように、ロスレス圧縮、リサイズ、WebPなど次世代フォーマットへの変更など、別の方法によりファイルサイズの削減を図るべきだと言えます。

なお、弊社検証環境にてBrotli圧縮を行った場合、Gzip圧縮よりもサーバーの処理時間（TTFB）が長くなり、転送時間が短くなる現象が見られました。

結果、トータルとしてはBrotliのほうが短い時間で転送が完了しました。

このようにBrotliはGzipに比べてテキストファイルの圧縮効率が高く、転送時間短縮にも効果がありました。
速度が遅くなりがちなモバイル回線ではより差が出る可能性があります。

ただし、ファイルサイズが大きいリソースである画像には効果がない上、サーバー設定がやや煩雑というデメリットもみられました。

サーバーにデフォルトで組み込まれるようになれば大きく普及しそうですが、それまでに対応するかどうかは検討の上で決定したほうがよさそうです。

CSS の最小化、JavaScript の最小化

このメッセージが出た場合、ファイル内のスペースを削除したり、同じ指示や命令を１つにまとめたりすることによって文字数（つまりファイルサイズ）を削減する余地があります。

手間をかけたとしても、その割に削減できるサイズはあまり大きくないかと思います。

使用していない CSS を削除してください、使用していない JavaScript の削除

調査対象ページで使われていないCSSやJavaScriptがあった場合に表示されるメッセージです。

Chrome Dev ToolのCoverage機能を使うと、ファイルごとの未使用コードの割合や、具体的にどのコードが使われていないかをチェックすることが可能です。
（Coverageが表示されていない場合は、Dev Tool右上の三点リーダ部分からMore Tool→Coverageを選択すると表示可能です）

ただし、CSSやJavaScriptはページ共通で入っていることも多く、他のページでは使われているのかもしれませんので、他ページからも削除されてしまわないように注意する必要があります。
前述のとおり、CSSやJavaScriptは一般的にファイルサイズはそこまで大きくないため、最適化してもさほど表示速度は変わらない可能性があります。

ただし、後述するレンダリングフェーズにおいては、ファイルを分割することで余計なコードを削減しやすくなる可能性があります。
転送されるファイルサイズを削減する目的ではなく、レンダリングフェーズの最適化を目的として行うとよいかもしれません。

リクエスト数を少なく、転送サイズを小さく維持してください

ファイル数やファイルサイズを小さくしてくださいというメッセージです。
（budget.jsonについては、改善するための方法ではなく、監視するためのツールのようです。興味がある方は以下をご覧ください。
https://web.dev/use-lighthouse-for-performance-budgets/）

ファイルサイズについては、先述の「過大なネットワークペイロード」における指摘にもあるように、表示速度に影響を与えますのでなるべく小さくする必要があります。

しかしリクエスト数についてはどうなのでしょうか。
検証してみました。

検証：リクエスト数が表示速度に与える影響

実験として、30KBのファイル100個のページと、3MBのファイル1個のページで比較してみた結果は以下の通りです。
ファイル数はスコアに影響を与えないことがわかります。

検証した範囲では、リクエスト数はスコアに影響しないようです。
余計なリクエストを発生させないに越したことはありませんが、あまり気にしなくてよいのではないでしょうか。

静的なアセットと効率的なキャッシュ ポリシーの配信

ネットワークの通信をもっとも減らしてくれるものの一つがキャッシュです。ブラウザにキャッシュがある場合、サーバにアクセスせずそのキャッシュを使用して描画を試みるためです。つまり全てのキャッシュがある場合ネットワークの負荷は0になります。

なお、ページスピードインサイトはすべてのキャッシュをオフにしてアクセスしますので（初回アクセス時をエミュレート）、本施策を行ってもラボデータのスコアが上がるわけではありません。そのため、ページスピードインサイト上でも「診断」という形で改善項目とは別に表示されています。
しかし、フィールド環境（実際のユーザー）は複数ページ、複数セッションにわたってアクセスすることがありますので、キャッシュが効いていればそれだけ表示を高速化することが可能です。

対策は.htaccessやWordPressプラグインなどで、画像などファイル種類ごとにキャッシュ期間を設定していくことになります。

オフスクリーン画像の遅延読み込み

オフスクリーン（ファーストビューの外の）画像をページロード時には読み込まず、ユーザーがスクロールしたときにはじめてロードするようにすることで、インタラクティブになるまでの時間を早める施策です。

画像やiframeの遅延読み込みはweb標準になっていますので、htmlソース内にloading=”lazy” 要素を追加するだけです。

画像の場合

<img src="https://example.com/image.jpg" loading="lazy" width="640" height="360" alt="">

iframeの場合も同様です。
YouTube動画の埋め込みやFacebookいいねボタンの設置などが該当します。

<iframe src="https://example.com/" loading="lazy" width="640" height="360">

WordPressではバージョン5.5 より、画像には自動的にloading=”lazy”が付与されるようになりました。
ただし、widthとheightが設定されていることが必要です。（設定していないとCLSの原因となるため）

これからはネイティブLazy Loadを積極的に使っていくとよいのではないかと思います。

検証：Lazy Loadがスコアに与える影響

※2019年当時の検証です
本サイトはほとんどの画像をプラグインでLazy Loadにしていますが、意図的にプラグインを外した場合どうなるかを検証しました。結果スコアが36 → 28 と2割ほどダウンし、インタラクティブになるまでの時間は倍増しています。

※現在はプラグインを用いてLazy Loadを導入する必然性はなく、ネイティブLazy Loadを使うのが良いかと考えます。

さて、ここまでがデータ転送フェーズ関連の主なメッセージと改善内容でした。
ここからは描画フェーズの改善です。

描画（レンダリング）フェーズの改善方法

描画部分はページスピードの中でも影響が大きい割に対応が一番難しい部分です。
前述の転送部分ではCSSやJavaScriptはファイルサイズが比較的小さいためにあまり影響しませんでしたが、描画に対しては非常に大きく影響するため、これらの最適化がレンダリングフェーズのカギとなります

なお、完全にイコールではありませんが、LCPの描画フェーズの改善と、FIDの改善はリンクしています。

FIDはレンダリングブロックからの応答時間に関する指標ですが、レンダリングブロックが長いほどコンテンツが表示されるまでの時間もかかるからです。

レンダリングを妨げるリソースの除外

ブラウザはJavaScriptやcssなどを描画の途中でロードすると、ページの描画を止めてしまいます。
これをレンダリングブロックと呼びます。

このメッセージは特にページスピードインサイトのスコアが低いサイトでは、高確率で出てきます。ページスピードインサイトのスコアは、きちんと最後まで読み込むまでのスコアです。レンダリングブロック＝描画を止めて別の処理をする、ということですので、これらをなくしていくことでよりスムーズに描画ができるようになります。

対策としては、ファーストビューの表示を左右しないJavaScript、cssの2つをページ下部で読み込み、実行することです。ページによっては実行順を変えるとエラーになるなどおかしくなる場合もありますので、注意して進めてください。

また、JavaScriptの場合以下のように非同期または遅延読み込みすることもできます。

<script defer src="…"≶</script> 
 <script async src="…"></script>

もう一つ注意点として、ファーストビューに関連するcssを下部で読み込むと、cssが適用されるまでレイアウトが崩れる（後述するCLSが発生する可能性がある）という問題が出てきます。
ファーストビューに関連するCSSは上部で読み込むかインライン化を行いましょう。

検証：読み込み位置をヘッダーとフッターでかえた場合のスコア

レンダリングブロック対策の効果がどのくらいあるのかを調べるため、本サイトで、全css、JavaScriptをヘッダー読み込みとフッター読み込みの2つにわけて実験を行った結果を公開します。（※2019年当時）
結果は以下のように7 -> 32 と大きく改善する結果となりました。また合わせて「コンテンツの初回ペイント」「意味のあるコンテンツの初回ペイント」の2つも大きく改善していることがわかります。

ファーストビューに影響しないリソースがわかれば、比較的楽にスコアアップが期待できるかと思います。

document.write() を使用しない

document.write()はJavaScriptでテキストをHTMLに書きだしたいときに使用する記述ですが、ネットワーク遅延の影響もあり、HTML5では使用が強く非推奨となっています。

該当のコードが含まれているファイルや位置が表示されていますので、別の記述によって代替するようにしましょう。

過大な DOM サイズの回避

HTMLのノード数に関連するアラートです。
これが大きくなるとレンダリングに悪影響を及ぼすため、なるべく小さくすることが望まれます。
以下の場合にアラートが出るようです。

合計DOM要素数：1500以上
DOMの最大深さ：32以上
子要素の上限数：60以上

※最大深さとは<html><body><div><div><p><span>のような深さを指し、子要素とは<ul>に対する<li>のような、子要素の数を指します。

不必要なノードは極力削除する、まとめるなど、できるだけ数を少なくしましょう。

キー リクエストのプリロード

CSSやJavaScript内でロードされるリソースがある場合に表示されることがあります。
該当のファイルを以下のようにプリロードしておくことで対応可能です。

<link rel=”preload” href=”styles.css” as=”style”>
<link rel=”preload” href=”ui.js” as=”script”>

第三者コードの影響を抑えてください

サードパーティJavaScriptによってレンダリング遅延が大きい場合に表示されることがあります。
第三者コードであるため、中身は変えることができませんが、不要なコードを削除したり、ページの下部で読み込むことでファーストビューのレンダリングへの影響を削減することができます。

メインスレッド処理の最小化、JavaScript の実行にかかる時間の低減、Avoid long main-thread tasks

CSSやJavaScriptを実行する際などにはブラウザのメインスレッドが占有され、他の作業が止まってしまいます。
特にJavaScriptを見直して止める時間を短くするか、止める要素を削除する必要がありますが、これらの改善は難易度が高いと予想されます。

サイトごとに対応がかわってくるでしょうが、以下にチューニングのヒントになりそうなものを箇条書きでご紹介します。

• このページで必要でない機能が含まれていないか確認
• 不要なタグ（解析系など）が含まれていないか確認
• 不要な機能がないかの確認（UI/UXを削る）
• 無駄な処理がないか確認
• setTimeoutなどを利用してメインスレッドから外せる処理がないか
• ファーストビューの描画が終わった後で実行してもよいものがないか
• サーバーサイドでレンダリングできないか

Javascriptのチューニングは、UI/UXの犠牲を伴うものもでてくるかもしれません。機能が本当に必要なのかも検討する必要がありますが、ページスピードインサイトのスコアをどこまで上げるかについてもきちんと考える必要があります。

FID（初回入力遅延）の改善方法

FIDはユーザーが最初にページ上のボタンやリンクをタップもしくはクリックしてからブラウザが応答できるようになるまでの時間のことです。

ユーザーがどのタイミングでクリックするかはコントロールできないため、FIDはフィールドデータのみの指標です。
そのため、ラボデータであるLightHouseでは測定できません。

そこで、合計ブロック時間（Total Blocking Time, TBT）を指標に改善を行います。
ただし、TBTが変わらなくても、長時間のブロックの原因となっているメインスレッドタスクを分割すればFIDの軽減につながりますので、そういったコードを分割するアプローチが特に有効だと考えられます。

改善にあたっては、LCPのレンダリングの項目で紹介した各施策がイコールではありませんが適用可能です。

「描画（レンダリング）フェーズの改善方法」で紹介した各項目まで戻って参照ください。

• レンダリングを妨げるリソースの除外
• 過大な DOM サイズの回避
• キー リクエストのプリロード
• 第三者コードの影響を抑えてください
• メインスレッド処理の最小化
• JavaScript の実行にかかる時間の低減
• Avoid long main-thread tasks

CLS（累積レイアウト変更）の改善方法

CLSは読み込み中に発生するレイアウトのずれを指します。
幸いなことに、CLSが生じているかどうかは視覚的にわかりやすいということがあります。
ページスピードインサイトを使ってCLSの原因要素を特定することもできますが、手元のデバイスを使って目視調査することもおすすめです。

まずは原因要素の特定を行い、特定された要素についての対応を行います。
たいていの場合、その原因要素は以下のようなものです。
• 画像
• 広告
• その他JavaScriptによって動的に挿入される要素
• フォントファイルが適用されることによるずれ

CLSをなくすことが難しい場合は、原因となっている要素をページ上方に置かない（下方に移動する）ことである程度影響が軽減できるかと思います。

ページスピードインサイトの連写キャプチャを参照する

ページスピードインサイトではページ読み込み中の表示の様子が連写でキャプチャ取得されています。
キャプチャを横に眺めていると急に要素が出現してCLSの原因となるずれが発生していることがわかるので、その要素に応じた対応を行います。

上のキャプチャでは、メイン画像やファーストビュー内下段に出現する画像によって、すでに表示されていたテキストが下にずれています。そのためこれらの画像によるずれを抑制すればいよいことがわかります。

なお、ページスピードインサイトを使わなくても、Chrome Dev ToolのPerformanceタブから取得することもできますし、手元の端末でページを開いてみて確認してもOKです。

ここでは原因となる要素を特定するのが目的ですので、対応方法については後述します。

レイアウトが大きく変わらないようにする(Avoid large layout shifts)

この項目では、読み込み中にずれが検出された要素とそのCLS値が掲載されています。

注意して欲しいのは、この要素がCLSの原因になっているというよりは、直前の要素によって下に押し下げられた要素がピックアップされているということです。

前述のキャプチャや目視確認と合わせて、上部にずれの原因となる要素がないかどうか確認しましょう。
ずれた要素が直接ピックアップされているわけではないため、キャプチャや目視調査を行った方が手っ取り早いかもしれません。
ただこの項目のメリットとしては、値がついているので対応の優先度はつけやすいことでしょうか。

CLSの原因となっている要素が特定できたら、その要素に合った対応を行います。

画像によってCLSが発生している場合の対処法

画像によってCLSが発生している場合の対応は単純です。widthとheightを記載するだけです。

しかし多くのサイトではレスポンシブを採用して画像のwidthやheightを記載せず、cssで比率を決めているだけになってはいないでしょうか。

HTML上の記述

<img src="image.jpg">

CSS上の記述

img {
  width:100%;
  height:auto;
 } 

この場合、ブラウザは画面サイズとcssに記載されている比率をもとに横幅を決めることはできますが、画像の縦幅はロードするまでわかりません。
そのため、とりあえず縦幅をゼロとして画面描画を行うため、画像がロードされた際に急にずれてしまう現象が起きてしまいます。
これが画像によるCLSの原因です。

回避するためには、単純にHTMLでサイズを記載しておきます。

HTML上の記述

<img src="image.jpg" width="640" height="360">

CSS上の記述

img {
  width:100%;
  height:auto;
 } 

ブラウザが画面上に表示させる大きさとしては、CSSに記載しておけばそちらが採用されるため、HTMLに記載されたものは無視されて採用されません。
それでもHTMLにサイズを記載しておく必要性は、ブラウザがHTMLに記載されたサイズからあらかじめ縦横比を計算するため、画像がロードされる以前からあらかじめ領域を確保できるようになるためです。

画像表示に必要な領域があらかじめ確保されることで、CLSの発生を回避することができます。
HTMLには画像の原寸サイズを記載しておくとよいでしょう。

検証：画像サイズを指定することによるCLS抑制効果

上述のようにサイズを記載しておくことで、CLSやページスピードインサイトのスコアがどうなるかを検証しました。
画像とテキストだけの簡素なページを調査の対象としました。

その結果、サイズ指定のないページではCLSが発生してしまいましたが、サイズを指定しておけばCLSをゼロにすることができました。
しかし、CLSが発生していてもスコアの減点はわずか2となっており、スコアへの影響はほとんどありませんでした。
これはCLSの配点が5%しかないためです。

CLSが抑制できていることは連写キャプチャからも明らかです。
HTMLでサイズを指定しておけば、ブラウザは読み込み前から画像に必要な領域を確保してくれます。

ブログのアイキャッチ画像など、ファーストビューにある画像は特にCLSの原因となりやすいため、サイズを記載しておくようにしましょう。

広告によってCLSが発生している場合の対処法

広告によるCLSも画像と同様に、表示領域があらかじめ確保されていないために起こるものです。
ただし、画像と違ってロードされる広告のサイズをコントロールすることができない場合もあるでしょうから、そのような場合はプレースホルダを設定しておくことで対応します。

※プレースホルダ（灰）が設定されていることで広告（青）がロードされてもずれが生じていない

どのようなサイズのプレースホルダを設定するかについては以下の考えがあります。
①可能な限り最大のサイズを予約する
　→CLSは抑制できる一方で、より小さい広告がロードされた場合は余白ができてしまう。
②履歴に基づいて、読み込まれることが多いサイズで予約しておく
　→大きい広告がロードされた場合、はみだしたり切り取られてしまう。はみ出した場合CLSが発生してしまう。

プレースホルダを静的な大きさで確保するのであれば単純ですが、広告の大きさが変わる場合はCSSやJavaScriptによって領域をリサイズします。
詳しくは以下を参照ください。
Minimize layout shift
https://developers.google.com/doubleclick-gpt/guides/minimize-layout-shift

ただし、CLSを抑制したとしても広告がファーストビュー内上部にあることは好ましくありません。
広告のためにファーストビュー内にメインコンテンツが視認しづらいページは、ユーザー体験を損なうものとして評価が下げられてしまうためです。
広告はより下部に移動することで、ファーストビュー内ではメインコンテンツを阻害しないようにすることがおすすめです。

参考：ページレイアウトのSEO効果と設計のポイント
https://www.sakurasaku-marketing.co.jp/labo/blogs/pagelayout

まとめ

ページスピードインサイトをもとにしたコアウェブバイタルの改善方法について一通り見てきました。

コアウェブバイタルは現在のところ表示速度を除いてSEOのランキング要因ではありません。コアウェブバイタルがランキング要因となるのは2021年5月です。
それ以降もUX指標がランキングに大きく影響することはないと考えられます。
順位上昇が目的であれば、改善を行っても明白なランキング上昇効果は見込めないでしょうが、UX向上を目的とするならば積極的に取り組みたい施策です。

しかし見てお分かりになるかと思いますが、改善は一筋縄ではいかないケースも多くあることでしょう。
可能であればAMP導入により改善することも検討するとよいかと思います。

既存ページを直接改善するのであれば、画像のファイルサイズ削減やCLS対策が比較的取り組みやすいと考えられます。
サーチコンソールでLCPやCLSの警告が出ていたらまずはここから着手することがおすすめです。

記事を読んでもどこから手をつけていいのかわからないという場合は、是非サクラサクラボまでご相談ください。

弊社のコンサルタントが現状を調査し、改善の方向性についてアドバイスを行います。

無料相談会へのお申し込みはコチラ