PageSpeed Insights によるパフォーマンス測定と改善方法

公開日:
更新日:
0ハイパフォーマンスWEB

PageSpeed Insights とは

PageSpeed Insights とは Web サイトのパフォーマンス (読み込み速度) を測るためのツールです。測定はオンラインで実施できるため、ソフトウェアのインストールなどは一切必要ありません。PageSpeed Insights のページの画面中央にあるフォームに測定したい URL を入力し、"分析" ボタンをクリックするだけで簡単にパフォーマンスを測定できます。


PageSpeed Insights
PageSpeed Insights


PageSpeed Insights

PageSpeed Insights のパフォーマンス結果は 0 ~ 100 ポイントの間で評価され、スコアが高いほどパフォーマンスが高いことを示します。ただし、PageSpeed Insights のテスト内容は継続的に改良されているため、改良に伴うスコアの変化が起きる場合があります。

Web サイトパフォーマンスの重要性

Web サイトのパフォーマンスは非常に重要です。読み込み時間が短くなることで、ユーザに与えるストレスを軽減し、Google からも評価されるメリットがあります。読み込み時間が遅い場合、ページの表示を待たずにユーザが Web サイトから離脱する以下の統計データもあります。


  • サイトの表示が 0.5 秒遅くなると、検索数が 20 % 減少する。(Google)
  • サイトの表示が 0.1 秒遅くなると、売り上げが 1 % 減少し、1 秒高速化すると 10 % の売上が向上する。(Amazon)
  • サイトの表示が 1 秒遅くなると、ページビューが 11 %、コンバージョンが 7 %、顧客満足度が 16 % 低下する。(Aberdeen Group)

また、Web ユーザビリティの第一人者であるヤコブ・ニールセン博士は、"Website Response Times" で次のように述べています。


  • 0.1 秒までのなら応答が瞬時に返ってきたという印象を与える。
  • 1 秒までならユーザーの思考は途切れなく流れる。
  • 10 秒までならユーザーの注意力は続く。
  • 10 秒以上遅延してしまうと、ユーザーが即、サイトから離れてしまうことも多くなる。

上記の評価は、非常に甘いと言えます。実際にユーザは余程有益なことが書かれていない限り、ページが表示されるまで 10 秒も待ってはくれません。せいぜい 2 ~ 3 秒程度です。それほどまでにユーザは急いでおり、ユーザの問題を解決する Web サイトは無数にあるため、遅い Web サイトには誰もやってこなくなります。

PageSpeed Insights の測定結果

測定結果のページには大きく分けて 3 種類の結果が表示されます。赤色の感嘆符で表示される "修正が必要な問題点"。黄色の感嘆符で表示される "修正を考慮する問題点"。最後に、緑色のチェックマークで表示される "ルールに合格した項目" です。下記は、Yahoo!Japan を例にサイトパフォーマンスを測定した結果画面です。

測定結果のページに表示される優先度インジケータ
アイコン説明
赤色の感嘆符この問題を修正すると、ページのパフォーマンスが大幅に改善されます。
黄色の感嘆符それほど忙しくない場合はこの問題の修正を検討してください。
緑色のチェックマーク大きな問題は見つかりません。パフォーマンスは良好です。


PageSpeed Insights の測定結果
PageSpeed Insights の測定結果


Web サイトの修正を行う場合、赤色の感嘆符の問題点から着手しましょう。修正が難しい場合は、黄色の感嘆符の修正を検討して下さい。次章からは、具体的な修正手順について説明します。

HTML・CSS・Javascript を縮小化する

この問題は、HTML や CSS などのリソースが "縮小化 (minify)" できる場合に検知されます。縮小化 (minify) とは、ブラウザで表示する際に関係のないスペース、改行、タブなどの不要なバイトを取り除くことです。不要なバイトを取り除くことで、ファイルサイズが小さくなり、ページの読み込み、解析、レンダリングの速度を向上させることができます。以下は、HTML を縮小化した例になります。


<html>
  <head>
    <link rel="stylesheet" href="style.css">
  </head>
  <body>
    <div>
      Hello, world!
    </div>
  </body>
</html>
 縮小化する前の HTML 例
<html><head><link rel="stylesheet" href="style.css"></head><body><div>Hello, world!</div></body></html>
 縮小化した後の HTML 例

