私の会社のサイトはほとんどがサーバー レンダリングされています (構造化ページ フラグメントを使用しています) が、プログレッシブ Web アプリの構築を検討したいと考えています。
サーバーでレンダリングされたページに Service Worker キャッシュを実装してプログレッシブ Web アプリを構築することは理にかなっていますか? あるいは、クライアント側のレンダリングへの移行を検討する必要がありますか?
非常に遅いデバイスを多数サポートしているため、サーバー上でできるだけ多くのレンダリングを行いたいことに注意してください。
サーバーでレンダリングされたページは、サイトにある程度の動的またはパーソナライズされたコンテンツがあることを意味します。そうでない場合は、静的な HTML を提供しているだけです。
オンラインとオフラインの両方で、動的コンテンツをどのように処理するかという観点から、最初に検討することをお勧めします。Jake Archibald のOffline Cookbookを読むと、実装できるさまざまな戦略の概要がわかります。
動的コンテンツのキャッシュ戦略を設定したら、次のステップはそれを実装することです。「ゴールド スタンダード」のアプローチは、App Shell + 動的コンテンツ アーキテクチャを使用することですが、既存のアプリケーションをこのアーキテクチャに組み込むには、特にサーバーから返される最初の HTML に動的/パーソナライズされた要素が含まれる場合に、ある程度のリファクタリングが必要になる場合があります。
リファクタリングが困難なタスクである場合、またはサーバーのみのレンダリングが厳しい要件である場合でも、Service Worker キャッシュを利用できますが、最終的にシェルを動的コンテンツであるかのように扱うことになるでしょう。 . これは、純粋なキャッシュ優先戦略は「安全」ではない可能性があることを意味しますが、キャッシュ/ネットワーク競合が機能するか、少なくともネットワークが cache にフォールバックする可能性があります。
これらの戦略の両方を使用すると、オフラインで動作する Web アプリになりますが、重複したデータをキャッシュすることになる可能性があります (つまり、共通の HTML 構造/page1を共有している場合、それを 2 回キャッシュすることになります)。/page2また、App Shell を使用する場合よりも頻繁にネットワークにアクセスする必要があるため、パフォーマンスと帯域幅の消費に影響を与えますが、適切な HTTP ブラウザー キャッシュ ヘッダーを使用することで多少軽減できます。(Service Worker のサポートがないブラウザーの場合は、とにかく考えておく必要があります。)
はい、Service Worker はクライアント側のレンダリングに限定されません。
必要なものは何でもキャッシュできます。たとえば、この WordPress プラグインはWordPress コンテンツをキャッシュします。