PRPL パターン

アプリケーションをグローバルにアクセス可能にすることは課題となります。低スペックなデバイスや通信環境の悪い地域でも、アプリケーションがパフォーマンスを発揮できることを確認する必要があります。アプリケーションが難しい環境でも効率的に読み込まれるようにするために、PRPL パターンを使用できます。

使用する場合

• 低スペックなデバイスと遅いネットワークで良いパフォーマンスを発揮する必要があるアプリケーションを構築するときに使用します
• これはウェブアプリケーションのクリティカルレンダリングパスを最適化するのに役立ちます

手順

• Push: HTTP/2 サーバープッシュまたは preload ヒントを使用して、クリティカルなリソースを効率的にプッシュします
• Render: 初期ルートをできるだけ早くレンダリングして、高速な初回描画を実現します
• Pre-cache: サービスワーカーを使用して頻繁にアクセスされるルートをプリキャッシュし、オフライン対応を実現します
• Lazily load: すぐに必要でないルートとアセットを遅延ロードします
• メインのエントリーポイントとしてアプリシェルアーキテクチャを使用します

詳細

PRPL パターンは、4 つの主なパフォーマンス上の考慮事項に焦点を当てています。

• Push: クリティカルなリソースを効率的にプッシュすることで、サーバーへの往復回数を最小化し、ロード時間を短縮します
• Render: 初期ルートをできるだけ早くレンダリングして、ユーザー体験を向上させます
• Pre-cache: バックグラウンドでアセットをキャッシュして、頻繁にアクセスされるルートのサーバーへのリクエスト数を最小化し、より良いオフライン体験を実現します
• Lazily load: 頻繁にアクセスされないルートやアセットを遅延ロードします

ウェブサイトにアクセスしたいとき、まずサーバーにリクエストを送信してリソースを取得する必要があります。エントリーポイントが指し示すファイルがサーバーから返されます。これは通常、アプリケーションの初期 HTML ファイルです。ブラウザの HTML パーサーはサーバーからデータを受信し始めるとすぐにそのデータを解析し始めます。パーサーがスタイルシートやスクリプトなどの追加リソースが必要なことを発見すると、それらのリソースを取得するために別の HTTP リクエストがサーバーに送信されます。

リソースを繰り返しリクエストしなければならないのは最適ではありません。クライアントとサーバー間の往復回数を最小化しようとしているからです。

長い間、クライアントとサーバー間の通信に HTTP/1.1 を使用していました。HTTP/2 は HTTP/1.1 と比較して大きな変更をもたらし、クライアントとサーバー間のメッセージ交換を最適化しやすくなりました。

HTTP/1.1 はリクエストとレスポンスで改行で区切られたプレーンテキストプロトコルを使用していましたが、HTTP/2 はリクエストとレスポンスをフレームと呼ばれるより小さい単位に分割します。ヘッダーとボディフィールドを含む HTTP リクエストは、最低でも 2 つのフレームに分割されます。ヘッダーフレームとデータフレームです。

HTTP/1.1 はクライアントとサーバー間で最大 6 つの TCP 接続を持っていました。新しいリクエストを同じ TCP 接続で送信できるようになるには、前のリクエストが解決される必要があります。前のリクエストが解決に時間がかかっている場合、このリクエストは他のリクエストが送信されるのをブロックします。この一般的な問題は行頭ブロッキング（head of line blocking）と呼ばれ、特定のリソースのロード時間を増やす可能性があります。

HTTP/2 は双方向ストリームを使用しており、1 つの TCP 接続に複数の双方向ストリームを含めることが可能になり、クライアントとサーバー間で複数のリクエストとレスポンスフレームを運ぶことができます。

HTTP/2 は行頭ブロッキングを解決することで、前のリクエストが解決される前に同じ TCP 接続で複数のリクエストを送信することが可能になります。

HTTP/2 はまた、サーバープッシュと呼ばれるより最適化されたデータフェッチ方式も導入しました。HTTP リクエストを送信して毎回明示的にリソースをリクエストする代わりに、サーバーはこれらのリソースを自動的に「プッシュ」することで追加リソースを送信できます。

クライアントが追加リソースを受け取った後、リソースはブラウザキャッシュに保存されます。エントリーファイルを解析中にリソースが発見されると、ブラウザはサーバーに HTTP リクエストを送信する代わりに、キャッシュから素早くリソースを取得できます。

リソースをプッシュすることで追加リソースを受信するまでの時間は短縮されますが、サーバープッシュは HTTP キャッシュを認識しません。プッシュされたリソースは次にウェブサイトを訪問したときに利用できず、再度リクエストする必要があります。これを解決するために、PRPL パターンは初期ロード後にサービスワーカーを使用してそれらのリソースをキャッシュし、クライアントが不要なリクエストを送信しないようにします。

サイトの作成者として、通常はどのリソースが早期にフェッチするのに重要かを知っていますが、ブラウザはできる限りこれを推測しようとしています。クリティカルなリソースに preload リソースヒントを追加することで、ブラウザを支援できます。

ブラウザに特定のリソースをプリロードしたいと伝えることで、ブラウザがそれを発見する前にそれをフェッチしたいと伝えていることになります。プリロードは、現在のルートに必要なリソースのロード時間を短縮する素晴らしい方法です。

リソースをプリロードすることは往復回数を減らし、ロード時間を最適化する素晴らしい方法ですが、多くのファイルをプッシュするのは有害になる可能性があります。ブラウザのキャッシュは制限されており、クライアントが実際に必要としなかったリソースをリクエストすることによって、帯域幅を不必要に使用する可能性があります。

PRPL パターンは初期ロードの最適化に焦点を当てています。初期ルートが読み込まれてレンダリングされるまで、他のリソースは読み込まれません。

これはアプリケーションを小さなパフォーマンスの良いバンドルにコード分割することで達成できます。これらのバンドルは、ユーザーが必要な時に必要なリソースだけを読み込みながら、キャッシュ可能性を最大化することを可能にする必要があります。

大きなバンドルのキャッシュは問題になる可能性があります。複数のバンドルが同じリソースを共有することができます。ブラウザは複数のルート間で共有されるバンドルのどの部分かを識別するのが難しく、したがってこれらのリソースをキャッシュできません。リソースをキャッシュすることは、サーバーへの往復回数を減らし、アプリケーションをオフラインに対応させるために重要です。

PRPL パターンで作業するときは、リクエストするバンドルがその時点で必要なリソースの最小限の量を含み、ブラウザがキャッシュ可能であることを確認する必要があります。

PRPL パターンは多くの場合、アプリシェルをメインのエントリーポイントとして使用しています。アプリシェルは、アプリケーションのロジックの大部分を含む最小限のファイルであり、ルート間で共有されます。また、アプリケーションのルーターも含まれており、動的に必要なリソースをリクエストできます。

PRPL パターンは、初期ルートがユーザーのデバイスに表示される前に、他のリソースが要求またはレンダリングされないようにします。初期ルートが正常に読み込まれた後、サービスワーカーをインストールして、バックグラウンドで他の頻繁にアクセスされるルートのリソースをフェッチできます。

このデータはバックグラウンドでフェッチされているため、ユーザーは遅延を経験しません。ユーザーがサービスワーカーでキャッシュされた頻繁にアクセスされるルートに移動したい場合、サービスワーカーはサーバーにリクエストを送信する代わりに、キャッシュから素早く必要なリソースを取得できます。

頻繁にアクセスされないルートのリソースは、動的にインポートできます。

ソース

• patterns.dev/vanilla/prpl