優れたプログレッシブ ウェブアプリとは

プログレッシブ ウェブアプリ(PWA)は、最新の API で構築、強化されており、機能、信頼性、インストール性が強化されています。また、1 つのコードベースで誰でも、どこでも、どのデバイスでも利用できます。最適なエクスペリエンスを実現するには、主要なチェックリストと最適なチェックリストと推奨事項を参考にしてください。

プログレッシブ ウェブアプリの主なチェックリスト

プログレッシブ ウェブアプリのチェックリストでは、サイズや入力タイプに関係なく、アプリをすべてのユーザーがインストールおよび使用できる条件について説明します。

すばやく起動、常に高速で快適
パフォーマンスは、パフォーマンスが高いサイトはパフォーマンスが低いサイトよりもユーザーのエンゲージメントと定着率が高いため、オンライン エクスペリエンスの成功において重要な役割を果たします。サイトは、ユーザーを中心としたパフォーマンス指標の最適化に重点を置く必要があります。

パフォーマンスは、オンライン エクスペリエンスの成功に大きな役割を果たします。パフォーマンスが高いサイトは、パフォーマンスが低いサイトよりもユーザーのエンゲージメントと定着率が高いからです。サイトは、ユーザーを中心としたパフォーマンス指標の最適化に重点を置く必要があります。

理由

ユーザーにアプリを使用してもらうには、速度が重要です。実際、ページの読み込み時間が 1 秒から 10 秒になると、ユーザーが直帰する確率は 123% 増加します。パフォーマンスは load イベントで終わることはありません。ユーザーは、操作(ボタンのクリックなど)が登録されたかどうかを気にする必要はありません。スクロールとアニメーションが滑らかに感じられる必要があります。パフォーマンスは、ユーザーによるアプリケーションの認識から実際のパフォーマンスまで、エクスペリエンス全体に影響します。

アプリケーションによってニーズは異なりますが、Lighthouse のパフォーマンス監査は Core Web Vitals に基づいており、これらの監査で高スコアを出すことで、ユーザーが快適に利用できる可能性が高くなります。また、PageSpeed InsightsChrome ユーザー エクスペリエンス レポートを使用して、ウェブアプリの実際のパフォーマンス データを取得することもできます。

方法

読み込み時間の短縮に関するガイドで、PWA の起動を高速化し、常に高速で維持する方法をご確認ください。

あらゆるブラウザに対応
ユーザーは、インストール前に任意のブラウザを使用してウェブアプリにアクセスできます。

ユーザーは、インストール前であれば、どのブラウザでもウェブアプリにアクセスできます。

理由

プログレッシブ ウェブアプリはまずウェブアプリです。つまり、ブラウザのいずれか 1 つだけでなく、複数のブラウザをまたいで機能する必要があります。

これを効果的に行うには、Resilient Web Design の Jeremy Keith の言葉を借りれば、コア機能を特定し、その機能を最もシンプルなテクノロジーで利用できるようにして、可能な限りユーザー エクスペリエンスを向上させることが挙げられます。多くの場合、これは HTML だけでコア機能を作成し、CSS と JavaScript を使用してユーザー エクスペリエンスを向上させ、より魅力的なエクスペリエンスを実現することを意味します。

フォームの送信を例にとります。最も簡単な実装方法は、POST リクエストを送信する HTML フォームです。これを作成すると、JavaScript でフォームの検証を行い、AJAX を介してフォームを送信するエクスペリエンスを強化し、サポート可能なユーザーのエクスペリエンスを向上させることができます。

ユーザーがさまざまなデバイスやブラウザでサイトにアクセスすることを考慮してください。単純にスペクトルの上の端だけをターゲットにすることはできません。機能検出を使用すると、現在存在しないブラウザやデバイスを使用しているユーザーも含め、幅広い潜在ユーザーに有用なエクスペリエンスを提供できます。

方法

Jeremy Keith による Resilient Web Design は、クロスブラウザ、プログレッシブな手法におけるウェブデザインの考え方を説明する優れたリソースです。

その他の情報