ただし、スペースや改行は、編集を行う上では重要な要素であり、公開しているオリジナルのページをそのまま縮小化すると、今後の修正やリニューアルが非常に困難になります。そのため、"縮小化前のオリジナルページ" と、"縮小化後の公開するページ" を分けて管理すると良いでしょう。本サイトでは非公開の場所でオリジナルのページを作成し、公開用のページに縮小化したリソースを配置しています。


縮小化はツールを使うと簡単で効率的です。 YUI CompressorClosure CompilerJSMin など、HTML、CSS、Javascript を縮小化するツールはいくつもあります。また、PageSpeed Insights を含めたパフォーマンス測定サイトの結果ページから、縮小化されたリソースをダウンロードすることもできます。


ページ更新後の作業が 1 つ増えることになるため、多くのサイトでは縮小化が行われていません。しかし、縮小化を行うことによりデザインを損なわず、ファイルサイズが数 % 削減できるため、修正を検討する価値はあります。特にファイルサイズが大きなページや、回遊率が高い Web サイトは積極的に縮小化を行いましょう。ただし、記事数が膨大にある大規模なサイトでは、ページを 1 つずつ縮小化することは現実的ではないため、何かしらのスクリプトにより実施することを推奨します。


リソース (HTML、CSS、JavaScript) を圧縮する

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

この問題は、サーバからの応答時間が 0.2 秒以上である場合に検知されます。この問題が発生する原因は、様々な理由が考えられるため、解決は容易ではありません。まずは、パフォーマンスに対するボトルネックがどこにあるのかを調査する必要があります。


ボトルネックの原因が、処理ロジック (例えば、遅いデータベースクエリや、ルーティングなど) に起因する場合は、どこにボトルネックがあるのかデータを収集して調査を行う必要があります。パフォーマンス上のボトルネックが特定できた場合は、デグレードしないように注意して修正を行います。


ボトルネックの原因が、サーバの性能 (例えば、CPU処理能力が低い場合や、メモリの容量不足など) に起因する場合は、解決はより困難になります。特にレンタルサーバーを利用している場合は、他社への乗り換えも検討する必要があります。VPS の仮想化環境を利用している場合は、プランの変更を検討する必要があります。


サーバーの応答時間を改善する

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

この問題は、表示されるページのスクロールせずに見える範囲に外部の CSS ファイル、および javascript ファイルを参照している場合に検知されます。例えば、画面上部に表示される共通メニューや、パンくずリストを外部の javascript ファイルで書き出している場合です。


スクロールせずに見える範囲に外部ファイルを参照している場合は、インライン化、または静的 HTML に置き換えることでこの問題を回避できます。以下の例では、スクロールせずに見える範囲に外部ファイルを参照しています。


<html>
  <head>
    <link rel="stylesheet" href="style.css">
    <script src="script.js">
  </head>
  <body>
    <div>
      Hello, world!
    </div>
  </body>
</html>
 スクロールせずに見える範囲で外部ファイルを参照している例

上記の外部ファイルをインライン化した例は以下のようになります。


<html>
  <head>
    <style>
      div{color:blue;}
    </style>
    <script>
      /* JavaScript file */
    </script>
  </head>
  <body>
    <div>
      Hello, world!
    </div>
  </body>
</html>
 外部ファイルをインライン化した例

javascript がページの読み込みを妨げないようにするために、非同期読み込みを行う方法もあります。以下のように script タグに async 属性を使用します。この方法は、Google も推奨している方法です。


<script async src="script.js">
 script タグに async 属性を付与した例

ただし、javascript 内で document.write を使用している場合は、非同期の読み込みをブロックしてしまうため、安全に使用できません。後続の処理に不具合を起こす可能性があります。document.write を使用している場合は、別の方法を使用するように書き直しましょう。一般的に document.write を代替する場合は、document.getElementById("[id名]").innerHTML が使われます。


CSS の配信を最適化する
レンダリングを妨げる JavaScript を削除する

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

この問題は、表示されるページのスクロールせずに見える範囲に追加のネットワーク往復が必要な場合に検知されます。


