Google PageSpeed Insight（グーグルページインサイト）がリニューアル！ツールの見方・使い方から改善方法を解説

スマホやパソコンで検索をしてたどり着いたページがずっと読み込みに時間がかかっていたら表示されるまで待ちますか？それともすぐ離脱してしまいますか？

今やWebページの表示速度はGoogle検索結果ページの順位を決定するシグナルにも使われているほど重要な要素になっています。ECカートでは平均約2秒程度ですぐに離脱してしまうという調査が出るほどです。

Googleではサイトの表示速度計測ツールとして、PageSpeed Insightというツールを提供しています。手軽に自身のサイトをチェックできるツールなので、この記事を元に活用していただければと思います。

Webページの表示速度はSEO評価のシグナルの一つ

意外と知られていませんが、Webページの読み込み速度はGoogle検索結果ページの検索順位を決定するシグナルとして利用されてきました。少し遅いぐらいであれば気にしなくても問題はなく、極端に読み込み速度が遅いWebページはSEO評価にマイナスの影響があるというものです。

読み込み速度はこれまでもランキングシグナルとして使用されていましたが、それはデスクトップ検索を対象としていました。 そこで 2018 年 7 月よりページの読み込み速度をモバイル検索のランキング要素として使用することを本日みなさんにお伝えしたいと思います。

Google検索セントラル　ページの読み込み速度をモバイル検索のランキング要素に使用します

2018年にGoogleは「Googleウェブマスター向け公式サイト」でWebページの読み込み速度の検索順位の評価をデスクトップ検索だけではなく、モバイル検索にも適用することを発表しています。また2016年にGoogleはMFI（モバイルファーストインデックス）の導入を発表しており2018年3月から一部サイトにおいてMFIの適用が開始されました。

このように、パソコンよりもスマホを優先する時代の流れに合わせて、Googleは検索結果ページの検索順位のアルゴリズムに改良を加えており、自身のWebサイトにおいてもSEO・ユーザビリティの観点からも問題がある場合、対応を行う必要があります。

Google PageSpeed Insight（グーグルページインサイト）とは

Google PageSpeed Insight（グーグルページインサイト）は、Googleが提供している無料のWebページの表示速度調査ツールです。調べたいWebページのURLを入力して検索実行するだけで、実際にスマホ・PC端末でWebページが表示された時のパフォーマンスを0〜100点満点のスコアで表示してくれます。

さらにWebページ上のパフォーマンスを改善するためのポイントも教えてくれるため、より良いサイトに改善するのを手助けしてくれます。もちろん、競合のWebページも簡単に調べることができるので競合分析ツールとしても利用することができます。

ちなみに以前のGoogle PageSpeed Insight（グーグルページインサイト）の画面はこんな感じでした。

Google PageSpeed Insight（グーグルページインサイト）の特徴・できること

当ブログをGoogle PageSpeed Insightでテストを行った結果画面が上記になります。Google PageSpeed Insightを使ってWebサイトをテストすることで下記の診断結果を知ることができます。

• 実際のユーザーの環境で評価する：速度や安定性の評価（Lighthouse）
• パフォーマンスの問題を診断する：速度や安定性の評価
• 改善できる項目：改善内容と短縮時間の予測の提示
• 診断：Webページが推奨される設定か診断、改善内容の提示
• 合格した監査：問題がない項目の提示

PageSpeed Insightsは2021年11月にリニューアルし、よりわかりやすいUIになりました。分析は「実際のユーザーの環境で評価する」データと、特定の制御された環境で収集した「パフォーマンスの問題を診断する」データに分かれて実行されます。これらのカテゴリーは、リニューアル前にはそれぞれ「フィールドデータ」「ラボデータ」という名称で記載されていました。

診断を行うには、URLを入力して「分析」ボタンをクリックするだけです。自社Webサイトだけでなく他社Webサイトも分析することができ、またWebサイト全体だけでなくページ単位でも分析できます。具体的には以下のような分析項目が設けられています。

各項目で分析できる内容について見ていきましょう。

Google PageSpeed Insight（グーグルページインサイト）の実際のユーザーの環境で評価する（旧フィールドデータ）

「実際のユーザーの環境で評価する」は、過去30日間における実際のユーザーデータにもとづいた評価が行われます。当ブログのトップページを実際にPageSpeed Insightsで分析した画面です。

FCP（First Contentful Paint）：最初のコンテンツ表示にかかるまでの時間

FCP（First Contentful Paint）はユーザーがWebページをクリック（ページへのアクセスをリクエスト）してからページ内のいずれかのコンテンツが表示されるまでにどれぐらいの時間がかかったのかを示す指標です。ユーザー体験を最大化するためにも、FCPが1.8秒以下になるようにサイトの改善を行いましょう。First Contentful Paint (FCP)によるとスコアの評価は下記になります。

• 「良い」：0～1.8秒
• 「要改善」：1.8～3.0秒
• 「不十分」：3.0秒以上