あらゆる画面サイズにレスポンシブ
ユーザーは任意の画面サイズで PWA を使用でき、すべてのコンテンツを任意のビューポート サイズで使用できます。

ユーザーは任意の画面サイズで PWA を使用し、すべてのコンテンツを任意のビューポート サイズで使用できます。

理由

デバイスにはさまざまなサイズがあり、ユーザーは同じデバイスであってもさまざまなサイズのアプリを使用できます。そのため、コンテンツをビューポート内に収めるだけでなく、サイトのすべての機能とコンテンツをすべてのビューポート サイズで使用可能にすることが重要です。

ユーザーが完了させたいタスクやアクセスしたいコンテンツがビューポートのサイズによって変わることはない。コンテンツはさまざまなビューポート サイズで再配置でき、どのような方法であれ、すべて存在する必要があります。Luke Wroblewski が著書『Mobile First』で述べているように、小規模から始めて大規模に行うことで、サイトのデザインを実際に改善できます。

> モバイル デバイスの場合、ソフトウェア開発チームはアプリの最も重要なデータとアクションのみに注力する必要があります。320 x 480 ピクセルの画面には、余分な不要な要素を表示するスペースがありません。> 優先順位を付ける必要があります。

方法

レスポンシブ デザインについては、Ethan Marcotte による元の記事、関連する重要なコンセプトのコレクション、書籍や講演など、レスポンシブ デザインに関するリソースが多数あります。レスポンシブ デザインのコンテンツの側面に絞り込むには、コンテンツファースト デザインコンテンツ出力レスポンシブ レイアウトについて詳しく見ていきます。 最後に、Josh Clark による Seven Deadly Mobile Myths の教訓はモバイルに焦点を当てていますが、モバイルの場合と同様に、レスポンシブ サイトの小規模なビューにも当てはまります。

カスタムのオフライン ページを用意する
ユーザーがオフラインのときに PWA に保持しておくことで、ブラウザのデフォルトのオフライン ページに戻るよりもシームレスなエクスペリエンスが提供されます。

ユーザーがオフラインのときに PWA に保持しておくことで、ブラウザのデフォルトのオフライン ページに戻るよりもシームレスなエクスペリエンスを提供できます。

理由

ユーザーは、接続状態に関係なくインストール済みのアプリが動作することを期待しています。 プラットフォーム固有のアプリでは、オフラインのときに空白のページは表示されません。プログレッシブ ウェブアプリでは、ブラウザのデフォルトのオフライン ページは表示されません。キャッシュに保存されていない URL にユーザーが移動したときも、接続を必要とする機能を使用しようとしたときにも、カスタムのオフライン エクスペリエンスを提供することで、ウェブ エクスペリエンスが動作中のデバイスの一部であるかのように感じられます。

方法

Service Worker の install イベントの発生中に、後で使用するためにカスタムのオフライン ページを事前キャッシュできます。ユーザーがオフラインになった場合、事前にキャッシュに保存されたカスタム オフライン ページで応答できます。Google のカスタム オフライン ページのサンプルで、実際の例と実装方法を確認できます。

インストール可能である
デバイスにアプリをインストールまたは追加するユーザーは、それらのアプリを利用する傾向があります。

デバイスにアプリをインストールまたは追加するユーザーは、それらのアプリを利用する傾向があります。

理由

プログレッシブ ウェブアプリをインストールすると、他のすべてのインストール済みアプリのデザイン、操作性、動作を実現できます。ユーザーが他のアプリを起動するのと同じ場所から起動します。アプリは、ブラウザとは別のアプリ ウィンドウ内で実行され、他のアプリと同様にタスクリストに表示されます。

PWA のインストールをユーザーに求める理由は何ですか。アプリストアからアプリをインストールしてもらうのと同じ理由です。アプリをインストールしたユーザーは、最もエンゲージメントの高いオーディエンスであり、一般的な訪問者よりもエンゲージメント指標が高く、多くの場合、モバイル デバイスのアプリユーザーと同等です。これらの指標には、リピート アクセスの増加、サイトの滞在時間、コンバージョン率の向上が含まれます。

方法

