このページは Cloud Translation API によって翻訳されました。

ウェブ向けのストレージ

ブラウザにデータを保存する方法は数多くあります。どちらがニーズに合っていますか？

Pete LePage

外出先でインターネット接続が不安定であったり、接続できなかったりする場合があるので、オフラインサポートと信頼性の高いパフォーマンスは、プログレッシブウェブアプリ完全なワイヤレス状態でも保存、キャッシュ、その他のストレージ手法を賢く使用すると、ユーザーエクスペリエンスが大幅に向上しますキャッシュに保存する方法はいくつかあります。静的なアプリケーションリソース（HTML、JavaScript、CSS、画像など）データ（ユーザーデータ、ニュース記事など）最適なソリューションはどれでしょうか？方法保存できる量はどれくらいでしょうか強制排除されないようにするにはどうすればよいですか？

何を使用すればよいですか？

リソースを保存する一般的な推奨事項は次のとおりです。

アプリやファイルベースのコンテンツの読み込みに必要なネットワークリソースについては、 Cache Storage API（ Service Worker）。
その他のデータには、IndexedDB（ Promise ラッパー）。

IndexedDB と Cache Storage API は、すべての最新のブラウザでサポートされています。どちらも非同期であり、メインスレッドをブロックしません。それらは window オブジェクト、ウェブワーカー、Service Worker からアクセス可能で、コード内のどこでも簡単に使用できます

他のストレージメカニズムについてはどうですか？

ブラウザで使用できるストレージメカニズムは他にもいくつかありますが、使用が制限されており、重大なパフォーマンスの問題を引き起こす可能性があります。

SessionStorage はタブ固有で、スコープはそのタブのライフタイム。少量のセッションを保存し、固有の情報（IndexedDB キーなど）が含まれます。この方法は、これは同期的であり、メインスレッドをブロックするため、注意する必要があります。内容サイズが約 5 MB に制限され、文字列のみを含めることができます。これはタブ固有であるためウェブワーカーや Service Worker からはアクセスできません。

LocalStorage は同期的であるため、使用しないでください。メインスレッドをブロックします。サイズは約 5 MB に制限されており、文字列だけです。ウェブワーカーまたはサービスから LocalStorage にアクセスできないできます。

Cookie には用途がありますが、保存のためには使用しないでください。 Cookie は HTTP リクエストごとに送信されるため、データ量が少ない場合、すべてのウェブリクエストのサイズが大幅に増加します。これらは同期的であり、ウェブワーカーからはアクセスできません。高評価 LocalStorage と SessionStorage では、Cookie は文字列のみに制限されます。

File System API と FileWriter API は、以下を行うためのメソッドを提供します。サンドボックス化されたファイルシステムとの間でファイルを読み書きできます。非同期ですが推奨されません。これは、 Chromium ベースのブラウザでのみ利用可能。

File System Access API は、ユーザーが簡単にローカルファイルシステム上のファイルを読み取り、編集できます。ユーザーページがローカルファイルの読み取りまたは書き込みを行えるようにするには、その権限を許可する必要があります。セッション間では保持されません。

WebSQL は使用しないで、既存の使用を IndexedDB。サポートは、ほぼすべてのメジャーサポートから終了しましたできます。W3C は 2010 年に Web SQL の仕様の維持を停止しました。今後の更新の予定はない。

アプリケーションキャッシュは使用しないでください。既存の使用量は Service Worker と Cache API に移行されます。時間が非推奨になり、実現します。

保存できる量

簡単に言うと、大量、少なくとも数百 MB、場合によっては数倍ですデータを格納できますブラウザの実装はさまざまですが、どのストレージを使用できるかは、通常はダウンロードします

