スマホでのWebサイトの閲覧が多数を締める現在、ページの表示スピードがページを見る人に取って重要な要素となりました。
Googleによると、モバイルサイトの読み込みに3秒以上かかると、53％がサイトから離脱されるそうです。
SEOの観点からも大きな影響はないにせよ、サイトの評価にも関わると言います。
（引用：Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed）
それほど重要視されているページのスピードですが、GoogleはWeb開発者のためにページのスピードを計測して、改善箇所を指摘するツールを公開しています。
そのツールが『Page Speed Insights』です。
このブログではこのツールを使って、ページのスピードを改善してみました。
結果的に、ツールのスコアが91点から98点に改善しました。
ツールの使い方から、改善箇所の確認、改善した内容まで書いていますので、ぜひご覧ください。
Contents
Google『Page Speed Insights』でページの表示速度、改善点をチェック
こちらのページの上部にある「ウェブページのURLを入力」と記載されているフォームにスピードを計測したいページのURLを入力して、ページをチェックします。
実際に制作したページをチェック
直近で制作した以下のページでスピードのテストをしてみました。
結果は「91点」（スマホ）でした。
評価としては点数の下にある表示ではグリーンですが、改善する余地があるようです。
何度か計測してみたところ、計測するごとに多少の誤差（３〜４点）がありました。
閲覧しているネットの通信環境などが影響しているのかもしれません。
ちなみにこの点数は「パフォーマンススコア」と呼ばれ、点数の下に表示されている６つの指標を加重平均した値とのことです。※1
（「加重平均」とは、私たちが日常で使用している「平均値を求める」と同じ意味で、指標を全て足し算した後に指標の数で割る、といった流れで求められます。）
※1 引用元：Lighthouse performance scoring
ポイントに大きく影響される指標
上記の「Lighthouse performance scoring」によると、ポイントに大きく影響を与える指標は２つあり、「トータルブロッキングタイム（TBT）」と「ラージェストコンテントフルペイント(LCP)」です。
トータルブロッキングタイムは今回の例で言えば、上記画像中のスマホ版画面の下に表示されている指標の上から2番目に表示されています。
ラージェストコンテントフルペイントは点数が表示されている左側の一番下に表示されています。
トータルブロッキングタイム指標について
こちらのページにトータルブロッキングタイムの詳しい説明がありますが、以下に引用します。
（読みやすいように改行を入れています。）
TBTは、マウスのクリック、画面のタップ、キーボードの押下などのユーザーの入力に対して、ページが反応しないようにブロックされている時間の合計を測定します。
この合計は、「First Contentful Paint」と「Time to Interactive」の間にあるすべての長いタスクのブロック部分を加算して計算されます。
50msを超えて実行されるタスクはすべてロングタスクです。
50ms以降の時間がブロッキング部分となります。
例えば、Lighthouseが70msの長いタスクを検出した場合、ブロッキング部分は20msとなります。
難しい言い回しですが、こちらはひとまず50msよりも短ければ問題ないようです。
ちなみに、この指標の評価が低い場合の改善は、具体的ではないのですが 公式ページで解説されています。
主にスクリプトの読み込みタイミングと実行のタイミングの調整を促しています。
ただ、具体的な改善点に関しては指標のスコアの下に指摘があるのでそちらを見てから改善しましょう。
ラージェストコンテントフルペイント指標について
こちらもTBTと同じく、公式の解説ページから引用します。
Largest Contentful Paint (最大視覚コンテンツの表示時間、LCP) は、知覚される読み込み速度を測定するための重要なユーザーを中心とした指標です。
これは、LCP がページの読み込みタイムラインにおいてページのメインコンテンツが読み込まれたと思われる時点を示すためです。
LCP を高速にすることで、そのページが便利であることをユーザーに強く印象付けることができるようになります。
どうやらGoogleは、ページのメインコンテンツをHTMLの記述から読んでいるようですが、メインコンテンツと判断された要素が読み込み完了するまでの時間を指標としているようです。（おそらく、通常ページの最後にあるフッターの直前のコンテンツ領域を指しているのだと思います。）
今回のページでは赤い数字で表示されていて、改善が必要な箇所と評価されました。
改善はこの箇所を中心に行うこととします。
指標の意味からすると「コンテンツ領域にある要素で、読み込みに時間がかかる箇所」と推定できますが、主に画像だと考えられます。
Webページで読み込みに時間がかかる要素は動画や音声、画像などいくつかありますが、動画や音声は今回のページでは使用していないため、画像である可能性が高いです。
具体的な改善内容
改善内容はスコア下の以下に表示されています。
画像の中に「改善できる項目」と「診断」がありますが、「改善できる項目」に対応すれば問題ありません。
「改善できる項目」を一つずつ見ていきましょう。
次世代フォーマットでの画像の配信
画像を次世代フォーマットのWebPやAVIFに置き換えるような指示内容です。
ただし、次世代フォーマットに対応していないWebブラウザもあるので焦って導入する必要はないように思います。
先ほどの「LCP」の内容を踏まえて考えると画像フォーマットの形式の問題ではなく、画像の容量を抑えれば良いということでしょう。
効率的な画像フォーマット
こちらは画像の最適化（＝軽量化）の指摘です。
レンダリングを妨げるリソースの除外
ページを開いてWebブラウザが画面を描画するまでの時間で妨げになっている外部ファイルがリストアップされています。ここの指摘によると、重要なCSSやJavaScriptはインライン（ページのHTMLソース内）で記述することを推奨しています。
今回のページだと、ページのスタイルを記述しているメインのCSSと、使用していなかったJavaScriptが記載されていました。
メインのCSSは管理上の都合から一旦対応しないことにして、使用していなかったJavaScriptは削除することにしました。（本気でページのスピードを上げる必要があれば、CSSもインラインで記述しますが、今回はそこまで求められていないので見送ります。）
適切なサイズの画像
画面よりも大きく作っている画像に関して指摘されています。
診断の内容
改善できる項目の下の「診断」の箇所ですが、スコアには直接影響しないと記載されています。
「直接」という記述が気になりますが、それによってユーザーのページでの体験の質が下がって、悪い印象を持ってしまう可能性がある、という意味でしょう。
（私見ですが、Googleアナリティクスを入れているページでユーザーの離脱が多いなどの現象があって、診断項目の指摘が悪い場合はスコアに影響するかもしれません。）
画像要素で width と height が明示的に指定されていない
レスポンシブWebデザインでページを作っているので、画像のサイズをimgタグで指定するのはいかがなものなのか？
imgタグでサイズを指定しつつ、CSSで柔軟にサイズが変わるように指定するとか？
こちら公式ページに改善方法が解説されていました。
長いので記事では割愛しますが、かなり技術的なことが詳しく説明されているので非常に参考になると思います。
参考：Cumulative Layout Shift を最適化する
静的なアセットと効率的なキャッシュ ポリシーの配信
キャッシュの有効期間を長くして再訪問したユーザーのページ表示を早くすることを推奨しています。
キャッシュの設定はサーバー内に配置するファイルの設定を行う「.htaccess」ファイルで設定します。
今回の例は広告用のランディングページなので重要度は低いのですが、ユーザーが何度か訪問することが想定されるWebサイトでは設定した方が良いですね。
First Contentful Paint (3G)
唐突に英語ですが、３Gネットワーク上で初めてテキストや画像が表示されるまでの時間です。
スコア下に同じ名前の指標「First Contentful Paint」がありますが、この３Gネットワーク版ということです。
3G回線が遅いことを前提としているので、画像の軽量化など「改善できる項目」で指摘されている箇所を改善すれば、自然と改善すると思います。
メインスレッド処理の最小化
「JavaScriptの解析、コンパイル、実行にかかる時間を短縮することをご検討ください。JavaScript ペイロードのサイズを抑えるなどの方法があります。」とあり、先に説明した「トータルブロッキングタイム」の解説ペジへリンクが張ってあります。
具体的な改善としては、CSSやJavaScriptなどの記述の改行やコメントなどの動作とは関係のない記述を削除して、データの読み込みを早くすることです。
クリティカル リクエスト チェーンを回避してください
これもデータの読み込みを妨げている（遅くしている）ファイルの削除や、ソースの記述の最小化の推奨です。
リクエスト数を少なく、転送サイズを小さく維持してください
ページに使用するファイルの数を減らすことを推奨しています。
「最大コンテンツの描画」要素
「ビューポート内で描画された最大のコンテンツ要素です。」と記載されていて、ものすごく幅が狭く縦長の画面でページを表示した場合のキャプチャとともに、ファーストビューのHTMLソースが指摘されていました。
スマホでの表示時にファーストビューを画面の高さいっぱいに広げているので、それが指摘されているようです。
特に修正を促す内容は書かれていないのですが、大きいサイズの要素は何かマイナス要素になるのか気になるところです。
レイアウトが大きく変わらないようにする
PCとスマホでレイアウトが大きく変わる要素に対して指摘しています。
それがひどいとユーザーの体験が悪化する可能性がある、との指摘です。
メインスレッドでタスクが長時間実行されないようにしてください
ページ中で使用されているJavaScriptに関して記載がありました。
Page Speed Insights「改善できる項目」の改善結果
先ほどの採点で指摘されていた改善できる箇所を改善したところ、91点が98点になりました！
自分のやった対応がしっかり結果に反映されると気持ちがいいものですね。
改善した箇所
改善した箇所は以下です。
- 「次世代フォーマットでの画像の配信」で指摘されていた画像の軽量化。20点ほど。
- 「レンダリングを妨げるリソースの除外」で指摘されていた、使用していないJavaScriptの削除。
- 「メインスレッド処理の最小化」で指摘されていた、headタグ内のJavaScriptをbody終了タグ直前に移動。
上記３つを改善しましたが、一番影響が大きいのはやはり画像の軽量化のようです。
ページの表示スピードを上げるには要素を軽くするのが必須ですが、ページの要素で容量が大きいのは画像なので当然の結果だと感じます。
意外性はないですが、こういった地味な作業を地道にしていくことでGoogleのページの評価も上がっていくのではないでしょうか。
これがWebサイト全体のスピード改善だと大変
今回はランディングページをサンプルに改善をしましたが、Webサイトが改善の対象となった時の作業はかなり大変になりそうです。
だから、Webサイトを制作する際にしっかり表示スピードを意識しておくことが重要ですね。
もし自社のWebサイトの表示スピードが「遅いな・・・」と感じたらご相談ください。
原因の調査から修正の対応までいたします！
ぜひお気軽にお問い合わせフォームからお問い合わせください。
