クリティカルパスを見極める
ブラウザがページの構築や描画の前に必要とする場合、スタイルシートや同期スクリプトがレンダリングをブロックすることがあります。適切な対処は、そのリソースが初期ビューに必要かどうかで変わります。必要なスタイルや動作を残さずに、レポートからリクエストだけを消しても、問題が移動するだけです。
確認の方法
ページ読み込みのトレースを取得し、最初のレンダリングより前に読み込まれるリソース、ファーストビューで実際に使われるリソース、遅延の主因がサーバーの応答なのかメインスレッドの処理なのかを特定します。キャッシュのない状態と、代表的な回線でテストします。ラボデータは経路の診断に使い、実際の訪問者がそれを体感しているかはフィールドデータで確認します。
導入と改善の方法
初期ビューに必要な、小さなクリティカルCSSだけをインライン化または優先します。重要でないコードは、安全な範囲で遅延させ、未使用のコードは元から減らします。変更のたびに、見た目が完全であること、キーボード操作、エラーのない操作、新たなレイアウトシフトがないことを確認します。
限界とよくある間違い
よくある間違いは、すべてのスクリプトやスタイルシートを遅延させることです。クリティカルなリソースは、初期ページが必要とするからクリティカルなのです。依存関係を、小さく意図的なものにします。
切り分けは、「JavaScriptはdeferする」という一律のルールではなく、ウォーターフォールとトレースから始めます。最初に有用な見た目になる状態を特定し、それを作るために必要なCSS、フォント、スクリプトを挙げて、後から読み込まれるアセットと分けます。初期のナビゲーションを定義するスタイルシートはクリティカルかもしれませんが、ファーストビューの下にあるカルーセルのライブラリはそうではありません。リクエストの優先度、応答時間、未使用のバイト数、メインスレッドのタスクを確認します。導入では、未使用のスタイルを元から減らすか分割し、ファーストビューが本当に必要とするリソースだけをpreloadします。アセットを遅延させるのは、初期ページのスタイルと操作が保たれると確認してからです。キャッシュなし、制限された回線、キーボード操作で再テストします。フォントの入れ替えで行の折り返しが変わるなら、読み込みのタイミングに加えて、レイアウトへの影響も記録します。確認すべき結果は、警告の件数が減ったことではなく、完全で使えるファーストビューです。
具体例です。商品一覧ページが、グローバルなスタイルシート1つ、小さなヘッダー用スタイルシート、Webフォント、並べ替えコンポーネント、ファーストビューの下のギャラリーを読み込んでいます。ウォーターフォールで、最初の2つのスタイルシートが最初の描画より前に実際に使われているかを確認します。縮小したクリティカルなバンドルの候補になるかもしれません。ギャラリーのスクリプトが見えていないなら、ヘッダーと商品グリッドを遅らせてはいけません。グローバルなスタイルシート全体をインライン化するのは避けます。バイトが重複し、キャッシュもしにくくなります。代わりに、初期ビューに必要なルールだけを抜き出し、メインのスタイルシートは通常どおり読み込んで、それが届いたときの切り替わりをテストします。デプロイ後にウォーターフォールを再実行し、スタイルが適用される前のテキストのちらつき、フォーカスの枠線の欠落、レイアウトシフトを確認します。変更を採用するのは、ページが正しく描画され、その後の操作も動作する場合だけです。