PageSpeed Insights でのモバイル解析

PageSpeed Insights は、ページを解析し、モバイル ネットワークで 1 秒未満でページがレンダリングされるようにする場合の推奨事項にそのページが準拠しているかどうかを確認します。調査によれば、1 秒を超える遅延があるとユーザーの思考の流れが中断し、ユーザー エクスペリエンスが低下します。Google では、デバイスやネットワークの種類に関わらず、ユーザーのページへの関心を持続させ、最適なエクスペリエンスを提供することを目標としています。

1 秒という時間の制約を満たすのは簡単ではありませんが、この時間内にページ全体をレンダリングする必要はありません。代わりに、スクロールせずに見える(ATF)コンテンツを 1 秒未満で配信しレンダリングします。こうすることで、ユーザーは可能な限り早くページを利用し始めることができます。続いて、ユーザーがコンテンツの最初のページを読み進める間に残りのページをバックグラウンドで徐々に配信できます。

待ち時間の長いモバイル ネットワークへの適応

携帯端末で ATF に関する 1 秒基準を満たすには、他のネットワークでは発生しない特有の課題が伴います。ユーザーは多種多様な 2G、3G、4G ネットワークを通じてサイトにアクセスする可能性があります。以下のように、ネットワークの待ち時間は有線接続に比べて大幅に長く、ATF コンテンツのレンダリングに 1,000 ミリ秒のうちの大部分を消費します:

  • 3G ネットワークでは 200~300 ミリ秒の往復時間
  • 4G ネットワークでは 50~100 ミリ秒の往復時間

3G は世界中で主流となっているネットワークの種類です。4G の導入は世界中で進んでいますが、まだユーザーの大多数は 3G ネットワークでページにアクセスすると考えられます。そのため、各ネットワーク リクエストには平均して 200 ミリ秒かかると想定する必要があります。

その点を考慮して、再度 1 秒基準について考えてみましょう。標準的なブラウザとサーバー間の一連の通信を見ると、この時間のうち既に 600 ミリ秒が、IP アドレスに対するホスト名(google.com など)を解決するための DNS ルックアップ、TCP ハンドシェイクを実行するためのネットワークの往復、最後に HTTP リクエストを送信するためのネットワークの往復全体といったネットワークのオーバーヘッドに費やされています。これで残りはたった 400 ミリ秒になります。

1 秒未満のレンダリングの実現

ネットワークの待ち時間を差し引くと残りの時間はたった 400 ミリ秒ですが、やるべきことはまだたくさんあります。サーバーでの応答のレンダリング、クライアント サイドのアプリケーション コードの実行、ブラウザでのコンテンツのレイアウトとレンダリングなどです。この点を考慮すると、次の基準を満たせば 1 秒未満のレンダリングを実現できることになります:

(1)サーバーは応答をレンダリングする必要がある(200 ミリ秒未満)
サーバーの応答時間とは、サーバーが最初の HTML を返すまでの時間からネットワークの転送時間を引いた時間です。残された時間は少ないため、この時間は最小限に抑える必要があります。理想的なのは 200 ミリ秒以内ですが、できればさらに短い方がよいでしょう。
(2)リダイレクト数を最小限に抑える
HTTP リダイレクトが増えると、余分なネットワークの往復が 1 回または 2 回(余分な DNS ルックアップが必要な場合は 2 回)追加され、3G ネットワークでは数百ミリ秒の余分な遅延が発生することになります。そのため Google では、リダイレクトの数を最小限にすること、理想的にはリダイレクトを完全になくすことをウェブマスターに強くすすめています。これは、HTML ドキュメントでは特に重要です(可能な場合は、「m.」によるリダイレクトを避けてください)。
(3)最初のレンダリングまでの往復数は最小限に抑える

TCP が通信量を見積もる手法(TCP スロー スタート)により、新しい TCP 接続ではクライアントとサーバー間で利用可能な帯域幅すべてをすぐに使用することはできません。このため、最初の往復ではサーバーが新しい通信で TCP パケットを送信できるのは最大 10 個です(~14 KB)。その後、サーバーは、輻輳ウィンドウを増やしてさらにデータ配信を進める前にクライアントがこのデータを承認するまで待機する必要があります。

この TCP の動作のため、コンテンツを最適化して、ページの最初のレンダリングを実行するために必要なデータの配信にかかる往復数を最小限に抑えることが重要です。理想としては、ATF コンテンツは 14 KB 未満にすることが適しています。これにより、ブラウザはたった 1 回の往復でページのレンダリングができるようになります。また、10 個のパケット(IW10)の制限は TCP 標準の最近のアップデートであることにも注意が必要です。この変更点を活用するには、サーバーが最新バージョンにアップグレードされていることを確認してください。最新バージョンにアップグレードされていない場合、制限は 3~4 個のパケットとなる可能性が高くなります。

(4)スクロールせずに見えるコンテンツでは外部のブロック JavaScript と CSS を使用しない

ブラウザではページをユーザーに表示する前に解析する必要があります。ブラウザで解析中に非同期ではない、またはブロックの外部スクリプトを検出した場合、ブラウザは解析を停止してそのリソースをダウンロードしなければなりません。そのたびにネットワークの往復が追加されるため、ページが最初に表示されるまでの時間が遅くなります。

そのため、スクロールせずに見える領域をレンダリングするために必要な JavaScript や CSS はインライン化し、ページにさらに機能を追加するために必要な JavaScript や CSS は ATF コンテンツが配信された後に読み込む必要があります。