LCP（Largest Contentful Paint ）：メインコンテンツの読み込み時間

LCP（Largest Contentful Paint ）はユーザーがWebページをクリック（ページへのアクセスをリクエスト）してからページ内のメインコンテンツが表示されるまでにどれぐらいの時間がかかったのかを示す指標です。先ほどのFCPはページ内のいずれかのコンテンツでしたが、LCPはメインコンテンツが表示されるまでにかかった時間を示す指標になります。Largest Contentful Paint (LCP)によるとスコアの評価は下記になります。

• 「良い」：0～2.5秒
• 「要改善」：2.5～4.0秒
• 「不十分」：4.0秒以上

FID（First Input Delay）：Webページの応答性

FID（First Input Delay）はユーザーがWebページ上で何かしらのアクション（クリック、キーボード入力など）を行なってからWebサーバーからの応答がどれぐらいの時間であったかを示す指標になります。First Input Delay (FID)によるとスコアの評価は下記になります。

• 「良い」：0～100ms（ミリ秒）
• 「要改善」：100～300ms
• 「不十分」：300ms以上

CLS（Cumulative Layout Shift）：視覚的な安定性

CLS（Cumulative Layout Shift）はユーザーがWebページを閲覧した際に、レイアウト上のずれやゆがみを数値化したものでコンテンツの視覚的な安定性を示す指標になります。Cumulative Layout Shift (CLS)によるとスコアの評価は下記になります。

• 「良い」：0～0.1
• 「要改善」：0.1～0.25
• 「不十分」：0.25以上

Google PageSpeed Insight（グーグルページインサイト）のパフォーマンスの問題を診断する（旧ラボデータ）

「パフォーマンスの問題を診断する」は、スマホ・PC環境下でシミュレーションした結果によって評価が行われます。あくまでシミュレーションになるので、数値としては参考程度に考えるので問題ありません。当ブログのトップページを実際にPageSpeed Insightsで分析した画面です。

FCP（First Contentful Paint）：最初のコンテンツ表示にかかるまでの時間

FCP（First Contentful Paint）はユーザーがWebページをクリック（ページへのアクセスをリクエスト）してからページ内のいずれかのコンテンツが表示されるまでにどれぐらいの時間がかかったのかを示す指標です。

Speed Index：ページの読み込み時間

Speed Indexは、Webページのコンテンツが視覚的に表示されるまでの速さを数値化した指標になります。Speed IndexはWebページが完全な状態で表示されるまでの時間が短いほどスコアが高くなります。具体的には、秒数毎の描画面積から算出されます。Speed Indexによるとスコアの評価は下記になります。

• 「速い」：0〜3.4秒：
• 「平均」：3.4〜5.8秒
• 「遅い」：5.8秒以上

LCP（Largest Contentful Paint）：メインコンテンツの読み込み時間

LCP（Largest Contentful Paint ）はユーザーがWebページをクリック（ページへのアクセスをリクエスト）してからページ内のメインコンテンツが表示されるまでにどれぐらいの時間がかかったのかを示す指標です。

TTI（Time to Interactive）：Webページのインタラクティブ性

TTI（Time to Interactive）は、直訳するとインタラクティブまでの時間という意味になります。インタラクティブはWebページ上でユーザーが自由に操作できるようになった状態です。ユーザーがWebページ上でインタラクティブになるまでにどれぐらいの時間がかかったを示す指標になります。Time to Interactiveによるとスコアの評価は下記になります。

• 「速い」：0〜3.8秒
• 「平均」：3.9〜7.3秒
• 「遅い」：7.3秒以上

TBT（Total Blocking Time）：合計ブロック時間

TBT（Total Blocking Time）はユーザーがWebページ上で何かしらのアクション（クリック、キーボード入力など）を行なってからWebサーバーの応答がブロックされている時間の合計がどれぐらいの時間であったかを示す指標になります。最初にWebページ上のコンテンツが表示されてからユーザーが操作可能になるまでの間に50ミリ秒を超える処理があると「ブロックされた」と診断されます。読み込まれるコンテンツが50ミリ秒を超える度に合計ブロック時間が加算されて合計を算出します。Total Blocking Time (合計ブロック時間)によるとスコアの評価は下記になります。

• 「速い」：0～200ms（ミリ秒）
• 「中程度」：200～600ms
• 「遅い」：600ms以上

改善のためには、できるだけLong taskを避ける必要があります。改善するには、次の要素が考えられます。

CLS（Cumulative Layout Shift）：視覚的な安定性

CLS（Cumulative Layout Shift）はユーザーがWebページを閲覧した際に、レイアウト上のずれやゆがみを数値化したものでコンテンツの視覚的な安定性を示す指標になります。

Google PageSpeed Insight（グーグルページインサイト）の改善できる項目の一覧と対応策

Google PageSpeed Insightの改善できる項目について、具体的にどういう項目が挙げられるのか、またどういう対応が求められるのかを説明します。

