こんにちは、Webエンジニアの仁木です。
Webページをユーザーに快適に閲覧してもらう為には、ページのパフォーマンスを向上することが１つの重要な課題です。
ユーザーはページの表示速度が遅かったり、操作がスムーズに開始できないといった不便さを感じると、興味を持ってアクセスしてもすぐに離脱されてしまいます。
今回はそういったページの閲覧体験を測定し改善するための「PageSpeed Insights」ツールと診断内容に応じた改善ポイントについてご紹介したいと思います。
Googleが提供しているツールで、Webページの表示速度や操作性などを測定することができます。
計測はページ単位で行え、Webに公開されているページであれば自分たちが作成したページ以外でも分析できます。
以下のURLにブラウザでアクセスします。
計測画面では最初にURLを入力し分析を開始します。
ツールがWebページに実際にアクセスして、ページのレポートを作成します。
以下は Googleのページ を測定したときのレポートです。
最初に表示されている「実際のユーザーの環境で評価する」セクションは、過去28日間にこのページを訪れた全ユーザーの閲覧環境の平均スコアです。
ユーザーの閲覧環境（ネットワーク速度や閲覧地域、端末）によってページの表示速度や応答速度は変わるため、ユーザー毎に閲覧体験は若干変わってくるのですが、ここでは平均的な指標を見ることができます。
携帯電話とデスクトップとそれぞれの端末で、５つの各指標の数値が表示されており、総合的な評価として「不合格」または「合格」といった判定が表示されます。
合格／不合格の判定でWebページのパフォーマンスに決定的な違いがあるわけではないですが、不合格の場合は何かしら改善が必要なポイントがあると考えてよいでしょう。
先ほどの評価レポートには５つの指標が表示されていました。
これらの指標が何を意味するのか見ていきましょう
Webページの中で視覚的に一番大きく表示される画像、テキスト、または動画の表示時間です。
記事ページなどでは、アイキャッチ画像などがLCPの対象となる場合が多いです。
こちらの時間は短い程パフォーマンスが良いとされ、Googleでは2.5秒以下を理想の表示時間としています。
LCPが長いということは、メインコンテンツをユーザーが閲覧できるようになるまでに時間がかかるということになり、閲覧体験が悪いということになります。
画像や動画であれば、ファイルを圧縮して軽量化したり、適切なサイズにリサイズするなど、ファイルサイズの軽減を行うことで大きく改善されることがあります。
Webページ中にあるインタラクティブな要素の反応時間です。
インタラクティブな要素は、例えばスライドのナビゲーションボタン、アコーディオンの切り替えボタン、モーダルの表示ボタンといった、ユーザーが操作して表示が変更されるUIなどが挙げられます。
こちらの時間も短い程良いとされ、Googleでは200ミリ秒以下が理想とされています。
インタラクティブな要素の反応が遅いと、ユーザーは待ち時間が発生したり、誤操作をしやすくなってしまいます。
操作したタイミングでスムーズにUIが動作するように、主にJavaScriptの処理の改善が必要です。
ページ内のコンテンツ表示の安定性に関するスコアです。
Webページはテキスト、画像、動画、広告といったコンテンツやCSSやJSといった様々なファイルを読み込んで表示されています。
これらのコンテンツやファイルは１つ１つが読み込まれるまでバラツキがあり、順番に少しづつ表示されます。
そうした時に、画像の表示にあわせてテキストがズレたり、画像の表示サイズが変更されるといったレイアウトシフトと呼ばれるコンテンツの表示がズレる事象が発生します。
このズレ具合が数値化したものが、Cumulative Layout Shiftです。
数値は０〜１の範囲で表され、０に近い程ズレが発生しておらず良いです。逆に１は非常に大きなズレが発生しておりユーザーの閲覧に大きな問題がでている可能性が高いです。
0.25以上の値になっている場合は、どこか改善が必要なズレが発生しているので対応を行うと良いです。
Webページにアクセスした時、一番最初は一瞬真っ白な表示です。
多くのページでは、一瞬でページの表示が開始されるので意識されることはありませんが、この真っ白な画面から何かしらテキストや画像、動画などのコンテンツが最初に表示されるまでにかかった時間です。
ページの表示が開始されるには、CSSやJavaScriptといったファイルの読み込みが完了する必要がありますが、この読み込みに時間がかかっているとページの表示処理がブロックされてしまい画面表示が遅くなってしまいます。
目安としては、1.8秒以下であれば良いとされ、3秒以上かかっている場合は改善が必要となります。
Webサーバーの応答時間です。
Webページを表示するには、ブラウザからWebサーバーにリクエストを出してから、Webページのデータを返してもらう必要があります。
このリクエストを出してからデータを受け取り始めるまでの時間が応答時間となります。
応答時間はWebサーバー側での処理の多さやサーバーのスペックにも依存します。
WordPressなどWebサーバー側で動作する動的システムが組み込まれているWebサイトでは、静的なWebページに比べると応答時間が長くなりやすいです。
TTFBは0.8秒以下が良いとされ、1.8秒以上かかる場合は改善が必要とされています。
動的システムが組み込まれている場合、1.8秒以上かかるケースは多くあるため、理想の時間を目指す場合は、それなりに改善の施策が必要となります。
レポートの下部には、具体的な診断内容と改善の提案があります。
赤▲の項目がパフォーマンスに特に影響している項目です。
黃■は要改善の項目です。
診断内容について具体的に見てみましょう。
画像ファイルをWebページに掲載する際に、従来のJPGやPNG形式の画像ではなく、WebPやAVIFといったより圧縮率のよい画像形式でアップロードすると良いです。
WebPやAVIFへの変換はオンラインツールなども多くあるため、比較的簡単に対応できる対策となります。
またWordPressなどのコンテンツ管理ツールから画像をアップロードしている場合は、変換プラグインを利用する方法もあります。
width と height が明示的に指定されていない画像を表示するimgタグにwidth属性とheight属性を指定し、画像の表示サイズを明示します。
これによりCumulative Layout Shiftが軽減され、ページ表示のズレが起こらなくなります。
HTMLを手動でマークアップしている場合は、alt と同様に原則的に設定しておくとよいでしょう。
JavaScript や CSS をHTML内に直接インラインで記述することでFirst Contentful Paintが改善されます。
またページの表示後に読み込んでも影響がないJavaScript や CSSは、ページが表示完了した後に、遅延読み込みする方法もあります。
上記のような改善施策は他にもありますが、気をつけるべきポイントとして、個別の改善施策は往々にしてサイトの保守性が下がるケースがあります。
例えば、CSSやJavaScriptを別ファイルで読み込まずにインラインでHTMLに記述した場合にFCPが改善されることがあります。
ただし、CSSやJavaScriptは他ページでも利用している場合、ベージ毎に記述してしまうと今後変更がでた場合にページ毎に修正が必要になります。
逆に画像や動画の軽量化は、対応しても保守性が下がらず、ページの表示速度の改善に大きく繋がりやすいため、有効な対策になります。
このようにWebページのパフォーマンスを最適化するために、保守対応にコストがかかってしまう場合もあるため、施策内容についてはコスト対パフォーマンスを意識して、有効な手段のみを選択していく必要があります。
アウラではWebページのパフォーマンス改善に最適な方法を検討し提案しています。
サイトの改善について、お困りのことがあれば、ぜひ一度お問い合わせください。