インストール可能なガイドでは、PWA をインストール可能にする方法、インストール可能かどうかをテストする方法、自分でインストールを試す方法について説明しています。

最適なプログレッシブ ウェブアプリのチェックリスト

優れたプログレッシブ ウェブアプリ(最高水準のアプリのように感じられるアプリ)を作成するには、単なるチェックリスト以外の要素が必要です。プログレッシブ ウェブアプリの最適なチェックリストは、ウェブの強みを活かしながら、PWA を動作中のデバイスの一部であるかのように感じさせることです。

オフライン エクスペリエンスを提供する
接続が厳密には要求されない場合、オフラインでも、アプリはオンラインの場合と同じように動作します。

接続が厳密には要求されない場合、アプリはオフラインでもオンラインと同じように動作します。

理由

ユーザーは、カスタムのオフライン ページを提供するだけでなく、プログレッシブ ウェブアプリがオフラインでも利用可能になることを期待しています。たとえば、旅行や航空会社のアプリでは、旅行の詳細と搭乗券をオフラインでも簡単に利用できるようにする必要があります。音楽アプリ、動画アプリ、ポッドキャスト アプリでは、オフライン再生ができるようにする必要があります。ソーシャル アプリやニュースアプリは、ユーザーがオフラインで読めるように、最近のコンテンツをキャッシュに保存する必要があります。また、ユーザーはオフライン時も認証が維持されることを期待するため、オフライン認証用に設計してください。オフライン PWA は、アプリと同様のユーザー エクスペリエンスを提供します。

方法

ユーザーがオフラインでの作業を想定している機能を決定したら、次に、コンテンツをオフラインのコンテキストで利用できるようにして、それに対応できるようにする必要があります。さらに、ブラウザ内 NoSQL ストレージ システムである IndexedDB を使用してデータの保存と取得を行うことができます。また、バックグラウンド同期を使用して、ユーザーがオフライン中にアクションを実行できるようにし、ユーザーの接続が再び安定するまでサーバー通信を延期することもできます。また、Service Worker を使用して他の種類のコンテンツ(オフラインで使用する画像ファイル、動画ファイル、音声ファイルなど)を保存し、それらを使用して安全で長期間有効なセッションを実装し、ユーザーの認証を維持することもできます。ユーザー エクスペリエンスの観点から、スケルトン画面を使用して、読み込み中にユーザーに速度とコンテンツを認識させ、必要に応じてキャッシュに保存されたコンテンツまたはオフライン インジケーターにフォールバックできます。

完全にアクセス可能
すべてのユーザー操作は、WCAG 2.0 のユーザー補助要件を満たしています。

すべてのユーザー操作は、WCAG 2.0 のユーザー補助要件を満たしています。

理由

ほとんどのユーザーは、人生のある時点で、WCAG 2.0 のユーザー補助要件の対象となる方法で PWA を利用したいと思うでしょう。ユーザーが PWA を操作して理解する能力には一定の範囲があり、そのニーズは一時的または永続的です。PWA を誰もが利用できるようにすることで、誰でも利用できるようにします。

方法

手始めに、W3C の Introduction to Web Accessibility をおすすめします。ユーザー補助機能テストの大半は、手動で行う必要があります。Lighthouse、axeユーザー補助インサイトユーザー補助監査などのツールを使用すると、ユーザー補助のテストを自動化できます。また、a 要素や button 要素など、これらの要素を独自に再作成するのではなく、意味的に正しい要素を使用することも重要です。これにより、より高度な機能を構築する必要がある場合に、矢印とタブを使用するタイミングなど、ユーザー補助機能に関する要求事項を満たすことができます。A11Y Nutrition Cards は、いくつかの一般的なコンポーネントについてこれに関する優れたアドバイスを提供しています。

検索で見つけられる
PWA は検索で検出されます。

PWA は検索で検出されます。

理由

ウェブの最大の利点の 1 つは、検索でサイトやアプリを見つけられることです。実際に、ウェブサイトの全トラフィックの半分以上がオーガニック検索から発生しています。ユーザーが PWA を見つけられるようにするには、コンテンツに対して正規 URL が存在し、検索エンジンがサイトをインデックスに登録できるようにする必要があります。これは特に、クライアントサイド レンダリングを導入する場合に当てはまります。