リンク先ページでリダイレクトを使用しない

Google PageSpeed Insightでは、特定のリンクをクリックしたときに最終的に到達するまでに、複数回リダイレクト処理が行われると表示されます。理由としては、Webサーバーに負荷をかけないことが考えられます。リダイレクトが1回だとしても、Webサーバーに対してページを開くリクエストとページを見せる応答のワンセットがあります。それに加えて外部のWebサーバーにも処理が必要な場合、どうしても処理に負荷がかかってしまいます。そのため、複数回に渡るようなリダイレクトは可能な限り最小限にすることが求められるでしょう。

Google PageSpeed Insightのドキュメントにも記載があるように、「リダイレクトを控えること」が対策になります。

圧縮を有効にする

Webサーバーとの通信の際に、読み込まれるデータはできるだけ圧縮する方が望ましいと考えられています。例えば、テキスト、画像、フォントなどの圧縮可能なデータは「gzip形式」で圧縮することが求められます。

UNIX系のコマンドでもある「gzip形式」に圧縮することで、元データから約8〜9割程度の圧縮も期待できます。そのため、リソースのダウンロード時間の大幅な短縮、ユーザーのデータ使用量の削減、ページレンダリング時間短縮など、Webサイトのパフォーマンス改善にも効果があります。

ブラウザのキャッシュを活用する

最近ではどのブラウザを使っていてもHTTPキャッシュを利用することができるので、ネットワーク遅延と転送するデータコストを削減することができるのでブラウザのキャッシュは活用すべきです。

HTTPキャッシュでWebサーバーが各送信応答に追加するヘッダーについては下記を参照してください。

Cache-Control: サーバーは、 Cache-Controlディレクティブを返します。このディレクティブは、ブラウザおよびその他の中間キャッシュが個々の応答をキャッシュする方法と期間を指定します。

ETag: ブラウザは、期限切れになったキャッシュに格納された応答を見つけると、小さいトークン (通常はファイルの内容のハッシュ) をサーバーに送信して、ファイルが変更されたかどうかを確認できます。サーバーが同じトークンを返す場合、ファイルは同じであり、再ダウンロードする必要はありません。

Last-Modified: このヘッダーは、ETagと同じ目的を果たしますが、ETagのコンテンツベースのストラテジとは対照的に、時間ベースのストラテジを使用して、リソースが変更されたかどうかを判断します。

HTTPキャッシュを使用して不要なネットワーク要求を防ぐ

サーバーの応答時間を改善する

Webサーバーの応答時間とはWebページのレンダリングを開始する時にかかった時間になります。Webサーバーの応答時間は200ミリ秒以下に抑えることが推奨とされています。特に応答時間が長くなる原因としてはアプリケーション、データベース、、ライブラリなどが挙げられます。

リソース（HTML、CSS、JavaScript）を圧縮する

ブラウザの処理に依存しないように、事前にデータを最適化、圧縮しておくということです。基本的にはコード内の重複する記述、コメント、使用していないコードを削除します。HTMLはHTMLMinifier、CSSはCSSNano、csso、JavascriptはUglifyJSかデータをダウンロードして使用することが推奨されています。

画像を最適化する

画像の品質を保ちながら、圧縮できる余地がある場合に改善できる項目として挙げられます。特に画像ファイルはWebページのダウンロード時にデータ量の大半を占めることがあっるので画像を最適化するだけで、パフォーマンスが大幅に改善することもあります。

Web上ではGIF・PNG・JPEG形式の画像が96％を占めており、各画像ファイル形式に合わせて下記の改善方法を取ることでパフォーマンスを改善できるでしょう。

GIF・PNG形式は可逆圧縮の形式であり、圧縮処理で画像が視覚的に変化することはありません。JPEGは非可逆圧縮の形式なので、圧縮処理で画像の視覚的な細かさが失われますが、圧縮比はGIFやPNGよりも10倍高くなると言われています。

CSSの配信を最適化する

Webページのレンダリングをブロックする外部スタイルシートの読み込みに関して、CSSのリソース量が少ない場合は、HTML内に直接記述することが有効とされています。逆にCSSのリソース量が多い場合でも、スクロールせずに表示される領域に関してだけ、HTML内に直接記述することで読み込み速度の改善が可能です。

スクロールせずに見える範囲のコンテンツのサイズを削減する

Webページを快適に閲覧するためにも、スクロールせずに見えるページ範囲のコンテンツの表示に必要なデータ（HTML マークアップ、画像、CSS、JavaScript）のサイズを制限します。

レンダリングを妨げるJavaScripを削除する

WebページのレンダリングをブロックするJavaScriptをインライン化、非同期化、遅延読み込みさせることで、Webページのパフォーマンスを改善させることができます。CSSに関しても配信方法を改善することが改善が期待できるので、JavaScriptもセットで対応を検討してみてはいかがでしょうか。