Chrome ではブラウザが総ディスク容量の最大 80% を使用できます。オリジンは合計ディスク容量の最大 60% を使用します。StorageManager を使用すると、 API を使用して、使用可能な最大割り当てを決定します。その他の Chromium ベースブラウザが異なる場合があります。
- シークレットモードでは、オリジンが利用できるストレージの量が少なくなります最大 5% が削減されます。
- ユーザーが [すべて閉じるときに Cookie とサイトデータを削除する] を有効にしている場合は、 Windows"保存容量は大幅に削減され、最大約 300 MB です。
- PR #3896 をご覧ください。をご覧ください。
Internet Explorer 10 以降では 250 MB まで保存でき、ユーザーに表示されます
Firefox では、ブラウザがディスクの空き容量を最大 50% 使用できます。「 eTLD+1 グループ（例:example.com、www.example.com、foo.bar.example.com）最大で 2 GB が使用される可能性があります。こちらの StorageManager API で残りの容量を判断できます。
Safari（パソコンとモバイルの両方）で約 1 GB が許可されるようです。制限が上限に達すると Safari でメッセージが表示され、上限が 200 MB に引き上げられますできます。これに関する公式ドキュメントは見つかりませんでした。
- モバイル Safari のホーム画面に PWA を追加すると、作成しても PWA 間では共有されないモバイル Safari ですインストールされている PWA が割り当てに達すると、追加のストレージをリクエストすることはできません。

これまでは、サイトの保存データが一定のしきい値を超えると、ブラウザが、より多くのデータを使用する権限を付与するようユーザーに求めます。対象オリジンで使用されたデータ量が 50 MB を超えた場合、ブラウザはユーザーに最大 100 MB 保存できるようにしてから、50 MB 単位で再度リクエストします。

現在、ほとんどの最新のブラウザでは、ユーザーにプロンプトは表示されず、できます。例外は Safari のようです。保存容量の上限を超過すると、プロンプトが表示され、増加する権限をリクエストする自動的にスケールします。送信元が割り当て分を超える使用を試みるため、さらにデータの書き込みが試行されます。失敗します

空き容量を確認するにはどうすればよいですか？

多くのブラウザでは、 StorageManager API でストレージ容量を確認送信元で使用可能なストレージの容量などがありますこのレポートでは、 IndexedDB と Cache API が使用するバイト数をカウントし、を使用して残りの保存容量の概算を計算できます。

if (navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate();
  // quota.usage -> Number of bytes used.
  // quota.quota -> Maximum number of bytes available.
  const percentageUsed = (quota.usage / quota.quota) * 100;
  console.log(`You've used ${percentageUsed}% of the available storage.`);
  const remaining = quota.quota - quota.usage;
  console.log(`You can write up to ${remaining} more bytes.`);
}

StorageManager はまだすべてのブラウザにimplementedされていないため、使用前に検出する必要があります。たとえ利用可能であっても、割り当て超過エラーを検出することもできます（以下を参照）。場合によっては、実際に利用可能なストレージ容量を超過している場合。

検証

開発中は、ブラウザの DevTools を使用して、保存できるデータをすべて簡単に消去できます。

サイトのストレージをオーバーライドできる新機能（Chrome 88）保存容量が表示されます。この機能を使用するとディスクの可用性が低い状態でのアプリの動作をテストできる説明します。[アプリ]、[ストレージ] の順に移動して、 [カスタムストレージの割り当てをシミュレート] チェックボックスをオンにして、有効な数値をストレージの割り当てをシミュレートします。

DevTools の [Storage] ペイン。

この記事の作業中に、私が作成したシンプルなツール可能な限り多くのストレージをすばやく使用しようとします迅速かつ簡単な方法でさまざまなストレージメカニズムを試してみて、どのストレージメカニズムが割り当てをすべて使用した場合です

割り当て超過に対処する方法

割り当てを超えた場合はどうすればよいですか。最も重要なのは書き込みエラーを常に検出して処理する（QuotaExceededError またはできます。次に、アプリの設計に応じて、処理方法を決定します。たとえば、長期間アクセスしていないコンテンツを削除する、または、ユーザーが削除する項目を選択できるようにします。

IndexedDB と Cache API はどちらも、DOMError という名前の利用可能な割り当てを超えた場合は QuotaExceededError。

IndexedDB

オリジンが割り当てを超過している場合、IndexedDB に書き込もうとすると、失敗します。トランザクションの onabort() ハンドラが呼び出され、イベントを渡します。このイベントの error プロパティには DOMException が含まれます。ルールのエラー name では QuotaExceededError が返されます。

