localStorage vs sessionStorage vs Cookies –詳細な比較

Cookieは長い間使用されてきました（Internet Explorer v2は1995年10月にCookieをサポートしていました）。 彼らには何の問題もありませんし、彼らは確かにウェブをより快適な場所にしましたが、25年近く経ってから多くのことが変わりました。

ローカルストレージ（W3のWebストレージの下にあります）は、Cookieの代わりになります。 それがそれについて最も混乱していることです。 ほとんどの場合、Cookieの代わりにlocalStorageを安全に使用して、Cookieが同じであるのに、同じであるという（間違った）印象を与えることができます。 読み進めて、localStorageを使用してCookieを置き換える方法とタイミングのナンセンスな内訳を確認してください。

革命か進化か？

ローカルストレージ、またはlocalStorage、またはDOMストレージまたはWebストレージ（私はこれらの名前を作成していません。これらはすべて使用されており、すべて同じものを参照しています）は、2012年に「HTML5特徴"。 それはクッキーの天の恵みの代替品のようでした。 不必要なデータを常に運ぶ肥大化したリクエストとサイズの制限に対する修正。 それはそれらの問題を「解決」しますが、それはクッキーの代わりとなるリンゴではありません。

そして、私たちが不要なデータのトピックに取り組んでいる間。 リクエストだけが不必要な肥大化を引き起こす可能性があることをご存知でしたか？あなたのサイトもそうです。 幸いなことに、解決策があり、それはWPリセットと呼ばれます。

WP Resetは、蓄積されたデータやアドオン（プラグイン、テーマ、ユーザー、ウィジェット、コンテンツなど）をサイトから削除するなどの操作を可能にする、さまざまなリセットオプションが付属するプラグインです。サイト全体をきれいに拭くことさえできます。 すごいですよね？ しかし、それだけではありません。 他の機能の中でも、このプラグインは、データベーススナップショットだけでなく、必要な回数だけクリックするだけでインストールできるプラグインとテーマのコレクションを作成できます。 間違いなくチェックする価値のあるツールです。

しかし、ここで、localStorageの話に戻りましょう。

名前が示すように、データはユーザーのデバイスにローカルに保存されます。 したがって、HTTPリクエストごとにネットワーク経由で転送する必要がなく、フットプリントが削減され、データを保存するためのスペースが大幅に増えます。 この「ローカルのみ」のパラダイムは、Cookieとローカルストレージの最も重要な違いです。 Cookieは、サーバー側とクライアント側の両方で読み取ることができ、ローカルストレージはクライアント側でのみ読み取ることができます。 これですべてです。 アプリがサーバー側のCookieの読み取りとそれに基づいたコンテンツの生成に大きく依存している場合、ローカルストレージに切り替えると、アプリを書き直すことになります。 インターフェースでアクティブなタブなどの設定を保存するためにCookieのみを使用する場合は、ローカルストレージが理想的な代替手段です。

欺瞞的に似ている

次の表は、Cookie、localStorage、およびsessionStorageの違いと使用例を明確に示しています。 すぐにそれを一瞥して必要な答えを得て去ることができますが、詳細に入るやや長い脚注を読むことをお勧めします。 はい、あなたは忙しくて次の猫のビデオを見たいと思っていますが、物事は白黒ではないので、もう少し深く掘り下げるとよいでしょう。

WebストレージとCookieを深く掘り下げる

ローカルに保存できるデータの最大量は、ブラウザによって異なります。 保証はありません。安全な賭けが必要な場合は、5MB未満から約2MBに設定してください。 この便利なツールを使用して、ブラウザで許可されているローカルストレージの最大サイズをテストします。

ユーザーがサードパーティまたはすべてのCookieをブロックするのは一般的なシナリオです。 同じルールがローカルストレージにも適用されます。 保証はありません。ローカルストレージが利用できない環境では、アプリが機能する（または少なくとも壊れない）必要があります。

すべてのCookieはある時点で期限切れになりますが、人々は寿命を数年に設定する傾向があります。これはインターネットの時代には永遠に思えます。 一方、ローカルストレージは期限切れになることはなく、アプリまたはユーザーが削除するまで利用できます。 タブまたはウィンドウが閉じられると、セッションストレージが削除されます–例外はありません。

「文字列しか保存できないとはどういう意味ですか？ 私はいつもオブジェクトを保存しています！」 JSONを使用すると、オブジェクトやその他のデータ型を文字列の形式で保存できます。 変換は、ユーザーの知らないうちに読み取りと書き込みで行われます。 Cookieとローカルストレージを処理するためのサウンドライブラリを使用すると、データ型について考える必要がなくなります。 ただし、文字列のみがネイティブにサポートされているという事実は変わりません。

