ウェブサイトのページスピード（表示速度）は速い方が良いなんて誰しも思っていますが、ビジネスの現場ではコストなどの兼ね合いから、これまで優先度は高くありませんでした。
しかし現在は表示速度の改善が注目されており、今後は高速化対応が常識化すると考えられます。
今のインターネットで「遅いサイトは稼げない」と言い切れます。
その理由と「PageSpeed Insights」を利用した表示速度の改善方法を紹介します。
また【2019年版】PageSpeed Insights で表示速度を改善するも書きました。
ですが、こちらの2018年版がベースとして必要なので、併せてご覧ください。
目次
ページスピード（表示速度）の改善がなぜ重要か
2016年頃を境に、世界中のインターネット利用者の過半数はモバイル機器（スマートフォン等）からインターネットにアクセスしています。モバイルユーザーは以下のような特徴があります。
- 移動中などわずかなスキマ時間に利用される
- PCに比べ通信速度や通信量に制限があることが多い
- スマホアプリのサクサクとしたレスポンスに慣れている
こうしたユーザー環境や行動の変化に伴いWebマーケティングも変化しており、以下2つの点からサイトの高速化はインターネットビジネスでメリットがあります。
売上・コンバージョン率への影響
アクセスしてもなかなか表示されない重いサイトを多くの人が体験したことがあると思います。 そんな重いサイトに付き合ってくれる人はいません。
下図はGoogleによる表示速度と直帰率の関係性レポートからの抜粋です。
引用元：New Industry Benchmarks for Mobile Page Speed – Think With Google
表示速度1秒のサイトが3秒になると直帰率が32%増、5秒になると90%増という形で、表示速度の遅さと直帰率は比例します。表示速度が遅いほどお客さんはイライラして離れやすいということです。
またネット技術に詳しい人の視点だと、「サーバーチューニングする技術が無い」「サーバーなどインフラへの投資や理解が低い」と見られ、インターネットビジネスに力を入れていない、本気度が低いと感じ、信用に影響します。
「お客様を待たせている」と考えれば優先度は上がるはずです。
冒頭にも書きましたが「遅いサイトは稼げない」です。
集客・SEOへの影響
Googleは収益の多くを検索結果の広告から得ています。
その検索結果が、内容の薄いサイトや表示が遅いサイトばかりだと、ユーザーは検索結果に対してガッカリします。 「Googleは役に立たないサイトばかり挙げてくる」と思われてはGoogleの収益に響きます。 多くの人に有益な情報を快適に検索してもらうため、Googleは常に「検索体験」の改善を進めています。
そして2018年7月から、「Speed Update」が適用されます。
このアップデートで、表示速度がモバイル検索順位に影響するようになります。
スマホなどのモバイル機器からインターネットを利用するユーザーは世界の半数を超えており、通信速度や転送量に限りのあるモバイルユーザーのため、より軽量で高速なWebサイトを優遇するものと考えられます。
「うちはモバイルサイトを用意していないから関係無い」とは言えません。2018年3月に適用されたモバイルファーストインデックスと併せ、PCサイト側の影響も無視できません。
SEOの面で表示速度の重要度が以前より増し、高速化対応は常識化します。
繰り返しますが、「遅いサイトは稼げない」です。
PageSpeed Insights で調査する
PageSpeed Insights でURLを入力するだけで、現状のスピード調査と改善項目の提案をしてくれます。
まず注目すべきは以下の診断スコアです。
「ページの速度」と「最適化」の2点で評価されます。
ページの速度
表示速度がFast、Avarage、Slow の3段階で評価されます。これは Google Chrome が世界中のユーザーレポートから得たデータにより、同カテゴリのウェブサイトから見て相対的に速い・遅いという評価になります。
一定以上のPVを持つサイトでなければ評価されず「Unavailable」と表示されることも多いですが、気にしなくて問題ありません。気にすべきは次の「最適化」のスコアです。
最適化
表示速度を向上させるための最適化項目の対応状況が、100点満点のスコアで評価されます。このスコアが低いほど表示速度が遅くなる課題が残っており、対応により前者の「ページの速度」に影響します。
「ページの速度」は「最適化」を行った上での結果です。
最適化スコアがGoodと診断される80点以上を目指しましょう。
PageSpeed Insights の最適化提案に対応する
PageSpeed Insights の診断結果の少し下に「最適化についての提案」の欄があります。
ここに実施すべき項目が列挙されます。
挙げられる項目は以下10点です。
- CSS を縮小する
- HTML を縮小する
- JavaScript を縮小する
- サーバーの応答時間を短縮する
- スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する
- ブラウザのキャッシュを有効にする
- リンク先ページのリダイレクトを使用しない
- 圧縮を有効にする
- 画像を最適化する
- 表示可能コンテンツの優先順位を決定する
補足：最適化スコアが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のドキュメントを参考に対応を検討してください。
まとめ
合言葉は「遅いサイトは稼げない」です。
速度改善の作業は基本的にリファクタリングなので、提案にあたって上司やお客さんの説明が一番悩みそうですが、前半に書いた通りGoogleのアップデートによってSEOへの影響、つまりビジネスに大きく影響します。
なので改修を渋られたら「遅いサイトは稼げない」と強気に言い切って提案して良いと思います。
ただ、早くすれば稼げるというわけではなく、他のSEO手法やマーケティング活動も必須です。競合他社と同品質のサービスを提供するなら、早いほうが有利というだけです。「高速化は最低限のマーケティング事項」くらいの感覚で実施しましょう。
今回紹介した方法で調査と改善を行えば、ウェブサイトは必然的に高速化されますので、表示速度に悩んでいる方はぜひ実践してみてください。
それでは引き続き【2019年版】PageSpeed Insights で表示速度を改善するもご覧ください！
