PageSpeed Insights で表示速度を改善する

ウェブサイトのページスピード(表示速度)は速い方が良いなんて誰しも思っていますが、ビジネスの現場ではコストなどの兼ね合いから、これまで優先度は高くありませんでした。

しかし現在は表示速度の改善が以前より注目が高まっており、今後は高速化対応が常識化すると考えられます。 その理由と「PageSpeed Insights」を利用した表示速度の改善方法を紹介します。

目次

 

ページスピード(表示速度)の改善がなぜ重要か

2016年頃を境に、世界中のインターネット利用者の過半数はモバイル機器(スマートフォン等)からインターネットにアクセスしています。モバイルユーザーは以下のような特徴があります。

  • 移動中などわずかなスキマ時間に利用される
  • PCに比べ通信速度や通信量に制限があることが多い
  • スマホアプリのサクサクとしたレスポンスに慣れている

こうしたユーザー環境や行動の変化に伴いWebマーケティングも変化しており、以下2つの点からサイトの高速化はインターネットビジネスでメリットがあります。

 

売上・コンバージョン率への影響

アクセスしてもなかなか表示されない重いサイトを多くの人が体験したことがあると思います。 そんな重いサイトに付き合ってくれる人は多くありません。

下図はGoogleによる表示速度と直帰率の関係性レポートからの抜粋です。


Find out how you stack up to new industry benchmarks for mobile page speed

表示速度1秒のサイトが3秒になると直帰率が32%増、5秒になると90%増という形で、表示速度と直帰率は比例関係にあります。

遅くイライラさせるユーザー体験(UX)の低いサイトはお客さんに避けられます。 インターネットに詳しい人の視点だと、遅いサイトは技術的に劣っていたり、インフラへの投資や理解が低くWebに力を入れていないなと感じ、信用性にも影響します。

「お客様を待たせている」と考えれば優先度は上がるはずです。
ユーザーが得る体験や印象を高めるために表示速度は重要です。

 

集客・SEOへの影響

Googleは収益の多くを検索結果の広告から得ています。

その検索結果が、内容の薄いサイトや表示が遅いサイトばかりだと、ユーザーは検索結果に対してガッカリします。 「Googleは役に立たないサイトばかり挙げてくる」と思われてはGoogleの収益に響きます。 多くの人に有益な情報を快適に検索してもらうため、Googleは常に検索体験の改善を進めています。

そして2018年7月から、「Speed Update」が適用されます。

このアップデートで、表示速度がモバイル検索順位に影響するようになります。

スマホなどのモバイル機器からインターネットを利用するユーザーは世界の半数を超えており、通信速度や転送量に限りのあるモバイルユーザーのため、より軽量で高速なWebサイトを優遇するものと考えられます。

「うちはモバイルサイトを用意していないから関係無い」とは言えません。2018年3月に適用されたモバイルファーストインデックスと併せ、PCサイト側の影響も無視できません。

SEOの面で表示速度の重要度が以前より増し、高速化対応は常識化すると考えられます。

 

PageSpeed Insights で調査する

PageSpeed Insights でURLを入力するだけで、現状のスピード調査と改善項目の提案をしてくれます。

PageSpeed Insights

まず注目すべきは以下の診断スコアです。
ページの速度」と「最適化」の2点で評価されます。

ページの速度

表示速度がFast、Avarage、Slow の3段階で評価されます。これは Google Chrome が世界中のユーザーレポートから得たデータにより、同カテゴリのウェブサイトから見て相対的に速い・遅いという評価になります。

一定以上のPVを持つサイトでなければ評価されず「Unavailable」と表示されることも多いですが、気にしなくて問題ありません。気にすべきは次の「最適化」のスコアです。

最適化

表示速度を向上させるための最適化項目の対応状況が、100点満点のスコアで評価されます。このスコアが低いほど表示速度が遅くなる課題が残っており、対応により前者の「ページの速度」に影響します。

「ページの速度」は「最適化」を行った上での結果です。
最適化スコアがGoodと診断される80点以上を目指しましょう。

 

PageSpeed Insights の最適化提案に対応する

PageSpeed Insights の診断結果の少し下に「最適化についての提案」の欄があります。
ここに実施すべき項目が列挙されます。

挙げられる項目は以下10点です。

補足:最適化スコアが80点以上だった場合

80点以上からスコアをさらに伸ばそうとしても、労力に対して得られる改善効果のコストパフォーマンスが低くなるので、簡単に出来るもの以外での改善施策はお勧めしません。解析など何らかの仕組みを入れているコーポレートサイトでは、最適化スコアを100点にすることはほぼ出来ません。90点に届けば上出来です。