(5)ブラウザのレイアウトとレンダリングのための時間を確保しておく(200 ミリ秒)
HTML、CSS、JavaScript の実行を解析するプロセスには時間とクライアントのリソースが費やされます。携帯端末の速度とページの複雑さによっては、このプロセスには数百ミリ秒かかる場合があります。ブラウザのオーバーヘッドのために 200 ミリ秒を確保しておくことをおすすめします。
(6)JavaScript の実行とレンダリング時間を最適化する
複雑なスクリプトや非効率的なコードは、実行に数十~数百ミリ秒かかります。ブラウザの組み込みデベロッパー ツールを使用してコードをプロファイリングし最適化してください。Chrome デベロッパー ツールのインタラクティブ コースは概要を知るのに最適です。ぜひご覧ください。

よくある質問

4G ネットワークは上記のモバイル基準にどのような影響を及ぼしますか?
往復の待ち時間が短いことが 4G ネットワークの主な改善点の 1 つです。これによりネットワークのオーバーヘッド時間全体が短縮されるため非常に有益です。オーバーヘッド時間は現在、3G ネットワークで 1 秒のうちの 50% に相当します。しかし、3G は世界中で主流のネットワークとなっており、今後数年はそうあり続けるでしょう。ページの最適化は 3G ユーザーを念頭に置いて行う必要があります。
JQuery などの JavaScript ライブラリを使用している場合はどうすればよいですか?
JQuery など多くの JavaScript ライブラリは、インタラクティブ性やアニメーションなどの効果を付加してページの魅力を高めるために使用されています。ただし、こうした動作の多くは、スクロールせずに見える範囲のコンテンツが表示された後に追加しても差し支えありません。そのような JavaScript の実行や読み込みをページの読み込み後に移動することを検討してください。
ページの作成に JavaScript フレームワークを使用している場合はどうすればよいですか?
クライアントサイドの JavaScript を使ってページのコンテンツを作成している場合は、関連する JavaScript モジュールをインライン化して、余分なネットワークの往復を避けることを検討してください。同様に、サーバーサイド レンダリングを使用すると、最初のページの読み込みのパフォーマンスが大幅に改善される場合があります。JS テンプレートをサーバー上でレンダリングし、その結果を HTML にインライン化してから、アプリケーションの読み込み後にクライアントサイド テンプレートを使用します。
SPDY と HTTP 2.0 の有益な点を教えてください。
SPDY と HTTP 2.0 は両方とも、基底の TCP 接続をより効果的に活用(多重化、ヘッダー圧縮、優先順位付け)してページの読み込みにかかる待ち時間を短縮することを目的としています。また、サーバー プッシュ機能により、余分なネットワークの待ち時間がなくなり、パフォーマンスがさらに向上します。サーバーに SPDY サポートを追加し、利用可能となり次第 HTTP 2.0 に切り替えることを検討することをおすすめします。
ページで重要な CSS を特定する方法を教えてください。
Chrome デベロッパー ツールで [Audits] パネルを開いてウェブページ パフォーマンス レポートを実行し、生成されたレポートで [Remove unused CSS rules] を探します。あるいは、他のサードパーティのツールまたはスクリプトを使用して、各ページでどの CSS セレクタが適用されているかを特定します。
これらのおすすめの方法は自動化できますか?
もちろんです。商用やオープンソースのウェブ パフォーマンス最適化(WPO)製品は数多くあります。このような製品を使用すると、上記の基準の一部またはすべてを満たすことができます。オープンソース ソリューションについては、PageSpeed 最適化ツールをご覧ください。
これらの基準を満たすにはサーバーをどのように調整すればよいですか?
まず、サーバーが最新バージョンのオペレーティング システムを実行していることを確認してください。最初の TCP 輻輳ウィンドウのサイズ(IW10)が大きくなったメリットを活用するには、Linux カーネル 2.6.39 以降が必要です。他のオペレーティング システムについては、該当のドキュメントをご覧ください。
サーバーの応答時間を最適化するには、コードをインストルメント化するか、アプリケーション監視ソリューションを使用してボトルネック(スクリプト記述の実行時間、データベースの呼び出し、RPC リクエスト、レンダリングなど)を特定してください。200 ミリ秒以内に HTML レスポンスをレンダリングすることが目標です。
コンテンツ セキュリティ ポリシー(CSP)について教えてください。
CSP を使用している場合は、デフォルトのポリシーを更新する必要がある場合があります。
まず、インライン CSS 属性は多くの場合不要なコードの重複の原因となるため、可能であれば HTML 要素のインライン CSS 属性(例: &lt p style=...&gt)を使用しないでください。インライン CSS 属性はデフォルトで CSP によりブロックされます(「style-src」の「unsafe inline」を通じて無効になります)。CSP が有効になっていると、デフォルトですべてのインライン スクリプト タグがブロックされます。インライン JavaScript がある場合は、CSP ポリシーを更新してスクリプト ハッシュ値またはナンス値を使用するか、「unsafe-inline」を使用してすべてのインライン スクリプトが実行されるようにします。インライン スタイルがある場合は、CSP ポリシーを更新してスタイル ハッシュ値またはナンス値を使用するか、「unsafe-inline」を使用してすべてのインライン スタイルのブロックが処理されるようにします。

他にご不明な点がある場合は、お気軽に PageSpeed Insights のディスカッション グループ(pagespeed-insights-discuss)をご利用ください。