すべてのブラウザがサポートする単一のクライアント側機能はありません。 それは悲しい事実ですが、それでも事実です。 Can I Useで特定の番号を確認できますが、Cookieとローカルストレージに関しては、それらをサポートしていないすべてのブラウザを無視します。 それらは限界であり、1％未満です。

サーバー側の処理のみを介してlocalStorageにアクセスすることはできません。 JSも必要です。 ユーザーがページを要求し、PHPがページを生成するためにキックイン（または使用するサーバー側の言語）すると、ローカルデータ、セッション、またはパーマネントにアクセスできなくなります。 ページが読み込まれ、JSが起動すると、ローカルデータにアクセスして、必要な操作を実行できます。ユーザーインターフェイスを調整するか、AJAXを使用してローカルデータをサーバーに送り返します。 そうです、ローカルデータをサーバーに戻すことはできますが、Cookieを使用する場合と同じ方法で同じ瞬間に取得することはできません。 要件によっては、Cookieからローカルストレージへの切り替えに関しては、これが問題になる可能性があるため、事前に計画してください。

ローカルストレージでは、クライアントとサーバー間でデータが転送されません（明示的にそれを行うコードがない限り）。 ペイロードサイズを縮小するのに最適です。 一方、Cookieは、設定されたドメインでのすべてのリクエストでHTTPヘッダーフィールドとして転送されます。 変更したり、選択的にオフにしたりすることはできません。

ユーザーはローカルデータにアクセスして直接（アプリの外部で）変更するべきではありませんが、それを妨げるものは何もありません。 ローカルに保存されたデータを編集するために利用できるデバッグツールは多数あります。 したがって、ローカルデータを信頼したり、ユーザーがそれに触れなかったと想定したりしないでください。 常に悪いことを想定してください。

Cookieには設定可能な「安全な」属性がありますが、アプリケーションからブラウザへの転送中にCookieを保護することはできません。 ですから、それは何もないよりはましです。 クライアント側のみのテクノロジーであるローカルストレージは、HTTPとHTTPSのどちらを使用するかを認識または認識しません。 セキュリティは、データを処理する方法から生まれる必要があります。 クレジットカード番号やパスワードなどの機密データをローカルストレージの形式で保存しないでください。 これまで！

始めるためのちょっとしたコード

この記事は、JavaScript Webストレージのチュートリアルを目的としたものではありませんが、問題を回避するために、ローカルストレージを使用したHelloWorldの例を示します。

// store a value
localStorage.setItem( 'name', 'John' );

// retrieve a value
localStorage.getItem( 'name' );

// remove the value
localStorage.removeItem( 'name' );

// only string values can be stored so for objects, use JSON
var post = {
  title: 'Cookies are old',
  author: 'Gordan'
}
localStorage.setItem( 'post', JSON.stringify( post ) );

// and to retrieve
var post = JSON.parse( localStorage.getItem( 'post' ) );

上記のコードは機能し、可能な限りシンプルです。 ただし、使用はお勧めしません。 Cookieと同様に、誰もdocument.cookiesを使用してCookieを操作することはありません。 考慮すべきブラウザ間のわずかな違いがあります。これらは文字列のみを格納するため、読み取りと書き込みのたびにJSONで文字列化して解析する必要があります。 そのため、js-cookieなどのCookieの処理に役立つ小さなライブラリを使用しています。 ローカルストレージについても同じことが言えます。 コードとAPIの間に小さな抽象化レイヤーを配置すると、長期的には役立ちます。 store.jsをお勧めします。 それはしばらく前からあり、クロスブラウザのナンセンスとフォールバックを処理し、その機能を拡張する便利なプラグインさえ持っています。 コーディングの練習に興味がある場合は、独自のライブラリを作成してjQueryプラグインに変換してください。

クッキーは悪いですよね？ 何か新しいものが必要です！

クッキーは悪くありません。 彼らは何十年にもわたってその目的を果たしてきましたが、ローカルストレージは「リンゴの代わり」ではないため、今後もそうしていきます。 しかし、クッキーは老化の兆候を示しています。 それとは別に、彼らの設計上の欠点のいくつかもすぐにはなくなることはありません。 つまり、Cookieペイロードと小さな最大ペイロードサイズを使用して、ドメイン上のすべてのリクエストを「汚染」します。

不十分で古いかどうかにかかわらず、Cookieは残っているので、ローカルストレージがすぐに完全に引き継がれるとは思わないでください。 ただし、一部のユースケースでは、ローカルストレージが間違いなくより良い選択です。

クライアント側に保存するデータが（大量に）あり、サーバーに転送されることはめったになく、そのデータに機密情報が含まれていない場合は、ローカルストレージの使用を開始してください。 それはまさにそれが作成されたものです。 ドメイン上のすべてのHTTPリクエストを軽くすることでより高速なアプリを作成し、新しいものを使用するというあたたかいファジーな感覚を得ることができます。