PRPL は、ウェブページを読み込んでインタラクティブに高速化するために使用されるパターンの頭字語です。
- 遅れて検出されたリソースをプリロードします。
- 最初のルートをできるだけ早くレンダリングします。
- 残りのアセットを事前にキャッシュに保存します。
- 他のルートや重要性の低いアセットを遅延読み込みします。
このガイドでは、これらの各手法を連携させながら、個別に使用してパフォーマンスを向上させる方法について説明します。
Lighthouse を使用してページを監査する
Lighthouse を実行して、PRPL の手法に沿った改善の機会を特定します。
- Ctrl+Shift+J キー(Mac の場合は Command+Option+J キー)を押して DevTools を開きます。
- [Lighthouse] タブをクリックします。
- [パフォーマンス] と [プログレッシブ ウェブアプリ] のチェックボックスをオンにします。
- [Run Audits] をクリックしてレポートを生成します。
詳しくは、Lighthouse を使用してパフォーマンス改善の機会を見つけるをご覧ください。
重要なリソースをプリロードする
特定のリソースの解析と取得が遅れた場合、Lighthouse では次のような不合格の監査が表示されます。
プリロードは宣言型取得リクエストであり、通常はブラウザのプリロード スキャナでは検出できないリソース(background-image
プロパティで参照される画像など)をリクエストするようブラウザに指示します。遅れて検出されたリソースをプリロードするには、HTML ドキュメントの先頭に rel="preload"
を含む <link>
タグを追加します。
<link rel="preload" as="image" href="hero-image.jpg">
<link rel="preload">
ディレクティブを追加すると、そのリソースに対するリクエストが開始され、キャッシュに保存されます。これにより、ブラウザは必要に応じてそのデータを取得できます。
重要なリソースのプリロードの詳細については、重要なアセットのプリロードガイドをご覧ください。
初期ルートをできるだけ早くレンダリングする
Lighthouse では、First Paint(サイトが画面にピクセルをレンダリングするタイミング)を遅らせるリソースがある場合、警告が表示されます。
First Paint の向上のため、Lighthouse では重要な JavaScript をインライン化し、async
を使用して残りを遅延させること、およびスクロールせずに見える範囲で使用する重要な CSS をインライン化することをおすすめしています。これにより、レンダリング ブロック アセットを取得するサーバーとのラウンドトリップがなくなるため、パフォーマンスが向上します。ただし、インライン コードは、開発の観点から維持することが難しく、ブラウザで個別にキャッシュすることはできません。
First Paint を改善するもう 1 つの方法は、ページの最初の HTML をサーバー側でレンダリングすることです。これにより、スクリプトの取得、解析、実行が続いている間に、コンテンツが直ちにユーザーに表示されます。ただし、これにより HTML ファイルのペイロードが大幅に増加し、Time to Interactive、すなわちアプリケーションがインタラクティブになってユーザー入力に応答するまでの時間が長引く可能性があります。
アプリ内の First Paint を減らすための正しい解決策は 1 つではありません。インライン スタイルとサーバーサイド レンダリングは、そのメリットがアプリのトレードオフを上回る場合にのみ検討してください。この 2 つのコンセプトの詳細については、次のリソースをご覧ください。
アセットを事前キャッシュする
プロキシとして機能することで、Service Worker は再アクセス時にサーバーではなくキャッシュから直接アセットを取得できます。これにより、ユーザーがオフラインでもアプリケーションを使用できるだけでなく、再アクセス時のページの読み込み時間が短縮されます。
サードパーティ ライブラリを使用して、Service Worker の生成プロセスを簡素化します。ただし、ライブラリが提供するものよりも複雑なキャッシュ要件がある場合を除きます。たとえば、Workbox は、アセットをキャッシュに保存する Service Worker を作成および維持できるツールのコレクションを提供します。Service Worker とオフラインの信頼性の詳細については、信頼性の学習プログラムの Service Worker ガイドをご覧ください。
遅延読み込み
ネットワーク経由で送信されるデータが多すぎると、Lighthouse では不合格となった監査が表示されます。
これにはすべてのアセットタイプが含まれますが、大規模な JavaScript ペイロードは、ブラウザによる解析とコンパイルに時間がかかるため、特にコストがかかります。必要に応じて、Lighthouse でも警告が表示されます。
ユーザーが最初にアプリケーションを読み込むときに必要なコードのみを含む、より小さい JavaScript ペイロードを送信するには、バンドル全体とオンデマンドで遅延読み込みのチャンクを分割します。
バンドルを分割したら、より重要なチャンクをプリロードします(重要なアセットをプリロードするガイドをご覧ください)。プリロードにより、重要なリソースがブラウザによって迅速に取得されてダウンロードされるようになります。
Lighthouse では、さまざまな JavaScript チャンクをオンデマンドで分割して読み込むほか、重要性の低い画像の遅延読み込みの監査も行えます。
ウェブページに多数の画像を読み込む場合は、ページ読み込み時に、スクロールしなければ見えない範囲にある画像やデバイスのビューポートの外側にある画像の読み込みを遅らせます(Lazysize を使用して画像を遅延読み込みするをご覧ください)。
次のステップ
PRPL パターンの背後にある基本コンセプトを理解したところで、このセクションの次のガイドに進み、詳細を確認してください。すべての手法を一緒に適用する必要はありません。次のいずれかを行うことで、パフォーマンスが大幅に向上します。
- 重要なリソースをプリロードします。
- 最初のルートをできるだけ早くレンダリングします。
- 残りのアセットを事前にキャッシュに保存します。
- 他のルートや重要性の低いアセットを遅延読み込みします。
PRPL パターンの詳細を確認する。