最適化スコアが高くても実測の表示速度が遅い場合、ウェブサイトの仕組み・アクセス状況に対しサーバー性能が低い可能性があります。サーバーから見直すことで改善が見込めます。

 

CSS/HTML/JavaScript を縮小する

ウェブサイトの表示を構成するソースコードの圧縮が必要です。
ソースコードの種類は違いますが、求められる対応は同じです。

ソースコードは通常、以下のように人が読みやすいよう適切にホワイトスペース(改行やスペース)やコメントが入れられます。

<html>
  <head>
    <title>サイトタイトル</title>
    <meta name="description" content="ほげほげ" />
  </head>
  <body>
    <h1>サイトタイトル</h1>
    <!-- コメント -->
  </body>
</html>

しかしホワイトスペースもデータ量に含まれるので、以下のようにホワイトスペースとコメントを除去してデータ量を削減します。

<html><head><title>サイトタイトル<title><meta name="description" content="ほげほげ" /></head><body><h1>サイトタイトル></body></html>

こうしてソースコードを縮小化することをMinify(ミニファイ)と呼びます。

しかしMinifyするとソースコードが読みにくくなるので、開発用のコードを公開用のコードにMinify出力する方法が一般的です。

 

サーバーの応答時間を短縮する

ウェブサイトに訪問者がアクセスしてからサーバーが応答するまでの時間が遅いと指摘されます。
PageSpeed Insights では200ミリ秒(0.2秒)以上あると「遅い」と判断されます。

「表示速度」と「応答時間」は似ているようで異なります。

表示速度ウェブサイトの文字や画像などのコンテンツが一通り表示されるまでの時間。
人の動きに例えると、電話を取って会話を終え受話器を置くまでの時間。
応答時間アクセスされ表示処理を開始するまでの時間。
人の動きに例えると、電話の受話器を取るまでの時間。

表示速度の中の最初に応答時間が含まれます。

サーバースペック、サーバーOSの種類、利用ミドルウェアの種類や設定、バージョンなどなど… 環境や状況によってチェックすべき要素が多岐に渡り、サーバーエンジニアがボトルネックを監視し一つ一つ調整するしかなく、「これさえやればOK!」という明確な答えはありません。

またサーバー管理権限の無い一般的な共用ホスティングサービスでは手を入れられません。
サーバーの管理権限とエンジニア対応が必要ですが、影響も大きい項目です。

下記Googleのドキュメントをもとに対応を検討してください。

 

スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する

レンダリングブロック」という現象が発生している指摘です。

JavaScriptやCSSは、HTMLの<head>タグ内で読み込まれることが一般的に多くあります。

ウェブページを見るためのMicrosoft EdgeやGoogle Chromeといったウェブブラウザは、<head>タグ内で指定されたJavaScriptやCSSのファイルなど、すべての外部ファイルの読み込みを完了するまで<body>タグ以下の内容を描画しません。

<head>タグ内のファイル読み込みにより描画(レンダリング)が止められているため「レンダリングブロック」と呼ばれます。 一つ一つの読み込み時間は0.1秒未満の一瞬ですが、積み重なれば表示が遅くなります。

主な対応は<head>内で読み込んでいるファイルを<body>内に移動させることですが、単純にすべて移動してしまうとデザイン崩れやスクリプトエラーなどの不具合の原因になります。

デザイナーとエンジニア双方で連携し、下記Googleのドキュメントも参考に改善しましょう。

補足:レンダリングブロックは2〜3件残っても良い

レンダリングブロックを0件まで対応しきることはお勧めしません。0件まで潰すにはフロントエンドの高度な工夫が必要で、労力に対する改善効果のコストパフォーマンスが低いためです。2〜3件残っていても速度への影響は軽微なので、見切りをつけて対応しましょう。

 

ブラウザのキャッシュを有効にする

ブラウザキャッシュを取るサーバー設定が必要です。
一度アクセスしたユーザーにコンテンツのキャッシュを取ってもらうことで、二度目以降の表示が高速化します。

.htaccess に以下のような記述を加えることで設定できます。

<ifModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 1 seconds"
  ExpiresByType text/html "access plus 7 days"
  ExpiresByType text/css "access plus 7 days"
  ExpiresByType text/js "access plus 7 days"
  ExpiresByType text/javascript "access plus 7 days"
  ExpiresByType image/png "access plus 7 days"
  ExpiresByType image/jpg "access plus 7 days"
  ExpiresByType image/jpeg "access plus 7 days"
  ExpiresByType image/gif "access plus 7 days"
  ExpiresByType image/x-icon "access plus 7 days"
  ExpiresByType application/javascript "access plus 7 days"
  ExpiresByType application/x-javascript "access plus 7 days"
  ExpiresByType application/x-font-ttf "access plus 7 days"
  ExpiresByType application/x-font-woff "access plus 7 days"
