現代のウェブは、さまざまなデバイスやネットワーク接続を使用して、幅広いユーザーに利用されています。クリエイターの作品は世界中のユーザーに届きますが、すべてのユーザーにウェブ上で信頼性の高いエクスペリエンスを提供することは難しい場合があります。信頼性の意味を理解するだけでも難しい場合があります。
オフラインでも信頼できる
信頼性を考えるうえで、ウェブアプリがネットワーク接続なしで動作するかどうかは重要な要素です。これは、アプリストアからモバイル デバイスにインストールされたプラットフォーム固有のアプリでユーザーが当然のことと考える信頼性の一種です。これらのアプリのアイコンが表示されたら、インターネットに接続しているかどうかに関係なく、タップして何らかの操作ができることをユーザーは期待します。
最近まで、ネットワーク接続なしで信頼性の高いウェブ アプリケーションを構築することは困難でした。
信頼性に優れた高速
信頼性について考えるもう 1 つの方法は、ネットワーク接続が理想的でない場合に、ユーザーがウェブアプリを十分に高速で読み込めるかどうかです。リピーターがモバイル接続に接続している場合と Wi-Fi に接続している場合で、ウェブアプリの操作性が異なることはありますか？レイテンシの高い「lie-fi」接続を使用しているユーザーはどうなるのでしょうか。このようなシナリオでも、ウェブアプリは確実に高速で動作しますか？
最適な状況で高速に動作するだけでは十分ではありません。ユーザーは、あらゆるネットワーク環境での動作という観点からウェブアプリのパフォーマンスを評価します。
信頼性は実現可能
幸いなことに、最新のウェブ プラットフォームには、信頼性の高いウェブ アプリケーションの構成要素として機能する Service Worker や Cache Storage API などのテクノロジーが用意されています。これにより、ウェブアプリとネットワークの間に位置するコードを記述できます。多くの場合、ネットワークを完全にバイパスし、代わりに以前にキャッシュに保存されたコンテンツを使用してウェブアプリのリクエストを満たすことができます。
ガイドライト: オフライン時に 200 OK を返します
Service Worker の構築を開始し、キャッシュからコンテンツを配信すると、効果的に配信できているかどうかを把握するのが難しくなります。実装した Service Worker が実際にウェブアプリでネットワークを回避するのに役立っているかどうかをどのように確認すればよいでしょうか？キャッシュ保存戦略の小さな変更によって、丁寧に作成したオフライン エクスペリエンスが壊れないようにするにはどうすればよいですか？
Lighthouse には、信頼性の高いウェブアプリを構築する際に特に重要なテストが 1 つあります。オフライン時にステータス 200 の応答を返す:
ここで実際にテストされているのは何ですか？これは、ブラウザ内でネットワーク接続の喪失をシミュレートし、サイトの監査対象の URL を読み込もうとするものです。このテストでは、信頼性の高いサイトを構築するうえで重要な要素の 1 つである「オフラインでも信頼できる」という側面を、制御された再現可能な一連のアクションを使用してテストします。
旅のようなものです
初めて CMS を導入する場合は、オフライン時に 200 を返すチェックで否定的な結果が返される可能性が非常に高くなります。問題ありません。カスタマイズされたスターター プロジェクトを使用していない限り、ウェブ アプリケーションにはデフォルトでそのような信頼性はありません。以降のガイドでは、ウェブアプリが読み込んでいるものを特定するために必要な手法を紹介し、Lighthouse を使用して読み込みエクスペリエンスの信頼性を高める方法を説明します。
このプロセス全体を通して、Lighthouse 監査を繰り返し実行することをおすすめします。新しいウェブ アプリケーションから信頼性の高いプログレッシブ ウェブアプリまで、このガイドは、その過程全体を通して道しるべとなります。