localStorage vs sessionStorage vs pliki cookie – szczegółowe porównanie

Pliki cookie są z nami od dawna (Internet Explorer v2 obsługiwał je w październiku 1995 roku). Nie ma w nich nic złego iz pewnością sprawili, że sieć stała się przyjemniejsza, ale po prawie 25 latach wiele się zmieniło.

Local Storage (znajdziesz je w Web Storage na W3) jest i nie jest zamiennikiem plików cookie. To jest w tym najbardziej zagmatwane. W większości przypadków można bezpiecznie użyć localStorage zamiast plików cookie i odnieść (błędne) wrażenie, że są one takie same, podczas gdy tak nie jest. Czytaj dalej, aby zobaczyć dokładny podział na to, jak i kiedy używać localStorage do zastępowania plików cookie.

Rewolucja czy ewolucja?

Pamięć lokalna lub localStorage lub DOM storage lub pamięć internetowa (nie wymyślam tych nazw; wszystkie są w użyciu i wszystkie odnoszą się do tego samego) zostały przyjęte w świecie rzeczywistym wśród popularnych przeglądarek w 2012 roku jako „HTML5 funkcja". Wydawało się to wybawieniem zamiennikiem ciastek. Poprawka dla nadętych żądań przenoszących niepotrzebne dane przez cały czas i ograniczenia rozmiaru. Chociaż „rozwiązuje” te problemy, nie jest zamiennikiem „jabłek w jabłkach” dla ciasteczek.

A skoro już jesteśmy przy temacie niepotrzebnych danych. Czy wiesz, że prośby nie są jedyną rzeczą, która może powodować niepotrzebne rozdęcie, Twoja witryna też może. Na szczęście istnieje rozwiązanie i nazywa się WP Reset.

WP Reset to wtyczka, która zawiera szereg opcji resetowania, które umożliwiają takie czynności, jak usuwanie zgromadzonych danych i/lub dodatków (wtyczek, motywów, użytkowników, widżetów, treści itp.) z witryny i nawet wyczyszczenie całej witryny. Niesamowite, prawda? Ale to nie wszystko. Ta wtyczka może między innymi tworzyć migawki bazy danych, a także kolekcje wtyczek i motywów, które można zainstalować jednym kliknięciem tyle razy, ile potrzebujesz. Zdecydowanie narzędzie, które warto sprawdzić.

Ale teraz wróćmy do rozmowy o localStorage.

Jak sama nazwa wskazuje, dane są przechowywane lokalnie, na urządzeniu użytkownika. W związku z tym nie musi być przesyłany przez sieć przy każdym żądaniu HTTP, zmniejszając rozmiar i dając nam dużo więcej miejsca na zapisanie danych. Ten paradygmat „tylko lokalnie” jest najważniejszą różnicą między plikami cookie a pamięcią lokalną. Pliki cookie mogą być odczytywane zarówno po stronie serwera, jak i po stronie klienta, lokalna pamięć masowa tylko po stronie klienta. To wszystko. Jeśli Twoja aplikacja w dużym stopniu polega na odczytywaniu plików cookie po stronie serwera i generowaniu na ich podstawie treści, przejście na pamięć lokalną będzie oznaczać przepisanie aplikacji. Jeśli używasz plików cookie tylko do przechowywania ustawień, takich jak aktywna karta w interfejsie, pamięć lokalna jest idealnym zamiennikiem.

Zwodniczo podobne

Poniższa tabela daje jasny wgląd w różnice i przypadki użycia plików cookie, localStorage i sessionStorage. Chociaż możesz szybko na nią spojrzeć, aby uzyskać odpowiedź, której potrzebujesz i wyjść, polecam przeczytanie nieco długich przypisów, które zawierają więcej szczegółów. Tak, wiem, że jesteś zajęty i chcesz obejrzeć kolejny film o kotach, ale rzeczy nie są czarno-białe, więc kopanie trochę głębiej dobrze ci zrobi.

Zagłębianie się w pamięć internetową i pliki cookie

Maksymalna ilość danych , które możesz przechowywać lokalnie, zależy od przeglądarki. Nie ma żadnych gwarancji, a jeśli chcesz bezpieczny zakład, zejdź poniżej 5 MB, do około 2 MB. Użyj tego przydatnego narzędzia, aby przetestować maksymalny dozwolony rozmiar pamięci lokalnej w przeglądarce.

Użytkownicy często blokują pliki cookie innych firm lub wszystkie pliki cookie . Ta sama zasada dotyczy pamięci lokalnej. Nie ma żadnych gwarancji, a Twoja aplikacja musi działać (lub przynajmniej nie działać) w środowisku, w którym pamięć lokalna nie jest dostępna.

Wszystkie pliki cookie wygasają w pewnym momencie, ale ludzie mają tendencję do ustawiania czasu życia na kilka lat, co wydaje się wiecznością w czasie Internetu. Z drugiej strony pamięć lokalna nigdy nie wygasa i jest dostępna, dopóki aplikacja lub użytkownik jej nie usunie. Pamięć sesji jest czyszczona po zamknięciu karty lub okna — bez wyjątków.

„Co masz na myśli mówiąc, że tylko struny mogą być uratowane ? Cały czas zapisuję przedmioty!” JSON umożliwia zapisywanie obiektów i innych typów danych w postaci ciągu. Konwersja odbywa się na czytaniu i pisaniu bez Twojej wiedzy. Dzięki bibliotece dźwięków do obsługi plików cookie i pamięci lokalnej nie będziesz musiał myśleć o typach danych. Nie zmienia to jednak faktu, że natywnie obsługiwane są tylko łańcuchy.