</ifModule>

上記例は各種ファイルを7日間キャッシュを残すようにしています。

頻繁な更新があるサイトや、ユーザー参加型のサイトではキャッシュ期間が長いと古い内容が表示され、最新の状況が見えないなど不都合もあるので、サイトの状態に応じて設定を検討してください。

 

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

対象のURLへアクセスすると、最終的なURLへ複数回リダイレクトされる場合に指摘されます。
リダイレクトの数だけ余計な通信が発生し遅くなるためです。

以下のようにPC用サイトとモバイル用サイトを別URLで分けているケースなどで指摘されます。

https://www.example.com/  (PC用サイト : スマホでこちらにアクセスしたらモバイル用URLにリダイレクトする)
https://m.example.com/    (モバイル用サイト : PCでこちらにアクセスしたらPC用URLにリダイレクトする)

PC用サイトとスマホ用サイトのHTMLとコンテンツを、同一ソースで提供するレスポンシブデザインで構成すると余分なリダイレクトが必要無くなるので、下記Googleのドキュメントも参考に対応を検討してください。

 

圧縮を有効にする

WebサーバーからWebサイトコンテンツをgzip圧縮し軽量化した状態で配信するよう、Webサーバーの設定で対応します。

.htaccess に以下のような記述を加えることで設定できます。

<IfModule mod_deflate.c>
  SetOutputFilter DEFLATE
  SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/xml
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/js
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/atom_xml
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE application/x-httpd-php
  AddOutputFilterByType DEFLATE application/x-font-ttf
  AddOutputFilterByType DEFLATE application/x-font-woff
  AddOutputFilterByType DEFLATE application/x-font-opentype
</IfModule>

 

画像を最適化する

画像のファイルサイズを削減します。
単純に画像サイズを削減するなら以下のサービスがオススメです。

レスポンシブデザインの画像最適化表示

PC用サイトとスマホ用サイトでURLを分けず同一のコンテンツを表示し、CSSだけでディスプレイサイズを判別してレイアウトを分ける手法を「レスポンシブデザイン」と呼びます。

レスポンシブデザインではPCもスマホも同一の画像を表示するのですが、iPhoneのRetinaディスプレイのように解像度の高いスマホでは、PCと同じサイズの画像を使うとボケて見えます。そのためスマホ表示では、表示サイズに対し実体サイズが倍の画像を使うテクニックが一般化しています。(100×100の表示幅に対し、200×200の画像を使うなど)

しかしPC表示の時も巨大な画像を使うことになるので、無駄な読み込み時間がかかってしまうデメリットがあります。そこでHTML5のsrcset属性を使えば解像度に応じた画像をブラウザ側が判別して表示してくれます。

<img src="img/example.png" srcset="img/example.png 1x, img/example@2x.png 2x">

上記<img>タグの例では、srcset属性で2つの画像を設定しています。

一般的な解像度のディスプレイなら 1x で指定された画像が表示され、Retinaディスプレイのような高解像度ディスプレイでは 2x で指定された画像が表示されます。

srcsetに対応していないブラウザでは従来のsrcが適用されます。

 

表示可能コンテンツの優先順位を決定する

ページの最初に表示されるコンテンツのデータ量が多すぎると指摘されます。
最初に表示されるコンテンツを優先して読み込み、それ以外は非同期で読み込むなどの工夫が必要です。

下記Googleのドキュメントを参考に対応を検討してください。

 

まとめ

PageSpeed Insights を使った調査と高速化の対応は以上になります。提案項目を潰していけばウェブサイトは必然的に高速化されますので、表示速度に悩んでいる方はぜひ実践してみてください。

やること自体はリファクタリングなので、実施提案にあたり上司やお客さんの説明が一番悩みそうですが、前半に書いた通りGoogleのアップデートによってインターネットビジネスに大きく影響しますので、「遅いサイトは稼げない」ぐらい強気に言い切って提案するのも良いと思います。

AWSを利用した導入事例のご紹介

実際に構築を行ったAWSの事例を紹介しています。導入の目的に近い事例をご覧いただくと、実際の構成例やメリット、注意点などが把握できます。

ブックオフコーポレーション株式会社様
第一生命保険株式会社様
株式会社電通様
株式会社LIFULL様
株式会社リブセンス様
TBSアナウンス部様
明治大学様
拓殖大学様