PRPL パターンを使用して即時読み込みを適用する

PRPL とは、ウェブページを読み込み、 より高速にインタラクティブになります。

  • 遅れて検出されたリソースをプリロードする。
  • 初期ルートをできるだけ早くレンダリングします。
  • 残りのアセットを事前にキャッシュに保存します。
  • 他のルートと重要性の低いアセットを遅延読み込みします。

このガイドでは、これらの手法がどのように連携して機能するかを 個別に使用する必要はありません。

Lighthouse を使用してページを監査する

Lighthouse を実行し、PRPL に沿って改善の機会を特定する 手法:

  1. Ctrl+Shift+J キー(Mac の場合は Command+Option+J キー)を押して DevTools を開きます。
  2. [Lighthouse] タブをクリックします。
  3. [パフォーマンス] と [プログレッシブ ウェブアプリ] のチェックボックスをオンにします。
  4. [Run Audits] をクリックしてレポートを生成します。

詳しくは、Lighthouse を使用してパフォーマンス向上の機会を特定するをご覧ください。

重要なリソースをプリロードする

Lighthouse では、特定のリソースが解析され、 遅れて取得されたケース:

Lighthouse: キーリクエストの監査をプリロードする

プリロード 宣言型のフェッチ リクエストで、background-image プロパティで参照される画像など、ブラウザのプリロード スキャナで検出されないリソースをリクエストするようブラウザに指示します。rel="preload" を含む <link> タグを HTML ドキュメントのヘッダーに追加することで、遅れて検出されたリソースをプリロードします。

<link rel="preload" as="image" href="hero-image.jpg">

<link rel="preload"> ディレクティブを追加すると、そのリソースに対するリクエストが開始され、キャッシュに保存されます。ブラウザは必要に応じてこの情報を取得できます。

重要なリソースのプリロードについて詳しくは、このモジュールの 重要なアセットをプリロードするガイド。

<ph type="x-smartling-placeholder">

初期ルートをできるだけ早くレンダリングする

Lighthouse では、First Paint を遅延させるリソースがある場合に警告が表示されます。 サイトでピクセルが画面にレンダリングされる瞬間です。

Lighthouse: レンダリングをブロックするリソースの監査を排除

Lighthouse では、First Paint を改善するために、重要な JavaScript と 使用して残りを遅らせる async スクロールせずに見える範囲で使用する重要な CSS の インライン化も可能ですこれにより サーバーへのラウンドトリップをなくし、レンダリングをブロックするアセットを取得します。 ただし、開発の観点ではインライン コードの保守が難しく、 ブラウザで個別にキャッシュできません。

First Paint を改善するためのもう 1 つの方法は、初期状態をサーバー側でレンダリングすることです。 ページの HTML。これにより、スクリプトの作成中、ユーザーにコンテンツがすぐに表示されます。 まだ取得、解析、実行されています。ただし、これにより 著しく低下し、操作可能になるまでの時間に悪影響を及ぼす可能性があります。 アプリケーションがインタラクティブになって 必要があります。

最初のペイントを減らすための正しい解決策は、 インライン スタイルとサーバーサイドの メリットがトレードオフを上回りますGoogle Chat では この 2 つのコンセプトについて詳しくは、以下のリソースをご覧ください。

Service Worker によるリクエスト/レスポンス

アセットを事前キャッシュに保存する

Service Worker をプロキシとして機能させることで、キャッシュからアセットを直接取得可能 再訪問時はサーバーにアクセスしませんこれによりユーザーは オフラインでも使えるようになりますが、ローカル環境でページの読み込みが速くなります。 再訪問する傾向にあります

サードパーティ ライブラリを使用して Service Worker の生成プロセスを簡素化する ただし、ライブラリの処理能力よりも複雑なキャッシュ要件がある場合は、 提供します。たとえば Workbox には、 Service Worker を作成、管理するためのツールのコレクションが キャッシュに保存します。Service Worker とオフラインの信頼性について詳しくは、 信頼性の学習プログラムの Service Worker ガイドをご覧ください。

遅延読み込み

Lighthouse では、ネットワーク経由で送るデータが多すぎると、「不合格」と表示されます。

Lighthouse: 膨大なネットワーク ペイロードの監査

これにはすべてのアセットタイプが含まれますが、サイズの大きな JavaScript ペイロードは特に ブラウザでの解析とコンパイルに時間がかかるため、コストがかさみます。 Lighthouse では、必要に応じて警告が表示されます。

Lighthouse: JavaScript 起動時間の監査

実行時に必要なコードのみを含む小さな JavaScript ペイロードを送信する場合は、 ユーザーが最初にアプリケーションを読み込み、バンドル全体をオンデマンドで遅延読み込みチャンクに分割します。

バンドルの分割が完了したら、より多くのチャンクをプリロードします。 (重要なアセットをプリロードするのガイドをご覧ください)。 プリロードにより、より重要なリソースがより早くフェッチおよびダウンロードされるようになる 表示されます。

さまざまな JavaScript チャンクをオンデマンドで分割して読み込む以外に、 Lighthouse では、重要でない画像の遅延読み込みの監査も行えます。

Lighthouse: 画面外画像の監査を延期する

ウェブページに多数の画像を読み込む場合は、スクロールしなければ見えない範囲にある画像をすべて遅らせるか、 ページの読み込み時にデバイスのビューポートの外側にレンダリングされるようにする必要があります(遅延サイズを使用して画像を遅延読み込みするをご覧ください)。

次のステップ

PRPL パターンの背後にある基本的なコンセプトを理解したところで、 詳細については、このセクションの次のガイドにお進みください。 重要な点として、すべての手法を必ずしも Google Cloud に 適用されます。以下のいずれかに取り組むと、 パフォーマンスが大幅に向上します

  • 重要なリソースをプリロードする。
  • 初期ルートをできるだけ早くレンダリングします。
  • 残りのアセットを事前にキャッシュに保存します。
  • 他のルートと重要性の低いアセットを遅延読み込みします。

PRPL パターンの詳細をご確認ください。