Nie ma jednej funkcji po stronie klienta obsługiwanej przez wszystkie przeglądarki . To smutny fakt, ale jednak fakt. Możesz sprawdzić konkretne numery na Czy mogę użyć, ale jeśli chodzi o pliki cookie i pamięć lokalną, zignorowałbym wszystkie przeglądarki, które ich nie obsługują. Są marginalne i poniżej 1%.

Nie możesz uzyskać dostępu do localStorage tylko poprzez przetwarzanie po stronie serwera. Potrzebujesz też JS. Gdy użytkownik zażąda strony, a PHP uruchomi się (lub jakikolwiek język po stronie serwera, którego używasz), aby ją wygenerować, nie będziesz mieć dostępu do żadnych lokalnych danych, sesji ani stałego. Po załadowaniu strony i uruchomieniu JS możesz uzyskać dostęp do lokalnych danych i zrobić wszystko, czego potrzebujesz — dostosować interfejs użytkownika lub użyć AJAX do wysyłania lokalnych danych z powrotem na serwer. Więc tak, możesz odzyskać lokalne dane z powrotem na serwer, ale nie w ten sam sposób i w tym samym momencie, co w przypadku pliku cookie. W zależności od wymagań może to być przełom, jeśli chodzi o przejście z plików cookie na lokalną pamięć masową, więc proszę – planuj z wyprzedzeniem!

W przypadku przechowywania lokalnego żadne dane nie są przesyłane między klientem a serwerem (chyba że istnieje kod, który wyraźnie to robi). Świetnie nadaje się do zmniejszania rozmiaru ładunku. Z kolei pliki cookie są przesyłane jako pole nagłówka HTTP przy każdym żądaniu w ustawionej domenie. Tego nie można zmienić ani selektywnie wyłączyć.

Użytkownicy „nie powinni” uzyskiwać dostępu do danych lokalnych i zmieniać ich bezpośrednio (poza Twoją aplikacją), ale nic ich nie powstrzymuje. Dostępnych jest wiele narzędzi debugowania do edycji przechowywanych lokalnie danych. Dlatego nie ufaj lokalnym danym ani nie zakładaj, że użytkownik ich nie dotknął. Zawsze zakładaj najgorsze.

Chociaż pliki cookie mają atrybut „bezpieczny” , który można ustawić, nie chroni on jednak pliku cookie podczas przesyłania z aplikacji do przeglądarki. Więc to lepsze niż nic, ale daleko od bezpieczeństwa. Pamięć lokalna, będąca technologią tylko po stronie klienta, nie wie ani nie obchodzi, czy używasz protokołu HTTP czy HTTPS. Bezpieczeństwo musi wynikać ze sposobu, w jaki obchodzisz się z danymi. Nie przechowuj żadnych poufnych danych, takich jak numery kart kredytowych lub hasła, w żadnej formie pamięci lokalnej! Kiedykolwiek!

Trochę kodu na początek

Ten artykuł nie ma być samouczkiem dotyczącym przechowywania w Internecie w języku JavaScript, ale aby oszczędzić Ci kłopotów, oto przykład Hello World z pamięcią lokalną;

// 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' ) );

Powyższy kod działa i jest tak prosty, jak to tylko możliwe. Jednak nie polecam go używać. Podobnie jak w przypadku plików cookie, nikt nie używa document.cookies do interakcji z nimi. Istnieją niewielkie różnice między przeglądarkami, które należy wziąć pod uwagę, a ponieważ przechowują one tylko ciągi, musisz ustrukturyzować i przeanalizować za pomocą JSON przy każdym odczycie i zapisie. Dlatego używamy małych bibliotek, które pomagają nam obsługiwać pliki cookie, takie jak js-cookie. To samo dotyczy pamięci lokalnej. Umieszczenie małej warstwy abstrakcji między kodem a API pomoże na dłuższą metę. Polecam store.js. Działa już od jakiegoś czasu, zajmuje się nonsensami i błędami w różnych przeglądarkach, a nawet ma przydatne wtyczki, które rozszerzają jego funkcje. Jeśli interesuje Cię praktyka kodowania, stwórz własną bibliotekę i przekonwertuj ją na wtyczkę jQuery.

Ciasteczka są złe, prawda? Potrzebujemy czegoś nowego!

Ciasteczka nie są złe. Służą one swoim celom od dziesięcioleci i nadal będą to robić, ponieważ lokalne przechowywanie nie jest zamiennikiem „jabłek za jabłka”. Pliki cookie wykazują jednak oznaki starzenia. Poza tym niektóre z ich niedociągnięć projektowych również nie znikną w najbliższym czasie. Mianowicie „zanieczyszczanie” każdego żądania w domenie ładunkiem cookie i małym maksymalnym rozmiarem ładunku.

Nieodpowiednie i stare lub nie, pliki cookie pozostaną, więc nie myśl, że pamięć lokalna w najbliższym czasie całkowicie przejmie kontrolę. Jednak w niektórych przypadkach lokalna pamięć masowa jest bez wątpienia lepszym wyborem.

Jeśli masz (dużo) danych do przechowywania po stronie klienta, które rzadko są przesyłane na serwer, a dane te nie zawierają niczego wrażliwego – zacznij korzystać z lokalnego magazynu ! Właśnie po to została stworzona. Stworzysz szybszą aplikację, czyniąc wszystkie żądania HTTP w domenie lżejszymi i uzyskasz ciepłe, rozmyte wrażenie używania czegoś nowego.