方法

まず、各 URL に一意のわかりやすいタイトルとメタ ディスクリプションが設定されていることを確認します。その後、Lighthouse の Google Search Console検索エンジン最適化の監査を使用して、PWA の見つけやすさに関する問題をデバッグおよび修正できます。Bing または Yandex のウェブマスター ツールを使用することもできます。また、Schema.org のスキーマを介して構造化データを PWA に含めることも検討してください。

あらゆる入力タイプに対応
PWA は、マウス、キーボード、タッチペン、タップ操作でも同様に使用できます。

PWA は、マウス、キーボード、タッチペン、タップ操作でも同様に使用できます。

理由

デバイスにはさまざまな入力方法があり、ユーザーがアプリケーションの使用中にそれらの入力方法をシームレスに切り替えられるようにする必要があります。同様に重要な点として、入力方法は画面サイズに依存しないようにする必要があります。つまり、大きいビューポートはタップをサポートする必要があり、小さいビューポートはキーボードとマウスをサポートする必要があります。アプリとそのすべての機能で、ユーザーが選択できる任意の入力方法の使用を可能な限りサポートするようにしてください。必要に応じて、入力固有の制御(プルして更新など)もできるようにエクスペリエンスを強化する必要があります。

方法

Pointer Events API は、さまざまな入力オプションを操作する統一されたインターフェースを提供し、タッチペンのサポートを追加する場合に特に適しています。タップとキーボードの両方をサポートするには、正しいセマンティック要素(アンカー、ボタン、フォーム コントロールなど)を使用し、非セマンティック HTML で再構築しないことを確認します(ユーザー補助に適しています)。カーソルを合わせたときにアクティブになる操作を含める場合は、クリックやタップでもアクティブになるようにしてください。

権限リクエストのコンテキストを提供する
強力な API を使用する許可を求める場合は、コンテキストを提供し、その API が必要な場合にのみ要求します。

強力な API を使用する許可を求めるときは、状況を説明し、その API が必要なときだけ要求するようにします。

理由

通知、位置情報、認証情報など、権限プロンプトをトリガーする API は、ユーザーがオプトインを必要とする強力な機能に関係している傾向があるため、ユーザーの混乱を招きかねないように設計されています。ページの読み込み時などの追加コンテキストなしでプロンプトをトリガーすると、ユーザーが権限を承認する可能性が低くなり、将来的に権限を信用できなくなる可能性が高くなります。プロンプトをトリガーできるのは、その権限が必要な理由について、状況に応じた説明をユーザーに提供した後に限られます。

方法

Permission UX に関する記事と UX Planet の The Right Ways to Ask Users for Permissions は、モバイルに焦点を当てつつ、すべての PWA に適用される権限プロンプトの設計方法を理解するための優れたリソースです。

正常なコードのためのベスト プラクティスに従っている
コードベースを健全な状態に保つことで、目標の達成や新機能の提供が容易になります。

コードベースを健全な状態に保つことで、目標の達成や新機能の提供が容易になります。

理由

最新のウェブ アプリケーションの構築には、多くの要素が関わります。アプリケーションを最新の状態に保ち、コードベースを健全に保つことで、このチェックリストに記載されている他の目標を満たす新機能を簡単に提供できるようになります。

方法

健全なコードベースを確保するための優先度の高いチェックには、既知の脆弱性のあるライブラリの使用の回避、非推奨の API を使用していないこと、コードベースからのウェブ アンチパターンの削除(document.write() の使用、非パッシブなスクロール イベント リスナーの使用など)、さらには分析や他のサードパーティ ライブラリの読み込みに失敗した場合に PWA が破損しないように防御的なコーディングが行われます。複数のブラウザとリリース チャンネルで、lint チェックなどの静的コード分析と自動テストを必須にすることを検討してください。これらの手法は、本番環境に導入する前にエラーをキャッチするのに役立ちます。