PageSpeed Insights でのモバイル分析

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

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

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

モバイル端末で ATF を 1 秒未満で表示するという基準を満たすには、他のネットワークでは生じない特有の課題があります。ユーザーは多種多様な 2G、3G、4G ネットワークを通じてサイトにアクセスする可能性があります。以下のように、ネットワークの遅延時間は有線接続に比べて大幅に長く、ATF コンテンツを表示する際の時間の制約である 1,000 ミリ秒のうちの大部分を消費します。

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

その点を考慮して、もう一度、1 秒未満で表示するという基準について考えてみましょう。一般的なブラウザとサーバーの間の一連の通信を見ると、この時間のうちすでに 300 ミリ秒が、DNS ルックアップによる IP アドレスからホスト名（google.com など）への解決、ネットワーク ラウンド トリップによる TCP ハンドシェイク、オプションの TLS 接続といったネットワークのオーバーヘッドに費やされています。これにより、残りは 700 ミリ秒となります。

1 秒未満での表示の実現

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

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

TCP が通信量を制御する仕組み（TCP スロースタート）が実装されているため、新しい TCP 接続はクライアントとサーバーの間で利用可能な帯域幅すべてをすぐに使用することはできません。このため、新しい TCP 接続の最初のラウンド トリップでは、サーバーから送信できるパケット数は最大 10 個（～14 KB）に制御されています。サーバーは、このデータの確認応答がクライアントから送信されるまで待ってから、輻輳ウィンドウを増やしてデータ配信量を増やすことができます。

また、10 個のパケット（IW10）の制限は TCP 標準の最近のアップデートであることにも注意してください。これを利用するためには、サーバーが最新バージョンにアップグレードされていることを確認する必要があります。最新バージョンにアップグレードされていない場合、パケット数の制限が 3～4 個となる可能性が高くなります。

この TCP の動作のため、コンテンツを最適化し、最初のページ レンダリングに必要なデータの配信に要するラウンド トリップの数を最小限に抑えることが重要です。ATF コンテンツを 98 KB 未満にすることができれば理想的です。そうすることで、ブラウザはわずか 3 回のラウンド トリップでページを描画でき、サーバーの応答遅延とクライアント側のレンダリングに十分な時間を確保できます。

（4）スクロールせずに見える範囲のコンテンツでは、レンダリングをブロックする外部の JavaScript や CSS を使用しない

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

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

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

よくある質問

JQuery などの JavaScript ライブラリを使用している場合はどうすればよいですか？
JQuery など多くの JavaScript ライブラリは、インタラクティブ性やアニメーションなどの効果を付加してページの魅力を高めるために使用されています。ただし、こうした動作の多くは、スクロールせずに見える範囲のコンテンツが表示された後に追加しても差し支えありません。そのような JavaScript の実行や読み込みの処理を、ページの読み込みの後に移動することを検討してください。
ページの作成に JavaScript フレームワークを使用している場合はどうすればよいですか？
クライアントサイドの JavaScript を使ってページのコンテンツを作成している場合は、関連する JavaScript モジュールをインライン化して、余分なネットワーク ラウンド トリップを避けることを検討してください。同様に、サーバーサイド レンダリングを使用すると、最初のページの読み込みのパフォーマンスが大幅に改善される場合があります。JS テンプレートをサーバー上でレンダリングし、その結果を HTML にインライン化してから、アプリケーションの読み込み後にクライアントサイド テンプレートを使用します。
ページで重要な 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）をご利用ください。