Setiap situs yang kamu buka perlu mengingat sesuatu. Sesi login kamu, tombol mode gelap yang baru kamu nyalakan, barang-barang di keranjang belanja, sampai draf pesan yang baru kamu ketik separuh — semua itu harus disimpan di suatu tempat pada perangkatmu. Soalnya, halaman web itu sendiri langsung hilang begitu tabnya kamu tutup. Nah, browser menyediakan beberapa “laci” berbeda untuk menyimpan data semacam ini, dan tiap laci punya ukuran, aturan masa simpan, serta keunikannya sendiri.
Buat kamu yang baru terjun ke dunia web, hal ini sering bikin pusing. Orang melempar istilah cookie, localStorage, dan IndexedDB seakan semua orang sudah paham bedanya. Setelah membaca artikel ini, kamu bakal tahu persis apa itu masing-masing, bagaimana perbandingannya, dan mana yang sebaiknya kamu pilih untuk tugas tertentu. Kita bahas santai dan konseptual saja — tidak perlu koding mendalam.
Kenapa browser butuh penyimpanan
Web bekerja dalam potongan-potongan singkat. Browser meminta sebuah halaman ke server, server mengirimkannya balik, lalu hubungannya praktis selesai. Server tidak otomatis “ingat” siapa kamu di antara permintaan-permintaan itu — tiap permintaan dimulai dari nol, seperti berkenalan dengan orang asing berulang kali.
Untuk mengatasinya, browser menyimpan potongan kecil informasi di komputermu dan menyerahkannya kembali saat dibutuhkan. Bayangkan seperti penitipan jas di sebuah gedung pertunjukan: kamu menyerahkan jas, menerima tiket, lalu nanti tiket itu membuktikan bahwa jas tersebut milikmu. Penyimpanan di browser berperan seperti penitipan itu. Berkat penyimpanan ini, situs bisa mengenali kamu, memulihkan pengaturanmu, dan tidak perlu menanyakan hal yang sama setiap saat.
Ada empat pilihan utama yang akan kamu temui, dan keempatnya terbagi dalam dua kubu: penyimpanan yang bisa dilihat server (cookie) dan penyimpanan yang murni tinggal di perangkat (selebihnya).
Cookie: catatan kecil yang ikut di setiap permintaan
Cookie adalah sepotong teks mungil — sepasang nama dan nilai — yang disimpan browser lalu otomatis dilampirkan ke setiap permintaan yang dikirim ke situs yang sama. Bagian terakhir inilah kunci memahami cookie: ia ikut bepergian.
Begini alurnya secara sederhana:
Browser Server
| ---- minta sebuah halaman --> |
| <--- "Set-Cookie: id=abc" -- | (server minta browser menyimpan cookie)
| |
| ---- minta lagi -----------> |
| "Cookie: id=abc" | (browser mengirimnya balik, tiap kali)Karena cookie ikut di setiap permintaan, ia jadi tempat alami untuk hal-hal yang perlu diketahui server di tiap kunjungan — yang paling penting, sesi login kamu. Saat kamu masuk, server biasanya memberi browser sebuah cookie sesi, dan sejak itu browser diam-diam membuktikan identitasmu dengan mengirim cookie tersebut di setiap permintaan.
Cookie berukuran kecil. Batas praktisnya sekitar 4 kilobyte per cookie — cukup untuk sebuah ID atau token pendek, tapi tidak untuk menyimpan daftar produk atau gambar. Kamu juga bisa mengatur berapa lama cookie bertahan dan bagaimana perilakunya lewat penanda seperti Expires, Secure, dan HttpOnly.
Cookie dikirim di setiap permintaan
Karena browser melampirkan cookie ke tiap permintaan ke situs itu, menyimpan data besar dalam cookie membuat setiap permintaan jadi lebih berat dan lambat. Jaga cookie tetap mungil, dan jangan pernah menaruh data berukuran besar di sana.
Soal reputasi cookie yang sering dikaitkan dengan pelanggaran privasi: cookie yang melacakmu lintas banyak situs itu adalah cookie pihak ketiga, yang dipasang oleh domain selain yang ada di bilah alamatmu. Cookie pihak pertama biasa yang menjaga kamu tetap login di satu situs adalah alat yang wajar dan berguna — bukan biang masalah.
localStorage: laci sederhana yang tetap di tempatnya
localStorage adalah penyimpanan kunci-nilai (key-value) bawaan browser. Kamu memberinya sebuah nama dan nilai berupa teks, lalu ia menyimpannya — bahkan setelah tab ditutup, browser ditutup, atau komputer dimatikan dan dinyalakan lagi. Datanya tetap di sana sampai kodemu menghapusnya atau pengguna membersihkan data penjelajahannya.
Cara pakainya terbilang sederhana. Kamu simpan, baca, lalu hapus:
// Simpan sebuah nilai
localStorage.setItem("theme", "dark");
// Baca lagi nanti (bahkan setelah perangkat dinyalakan ulang)
const theme = localStorage.getItem("theme"); // "dark"
// Hapus
localStorage.removeItem("theme");Ada dua hal yang membedakan localStorage dari cookie. Pertama, ukurannya jauh lebih besar — browser umumnya mengizinkan sekitar 5 megabyte per situs, sangat cukup untuk preferensi, pengaturan tersimpan, atau sebuah draf. Kedua, dan ini penting, ia tidak pernah dikirim ke server. Datanya sepenuhnya tinggal di browser, jadi tidak memperlambat permintaanmu.
Karena itu localStorage sangat pas untuk preferensi di sisi pengguna: tema yang dipilih pengunjung, panel mana yang ia tutup, atau apakah ia sudah menutup sebuah banner. Kekurangannya, ia hanya menyimpan teks biasa, jadi data yang berstruktur harus diubah dulu ke dan dari format JSON.
localStorage hanya menyimpan teks
Untuk menyimpan objek atau array, ubah dulu dengan JSON.stringify() sebelum disimpan, lalu JSON.parse() saat membacanya kembali. Lupa langkah ini adalah salah satu kesalahan pemula yang paling sering terjadi.
Ada satu aturan keamanan yang wajib kamu tanamkan baik-baik: jangan pernah menyimpan hal sensitif di localStorage. Skrip apa pun yang berjalan di halaman bisa membacanya, jadi kata sandi, token, atau data pribadi sama sekali tidak boleh ditaruh di sana.
sessionStorage: ide yang sama, tapi khusus tab ini saja
sessionStorage bekerja persis seperti localStorage — metode sama, sama-sama hanya menyimpan teks — dengan satu perbedaan penting: ia terikat pada satu tab, dan lenyap begitu tab itu ditutup.
Buka blog.acy-partner.com di dua tab terpisah, dan tiap tab punya sessionStorage-nya sendiri yang terpisah; keduanya tidak berbagi apa pun. Tutup satu tab, datanya hilang. Buka lagi situsnya, kamu mulai dari awal.
Hal ini membuat sessionStorage cocok untuk data sementara berumur pendek yang memang sebaiknya tidak menetap: langkah saat ini pada formulir bertahap, posisi gulir yang ingin kamu pulihkan saat menekan tombol kembali dalam kunjungan yang sama, atau penanda bahwa sebuah popup sudah pernah muncul selama sesi ini. Kalau sesuatu memang harus dilupakan saat pengguna pergi, sessionStorage adalah laci yang tepat.
// Hanya hidup di tab ini, hanya sampai tab ditutup
sessionStorage.setItem("wizardStep", "3");
const step = sessionStorage.getItem("wizardStep"); // "3"IndexedDB: basis data sungguhan di dalam browser
Tiga pilihan pertama bagus untuk nilai-nilai kecil dan sederhana. Tapi bagaimana kalau kamu perlu menyimpan banyak data berstruktur — misalnya ratusan catatan supaya aplikasi web tetap jalan tanpa koneksi internet? Untuk itulah IndexedDB ada. Ini adalah basis data utuh yang tinggal di dalam browser.
Berbeda dari localStorage, IndexedDB sanggup menampung data dalam jumlah besar (sering kali ratusan megabyte atau lebih, tergantung perangkat dan ruang disk yang tersedia). Ia menyimpan objek berstruktur, bukan sekadar teks, dan memungkinkanmu mencari serta mengindeks data tersebut, mirip basis data di server.
Imbalannya adalah kerumitan. IndexedDB memang lebih bertenaga, tapi juga lebih sulit dipakai secara langsung — antarmuka mentahnya bertele-tele dan bekerja lewat event serta permintaan asinkron. Pada proyek nyata, kebanyakan pengembang memilih memakai pustaka bantu kecil yang membungkus IndexedDB dengan perintah yang lebih ramah, ketimbang memanggilnya secara manual.
Kamu memilih IndexedDB ketika datanya terlalu besar atau terlalu berstruktur untuk pilihan yang lebih sederhana: aplikasi email luring yang menyimpan pesan, aplikasi catatan yang menyimpan dokumen, atau aplikasi peta yang menyimpan petak peta untuk wilayah yang sudah kamu unduh.
Kebanyakan aplikasi tidak butuh IndexedDB
Kalau kamu hanya perlu mengingat tema atau status login, cookie dan localStorage sudah cukup. Pakai IndexedDB hanya saat kamu benar-benar perlu menyimpan data besar, berstruktur, dan bisa dicari di perangkat.
Membandingkan keempatnya berdampingan
Berikut gambaran utuhnya dalam satu tempat. Saat memutuskan di mana menyimpan sepotong data, telusuri tabel ini dan pilih baris pertama yang cocok.
| Aspek | Cookie | localStorage | sessionStorage | IndexedDB |
|---|---|---|---|---|
| Batas ukuran umum | ~4 KB | ~5 MB | ~5 MB | Ratusan MB+ |
| Berapa lama bertahan | Sampai masa berlaku yang kamu atur | Sampai dibersihkan | Sampai tab ditutup | Sampai dibersihkan |
| Cakupan | Seluruh situs | Seluruh situs | Satu tab saja | Seluruh situs |
| Dikirim ke server? | Ya, tiap permintaan | Tidak | Tidak | Tidak |
| Jenis data | Teks pendek | Hanya teks | Hanya teks | Objek berstruktur |
| Cocok untuk | Sesi, penanda yang dibaca server | Preferensi, data kecil | Data sementara per tab | Kumpulan data luring besar |
Memilih yang tepat dalam praktik
Sebagian besar keputusan bermuara pada beberapa pertanyaan sederhana.
Pertama: apakah server perlu membaca data ini di setiap permintaan? Kalau ya — sesi login adalah contoh klasiknya — pakai cookie, dan jaga tetap kecil. Kalau datanya hanya penting di browser, lewati cookie sama sekali supaya kamu tidak memperlambat tiap permintaan.
Kedua: berapa lama data harus bertahan? Kalau ia harus selamat dari proses nyala-ulang perangkat (sebuah preferensi tersimpan), pilih localStorage. Kalau ia mestinya lenyap saat tab ditutup (formulir yang belum selesai), pakai sessionStorage.
Ketiga: seberapa banyak datanya, dan seberapa berstruktur? Kalau cuma segelintir nilai kecil, localStorage sudah lebih dari cukup. Kalau berupa kumpulan besar yang bisa dicari — jenis data yang menggerakkan aplikasi luring — di situlah IndexedDB membuktikan gunanya.
Bayangkan sebuah toko daring kecil milik ACY Partner Indonesia. Seorang pembeli bernama Jane Doe masuk: sesinya tinggal di sebuah cookie supaya server mengenalinya. Pilihan bahasa dan setelan mode gelapnya masuk ke localStorage supaya tetap ada di antara kunjungan. Langkah saat ini pada proses checkout-nya berada di sessionStorage supaya teratur ulang kalau ia meninggalkan tab. Dan andai toko itu menawarkan katalog produk luring, ribuan barang tersebut akan tinggal di IndexedDB. Empat jenis data, empat laci, masing-masing dipilih dengan sengaja.
Penutup
Penyimpanan di browser bukan satu hal tunggal — ia adalah kotak perkakas kecil, dan keahliannya terletak pada mencocokkan alat dengan tugasnya. Cookie adalah catatan mungil yang ikut ke server di setiap permintaan, ideal untuk sesi. localStorage adalah laci lapang yang menetap dan tinggal di perangkat, pas untuk preferensi. sessionStorage adalah ide yang sama tapi terbatas pada satu tab dan terhapus saat ditutup. Sementara IndexedDB adalah basis data sungguhan di dalam browser untuk data besar, berstruktur, dan bisa dicari.
Ada dua aturan yang harus selalu kamu ingat di atas segalanya: jangan pernah menaruh data sensitif di penyimpanan yang bisa dibaca skrip apa pun, dan jangan membengkakkan cookie dengan data yang sebenarnya tidak dibutuhkan server. Kalau dua hal ini benar, kamu sudah menghindari kesalahan yang paling sering terjadi.
Dari sini, langkah lanjutan yang wajar adalah menelaah lebih dekat bagaimana penanda cookie seperti Secure, HttpOnly, dan SameSite melindungi sebuah sesi login, serta bagaimana aturan same-origin menentukan halaman mana saja yang boleh membaca sebuah penyimpanan. Detail-detail itu dibangun langsung di atas fondasi yang baru saja kamu pasang.