この問題は、前章の "スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する" と密接な関係があります。追加のネットワーク往復とは、外部ファイルを読み込むトラフィックに起因する場合が多いため、前章の問題を解決すると、この問題も解決される場合があります。Google では、スクロールせずに見える部分はインライン化し、それ以降の部分は外部ファイルとして分割するように提案しています。


しかし、新規に作成する Web サイトでもない限り、Google の提案を実行するには大規模な改修が必要になります。そのため、力技になりますが、手っ取り早い解決方法としては、すべてインライン化、および静的 HTML に置き換えることで問題を回避できます。


ただし、CSS も javascript も複数ページの共通コンポーネント化を目的としているため、インライン化すると何かを修正した場合、すべてのページに影響を与えます。そのため、この問題について修正を行う場合は、慎重な検討が必要になります。本サイトでは、CSS のインライン化や、javascript を静的 HTML に置き換えるスクリプトを用意し、簡易的なデプロイツールを作ることで、上記の問題点を回避しています。


スクロールせずに見える範囲のコンテンツのサイズを削減する

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

この問題は、特定の URL から最終的なリンク先のページが表示されるまでにリダイレクトが複数ある場合に検知されます。


リダイレクトが行われると追加の HTTP リクエストとレスポンスが発生します。そのため、リダイレクトの数は最小限に抑えることが重要になります。リダイレクトする例としては、デバイスによってモバイル版サイトと、PC 版サイトで振り分けるケースがあります。しかし、現在ではレスポンシブデザインが主流となりつつあるため、リダイレクトによる振り分けは特に必要なくなっています。


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

圧縮を有効にする

この問題は、圧縮可能なリソースが HTTP 圧縮されていない場合に検知されます。


多くの Web サーバでは、モジュールを呼び出すか、組み込みのルーチンを使用すると、ファイルをダウンロード用に送信する前に gzip 形式で圧縮できます。Apache の mod_deflate を使った圧縮方法についての詳細は、"gzip 圧縮によるサイトパフォーマンスを向上させる方法" を参照して下さい。


圧縮を有効にする

画像を最適化する

この問題は、ページ上の画像のサイズが不適切な場合や、最適な画像フォーマットが使用されていない場合や、品質に大きな影響を与えずにサイズを削減できる場合に検知されます。例えば、高解像度のデバイスに合わせて 2 倍の解像度の画像を設置していたり、JPEG や PNG ファイルのロスレス圧縮がされていない場合などです。


画像にもよりますが、ロスレス圧縮では人間の視覚的に大幅な影響を与えずに 60 ~ 70 % 程度の圧縮が可能です。画像の圧縮はオンライン上で行うことができます。また、PageSpeed Insights を含めたパフォーマンス測定サイトの結果ページから、圧縮されたリソースをダウンロードすることもできます。


画像を最適化する

ブラウザのキャッシュを活用する

この問題は、サーバからのレスポンスにキャッシュヘッダが含まれていない場合や、リソースが短時間でキャッシュされる設定がされている場合に検知されます。


静的なリソースをキャッシュすると、次回以降にアクセスした場合、高速な処理が実現できます。キャッシュについての詳細は、"ブラウザのキャッシュよるサイトパフォーマンスを向上させる方法" を参照して下さい。


ただし、Google アナリティクスのコードを head 内に記述している場合、この問題点は回避できません。


ブラウザのキャッシュを活用する

PageSpeed Insights の最終測定結果

すべての問題 (Google アナリティクスを除く) に対して修正を行うと、最終的なスコアはモバイル・ブラウザともに 99 点まで上がります。Google アナリティクスのリソースである analytics.js のブラウザキャッシュ時間は 2 時間に設定されていますが、この値を変更することはできません。そのため、最高スコアは 99 点になります。


PageSpeed Insights の測定結果
PageSpeed Insights の最終測定結果


実際には Web サイトの構造や改修規模により最高スコアを目指すことは難しいかもしれません。しかし、パフォーマンスを上げるために何かしらのチューニングが施せる場合は、修正を検討してみて下さい。

まとめ

Web サイトのパフォーマンスの向上は、ユーザビリティの向上に大きく寄与します。ただし、PageSpeed Insights で検知された問題の中には改修が非常に難しいものも含まれます。無理に修正をすることだけを考えずに、サイトを運用していく上でのメンテナンス性も併せて考慮しましょう。