const transaction = idb.transaction(['entries'], 'readwrite');
transaction.onabort = function(event) {
  const error = event.target.error; // DOMException
  if (error.name == 'QuotaExceededError') {
    // Fallback code goes here
  }
};

キャッシュ API

配信元が割り当てを超過している場合は、Cache API への書き込みが試行されます。 QuotaExceededError DOMException で拒否されます。

try {
  const cache = await caches.open('my-cache');
  await cache.add(new Request('/sample1.jpg'));
} catch (err) {
  if (error.name === 'QuotaExceededError') {
    // Fallback code goes here
  }
}

エビクションの仕組み

ウェブストレージは「ベストエフォート」の 2 つのバケットに分類される「永続性」です。ベストエフォートでは、何もしなくてもブラウザはストレージを消去できます。ただし、長期のデータや重要なデータに対しては耐久性が低くなります。ストレージが少なくなっても、永続ストレージは自動的に消去されません。ユーザーこのストレージは（ブラウザの設定を介して）手動で消去する必要があります。

デフォルトでは、サイトのデータ（IndexedDB、Cache API など）は次のカテゴリに分類されます。カテゴリは「ベストエフォート」です。つまり、永続ストレージをリクエストした場合、ブラウザによって強制排除される場合があります。独自の裁量でサイトのデータを保護できます。たとえば、デバイスの空き容量が少ない場合が該当します。

ベストエフォートのエビクションポリシーは次のとおりです。

Chromium ベースのブラウザでは、ブラウザを使い切った時点でデータの削除が開始されます最も長い間使われていないオリジンのサイトデータをすべて消去するブラウザが上限を超えなくなるまで続きます。
Internet Explorer 10 以降では、データは強制排除されませんが、もう書いていません。
Firefox はディスクの空き容量がなくなるとデータの強制排除を開始します。最も長い間使われていないオリジンのサイトデータをすべて消去してから、ブラウザが上限を超えなくなるまで続きます
Safari はこれまでデータを削除しなかったが、最近書き込み可能なすべてのストレージに 7 日間の上限が適用されます（下記参照）。

iOS および iPadOS 13.4 以降、および macOS の Safari 13.1 以降、 IndexedDB、サービスバックエンドサービスを含む、すべてのスクリプト書き込み可能ストレージの 7 日間の上限ワーカー登録、Cache API などがあります。Safari ですべてのコンテンツが強制排除されます Safari で 7 日間経過した後にキャッシュからのコンテンツユーザーとやり取りしますこのエビクションポリシーは、インストールされているホーム画面に追加されている PWA。詳しくは、 WebKit のサードパーティ Cookie の完全ブロックなどブログをご覧ください。

参考: IndexedDB にラッパーを使用する理由

IndexedDB は低レベルの API であり、使用する前にかなりの設定が必要です。シンプルなデータを保存する場合には特に問題になります最新のテクノロジーとイベントベースです。Promise のラッパー。たとえば、 IndexedDB の idb には優れた機能の一部が隠されていますが、重要なのは、複雑な機構（トランザクション、スキーマのバージョニングなど）を隠すこと。（IndexedDB ライブラリに付属しています）。

まとめ

保存容量が限られ、ユーザーが大量の保存容量やできます。サイトはすべてのリソースとデータを効果的に保存できる必要があります。StorageManager API を使用すると、使用可能なリソースの量とこれまでに使用した使用量によって決まりますまた、永続ストレージ。ユーザーが削除しない限り、エビクションから保護できます。

参考情報

ありがとう

Jarryd Goodman、Phil Walton、Eiji Kitamura、Daniel Murphy に心より感謝します。 Darwin Huang、Josh Bell、Marijn Kruisselbrink、Victor Costan（レビュー担当）ご覧ください。執筆者: Eiji Kitamura、Addy Osmani、Marc Cohen の基づいた元の記事ですEiji が開発した便利なツール（Browser Storage Abuser）と呼ばれ、現在の動作を確認します。可能な限り多くのデータを保存しブラウザの使用容量の上限をご確認ください。掘り起こしてくれたフランソワボーフォートのおかげ Safari を開いて、保存容量を確認します。

ヒーロー画像は、Guillaume Bolduc 氏がスプラッシュを解除。