
- 現役Webマーケター
(元Webディレクター) - 東証一部上場の不動産系企業で勤務
- 最高収益:月間30万円
スマホやパソコンで検索をしてたどり着いたページがずっと読み込みに時間がかかっていたら表示されるまで待ちますか?それともすぐ離脱してしまいますか?
今やWebページの表示速度はGoogle検索結果ページの順位を決定するシグナルにも使われているほど重要な要素になっています。ECカートでは平均約2秒程度ですぐに離脱してしまうという調査が出るほどです。
Googleではサイトの表示速度計測ツールとして、PageSpeed Insightというツールを提供しています。手軽に自身のサイトをチェックできるツールなので、この記事を元に活用していただければと思います。
意外と知られていませんが、Webページの読み込み速度はGoogle検索結果ページの検索順位を決定するシグナルとして利用されてきました。少し遅いぐらいであれば気にしなくても問題はなく、極端に読み込み速度が遅いWebページはSEO評価にマイナスの影響があるというものです。
読み込み速度はこれまでもランキングシグナルとして使用されていましたが、それはデスクトップ検索を対象としていました。 そこで 2018 年 7 月よりページの読み込み速度をモバイル検索のランキング要素として使用することを本日みなさんにお伝えしたいと思います。
Google検索セントラル ページの読み込み速度をモバイル検索のランキング要素に使用します
2018年にGoogleは「Googleウェブマスター向け公式サイト」でWebページの読み込み速度の検索順位の評価をデスクトップ検索だけではなく、モバイル検索にも適用することを発表しています。また2016年にGoogleはMFI(モバイルファーストインデックス)の導入を発表しており2018年3月から一部サイトにおいてMFIの適用が開始されました。
このように、パソコンよりもスマホを優先する時代の流れに合わせて、Googleは検索結果ページの検索順位のアルゴリズムに改良を加えており、自身のWebサイトにおいてもSEO・ユーザビリティの観点からも問題がある場合、対応を行う必要があります。
Google PageSpeed Insight(グーグルページインサイト)は、Googleが提供している無料のWebページの表示速度調査ツールです。調べたいWebページのURLを入力して検索実行するだけで、実際にスマホ・PC端末でWebページが表示された時のパフォーマンスを0〜100点満点のスコアで表示してくれます。
さらにWebページ上のパフォーマンスを改善するためのポイントも教えてくれるため、より良いサイトに改善するのを手助けしてくれます。もちろん、競合のWebページも簡単に調べることができるので競合分析ツールとしても利用することができます。
ちなみに以前のGoogle PageSpeed Insight(グーグルページインサイト)の画面はこんな感じでした。
当ブログをGoogle PageSpeed Insightでテストを行った結果画面が上記になります。Google PageSpeed Insightを使ってWebサイトをテストすることで下記の診断結果を知ることができます。
PageSpeed Insightsは2021年11月にリニューアルし、よりわかりやすいUIになりました。分析は「実際のユーザーの環境で評価する」データと、特定の制御された環境で収集した「パフォーマンスの問題を診断する」データに分かれて実行されます。これらのカテゴリーは、リニューアル前にはそれぞれ「フィールドデータ」「ラボデータ」という名称で記載されていました。
診断を行うには、URLを入力して「分析」ボタンをクリックするだけです。自社Webサイトだけでなく他社Webサイトも分析することができ、またWebサイト全体だけでなくページ単位でも分析できます。具体的には以下のような分析項目が設けられています。
各項目で分析できる内容について見ていきましょう。
「実際のユーザーの環境で評価する」は、過去30日間における実際のユーザーデータにもとづいた評価が行われます。当ブログのトップページを実際にPageSpeed Insightsで分析した画面です。
FCP(First Contentful Paint)はユーザーがWebページをクリック(ページへのアクセスをリクエスト)してからページ内のいずれかのコンテンツが表示されるまでにどれぐらいの時間がかかったのかを示す指標です。ユーザー体験を最大化するためにも、FCPが1.8秒以下になるようにサイトの改善を行いましょう。First Contentful Paint (FCP)によるとスコアの評価は下記になります。
LCP(Largest Contentful Paint )はユーザーがWebページをクリック(ページへのアクセスをリクエスト)してからページ内のメインコンテンツが表示されるまでにどれぐらいの時間がかかったのかを示す指標です。先ほどのFCPはページ内のいずれかのコンテンツでしたが、LCPはメインコンテンツが表示されるまでにかかった時間を示す指標になります。Largest Contentful Paint (LCP)によるとスコアの評価は下記になります。
FID(First Input Delay)はユーザーがWebページ上で何かしらのアクション(クリック、キーボード入力など)を行なってからWebサーバーからの応答がどれぐらいの時間であったかを示す指標になります。First Input Delay (FID)によるとスコアの評価は下記になります。
CLS(Cumulative Layout Shift)はユーザーがWebページを閲覧した際に、レイアウト上のずれやゆがみを数値化したものでコンテンツの視覚的な安定性を示す指標になります。Cumulative Layout Shift (CLS)によるとスコアの評価は下記になります。
「パフォーマンスの問題を診断する」は、スマホ・PC環境下でシミュレーションした結果によって評価が行われます。あくまでシミュレーションになるので、数値としては参考程度に考えるので問題ありません。当ブログのトップページを実際にPageSpeed Insightsで分析した画面です。
FCP(First Contentful Paint)はユーザーがWebページをクリック(ページへのアクセスをリクエスト)してからページ内のいずれかのコンテンツが表示されるまでにどれぐらいの時間がかかったのかを示す指標です。
Speed Indexは、Webページのコンテンツが視覚的に表示されるまでの速さを数値化した指標になります。Speed IndexはWebページが完全な状態で表示されるまでの時間が短いほどスコアが高くなります。具体的には、秒数毎の描画面積から算出されます。Speed Indexによるとスコアの評価は下記になります。
LCP(Largest Contentful Paint )はユーザーがWebページをクリック(ページへのアクセスをリクエスト)してからページ内のメインコンテンツが表示されるまでにどれぐらいの時間がかかったのかを示す指標です。
TTI(Time to Interactive)は、直訳するとインタラクティブまでの時間という意味になります。インタラクティブはWebページ上でユーザーが自由に操作できるようになった状態です。ユーザーがWebページ上でインタラクティブになるまでにどれぐらいの時間がかかったを示す指標になります。Time to Interactiveによるとスコアの評価は下記になります。
TBT(Total Blocking Time)はユーザーがWebページ上で何かしらのアクション(クリック、キーボード入力など)を行なってからWebサーバーの応答がブロックされている時間の合計がどれぐらいの時間であったかを示す指標になります。最初にWebページ上のコンテンツが表示されてからユーザーが操作可能になるまでの間に50ミリ秒を超える処理があると「ブロックされた」と診断されます。読み込まれるコンテンツが50ミリ秒を超える度に合計ブロック時間が加算されて合計を算出します。Total Blocking Time (合計ブロック時間)によるとスコアの評価は下記になります。
改善のためには、できるだけLong taskを避ける必要があります。改善するには、次の要素が考えられます。
CLS(Cumulative Layout Shift)はユーザーがWebページを閲覧した際に、レイアウト上のずれやゆがみを数値化したものでコンテンツの視覚的な安定性を示す指標になります。
Google PageSpeed Insightの改善できる項目について、具体的にどういう項目が挙げられるのか、またどういう対応が求められるのかを説明します。
Google PageSpeed Insightでは、特定のリンクをクリックしたときに最終的に到達するまでに、複数回リダイレクト処理が行われると表示されます。理由としては、Webサーバーに負荷をかけないことが考えられます。リダイレクトが1回だとしても、Webサーバーに対してページを開くリクエストとページを見せる応答のワンセットがあります。それに加えて外部のWebサーバーにも処理が必要な場合、どうしても処理に負荷がかかってしまいます。そのため、複数回に渡るようなリダイレクトは可能な限り最小限にすることが求められるでしょう。
Google PageSpeed Insightのドキュメントにも記載があるように、「リダイレクトを控えること」が対策になります。
Webサーバーとの通信の際に、読み込まれるデータはできるだけ圧縮する方が望ましいと考えられています。例えば、テキスト、画像、フォントなどの圧縮可能なデータは「gzip形式」で圧縮することが求められます。
UNIX系のコマンドでもある「gzip形式」に圧縮することで、元データから約8〜9割程度の圧縮も期待できます。そのため、リソースのダウンロード時間の大幅な短縮、ユーザーのデータ使用量の削減、ページレンダリング時間短縮など、Webサイトのパフォーマンス改善にも効果があります。
「gzip形式」で圧縮する
・Apache: mod_deflate を使用する
・Nginx: ngx_http_gzip_module を使用する
・IIS: HTTP 圧縮を設定する
最近ではどのブラウザを使っていてもHTTPキャッシュを利用することができるので、ネットワーク遅延と転送するデータコストを削減することができるのでブラウザのキャッシュは活用すべきです。
HTTPキャッシュでWebサーバーが各送信応答に追加するヘッダーについては下記を参照してください。
Cache-Control: サーバーは、 Cache-Controlディレクティブを返します。このディレクティブは、ブラウザおよびその他の中間キャッシュが個々の応答をキャッシュする方法と期間を指定します。
ETag: ブラウザは、期限切れになったキャッシュに格納された応答を見つけると、小さいトークン (通常はファイルの内容のハッシュ) をサーバーに送信して、ファイルが変更されたかどうかを確認できます。サーバーが同じトークンを返す場合、ファイルは同じであり、再ダウンロードする必要はありません。
Last-Modified: このヘッダーは、ETagと同じ目的を果たしますが、ETagのコンテンツベースのストラテジとは対照的に、時間ベースのストラテジを使用して、リソースが変更されたかどうかを判断します。
HTTPキャッシュを使用して不要なネットワーク要求を防ぐ
Webサーバーの応答時間とはWebページのレンダリングを開始する時にかかった時間になります。Webサーバーの応答時間は200ミリ秒以下に抑えることが推奨とされています。特に応答時間が長くなる原因としてはアプリケーション、データベース、、ライブラリなどが挙げられます。
ブラウザの処理に依存しないように、事前にデータを最適化、圧縮しておくということです。基本的にはコード内の重複する記述、コメント、使用していないコードを削除します。HTMLはHTMLMinifier、CSSはCSSNano、csso、JavascriptはUglifyJSかデータをダウンロードして使用することが推奨されています。
画像の品質を保ちながら、圧縮できる余地がある場合に改善できる項目として挙げられます。特に画像ファイルはWebページのダウンロード時にデータ量の大半を占めることがあっるので画像を最適化するだけで、パフォーマンスが大幅に改善することもあります。
Web上ではGIF・PNG・JPEG形式の画像が96%を占めており、各画像ファイル形式に合わせて下記の改善方法を取ることでパフォーマンスを改善できるでしょう。
GIF・PNG形式は可逆圧縮の形式であり、圧縮処理で画像が視覚的に変化することはありません。JPEGは非可逆圧縮の形式なので、圧縮処理で画像の視覚的な細かさが失われますが、圧縮比はGIFやPNGよりも10倍高くなると言われています。
画像形式がGIF・PNGの場合
・GIFはPNGに変換する
・すべてのピクセルが不透明な場合はアルファチャンネルを削除
画像形式がJPEGの場合
・画質を85まで下げる
・クロマサンプリングを4:2:0にする
・10キロバイトを超える画像はプログレッシブJPEG形式を使用
・白黒画像はグレースケールの色空間を使用
Webページのレンダリングをブロックする外部スタイルシートの読み込みに関して、CSSのリソース量が少ない場合は、HTML内に直接記述することが有効とされています。逆にCSSのリソース量が多い場合でも、スクロールせずに表示される領域に関してだけ、HTML内に直接記述することで読み込み速度の改善が可能です。
Webページを快適に閲覧するためにも、スクロールせずに見えるページ範囲のコンテンツの表示に必要なデータ(HTML マークアップ、画像、CSS、JavaScript)のサイズを制限します。
WebページのレンダリングをブロックするJavaScriptをインライン化、非同期化、遅延読み込みさせることで、Webページのパフォーマンスを改善させることができます。CSSに関しても配信方法を改善することが改善が期待できるので、JavaScriptもセットで対応を検討してみてはいかがでしょうか。