Explorando el Almacenamiento en Navegadores: Una Comparativa de Cookies, LocalStorage, SessionStorage e IndexedDB

La evolución de las redes móviles ha dado lugar a las "Web Apps", que ofrecen una experiencia de usuario fluida y accesible al instante, similar a las aplicaciones nativas. Parte del rendimiento excepcional de estas Web Apps se debe a los avances en las tecnologías de almacenamiento del navegador. Las capacidades de almacenamiento de las cookies han demostrado ser insuficientes para las demandas actuales, siendo gradualmente reemplazadas por Web Storage e IndexedDB. Este artículo detallará las diferencias, ventajas y desventajas de estos métodos de almacenamiento.

  1. Cookies

1.1 Origen de las Cookies

Originalmente, las cookies no fueron diseñadas para el almacenamiento local, sino para "mantener el estado". Dado que el protocolo HTTP es sin estado, no conserva la comunicación entre peticiones y respuestas. Esto dificultaba la creación de aplicaciones web interactivas. En un escenario de compra en línea, un servidor no podría rastrear los artículos que un usuario ha añadido a su carrito a través de múltiples páginas sin un mecanismo adicional. Las cookies surgieron como una solución para superar la naturaleza sin estado de HTTP, permitiendo a los servidores configurar o leer cookies para mantener el estado de la sesión del usuario.

Podemos conceptualizar las cookies como pequeños archivos de texto almacenados en el navegador que se adjuntan a las solicitudes HTTP, transitando entre el navegador y el servidor. Pueden portar información del usuario, permitiendo al servidor identificar el estado del cliente al inspeccionar las cookies.

1.2 ¿Qué son las Cookies y Escenarios de Aplicación?

Las cookies son datos (generalmente cifrados) que algunos sitios web almacenan en el terminal local del usuario para identificarlo. Son generadas por el servidor y mantenidas y almacenadas por el cliente. Mediante las cookies, el servidor puede identificar el origen de una petición y mantener el estado del cliente. Por ejemplo, al iniciar sesión y recargar la página, la petición subsiguiente incluirá la cookie establecida por el servidor, permitiendo al servidor reconocer al usuario y restaurar su información de estado.

Las cookies se presentan en formato de clave-valor. Los escenarios de aplicación típicos incluyen:

  • Recordar contraseñas para iniciar sesión automáticamente.
  • Funcionalidad de carrito de compras.
  • Registrar datos de navegación del usuario para recomendaciones de productos o anuncios.

1.3 Principio y Método de Generación de Cookies

Principio de las Cookies

La primera vez que se visita un sitio web, el navegador realiza una petición. El servidor responde e incluye una opción Set-Cookie en la cabecera de la respuesta. En la segunda petición del navegador, la información de la cookie se envía de vuelta al servidor a través de la cabecera Cookie. El servidor puede entonces identificar al usuario. Además, la fecha de caducidad, el dominio, la ruta y la validez de la cookie pueden especificarse según sea necesario.

Métodos de Generación de Cookies

Existen dos métodos principales para generar cookies:

  • Cabecera de respuesta HTTP Set-Cookie: Podemos especificar el valor de la cookie a almacenar en la cabecera Set-Cookie de la respuesta. Por defecto, el dominio se establece en el nombre de host de la página que establece la cookie, pero se puede configurar manualmente.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2018 07:28:00 GMT; // Se puede especificar una hora de caducidad o Max-Age

Cuando se establece la fecha de caducidad de una cookie, esta está relacionada con el cliente y no con el servidor.

  1. Lectura/escritura en JavaScript a través de document.cookie: Las cookies se muestran en formato de clave-valor.

document.cookie="userName=hello";
document.cookie="gender=male";
document.cookie='age=20;domain=.example.com'; // Establecer dominio

El atributo domain especifica qué dominios pueden acceder a la cookie. Si no se establece, se enlaza automáticamente al dominio actual donde se ejecuta la declaración. Si se establece como .example.com, todos los dominios que terminen en example.com pueden acceder a esta cookie.

1.4 Deficiencias de las Cookies

  • Tamaño limitado: Las cookies tienen una restricción de tamaño de aproximadamente 4KB. Esto es insuficiente para necesidades de almacenamiento complejas. Si una cookie excede este límite, se truncará. Por lo tanto, las cookies solo son adecuadas para almacenar pequeñas cantidades de información. Además, muchos navegadores imponen límites al número de cookies por sitio. (Nota: Este límite de 4KB se aplica al valor de cada par name=value, no al total de cookies para un dominio).
  • Desperdicio de rendimiento: Las cookies se adjuntan a las solicitudes basadas en el dominio. Todas las solicitudes a un mismo dominio enviarán las cookies. Incluso para solicitudes de recursos estáticos como imágenes o archivos CSS, se enviarán cookies que pueden no ser necesarias, lo que resulta en un desperdicio considerable. Aunque las cookies individuales son pequeñas, el gran volumen de solicitudes puede acumularse, generando una sobrecarga significativa. Para mitigar esto, se pueden separar los dominios de los archivos estáticos (por ejemplo, usando una CDN) de los dominios del sitio principal.
  • Problemas de seguridad: Las cookies se transmiten en texto plano en las solicitudes HTTP, lo que las hace vulnerables a la interceptación, a menos que se utilice HTTPS.

1.5 Cookies y Seguridad

La seguridad es una preocupación importante con las cookies. El atributo HttpOnly impide que scripts como document.cookie accedan o modifiquen la cookie, protegiéndola contra ataques de Cross-Site Scripting (XSS). Las cookies marcadas como HttpOnly solo deben ser enviadas al servidor y no ser accesibles por JavaScript en el lado del cliente.


Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Las cookies marcadas como Secure solo deben enviarse a través de conexiones HTTPS cifradas. Sin embargo, incluso con la marca Secure, la información sensible no debe transmitirse a través de cookies debido a su inseguridad inherente.

Para abordar las limitaciones de las cookies y asignar responsabilidades especializadas, surgió Web Storage, introducido en HTML5. Web Storage se divide en dos categorías: sessionStorage y localStorage. Con Web Storage, las cookies pueden centrarse en su función principal: actuar como canal de comunicación entre el cliente y el servidor para mantener el estado de la sesión.

  1. LocalStorage

2.1 Características de LocalStorage

  • Los datos almacenados persisten a largo plazo; la próxima vez que se visite el sitio, los datos previamente guardados se pueden leer directamente.
  • Tiene un tamaño de almacenamiento de aproximadamente 5MB.
  • Opera únicamente en el lado del cliente y no se comunica con el servidor.
  • Ofrece una interfaz de programación fácil de usar.

Debido a estas características, localStorage puede servir como una solución de caché local en el navegador, mejorando la velocidad de renderizado inicial de la página al almacenar información invariable recuperada en la primera petición.

2.2 Almacenamiento y Recuperación de Datos

localStorage almacena datos en formato de clave-valor, donde cada elemento tiene un nombre de clave y un valor asociado. Todos los datos se guardan como texto.

Para almacenar datos, se utiliza el método setItem, que toma dos argumentos: el nombre de la clave y el valor a almacenar.


localStorage.setItem("clave", "valor");

Para recuperar datos, se utiliza el método getItem, que toma un solo argumento: el nombre de la clave.


var valorLocal = localStorage.getItem("clave");

Un ejemplo práctico:


// Almacenamiento
if (window.localStorage) {
 localStorage.setItem('nombre', 'mundo');
 localStorage.setItem('genero', 'femenino');
}

// Recuperación y visualización
var nombreGuardado = localStorage.getItem("nombre");
var generoGuardado = localStorage.getItem("genero");

document.getElementById("nombre").innerHTML = nombreGuardado;
document.getElementById("genero").innerHTML = generoGuardado;

2.3 Escenarios de Uso

localStorage es flexible para el almacenamiento. Cualquier tarea de almacenamiento de datos que pueda realizarse con simples pares clave-valor y que no sea manejable por las cookies puede ser delegada a localStorage. Por ejemplo, debido a su persistencia, localStorage es ideal para almacenar recursos con contenido estable, como cadenas de imágenes en formato Base64 en sitios de comercio electrónico con mucho contenido visual.

  1. SessionStorage

sessionStorage almacena datos para una única sesión del navegador. Los datos se borran cuando la sesión finaliza (generalmente al cerrar la ventana). Una característica distintiva de sessionStorage es que, incluso para páginas con el mismo dominio, si no se abren en la misma ventana del navegador, su contenido de sessionStorage no se comparte. En contraste, localStorage se comparte entre todas las ventanas del mismo origen, al igual que las cookies.

Aparte de la duración de almacenamiento, los atributos y métodos de sessionStorage son idénticos a los de localStorage.

3.1 Características de SessionStorage

  • Almacenamiento a nivel de sesión del navegador.
  • Tamaño de almacenamiento de aproximadamente 5MB.
  • Opera únicamente en el lado del cliente y no se comunica con el servidor.
  • Ofrece una interfaz de programación fácil de usar.

Estas características hacen que sessionStorage sea útil para mantener información de formularios o datos temporales que no deben persistir más allá de la sesión actual, como evitar la pérdida de datos del formulario al refrescar la página.

3.2 Escenarios de Uso

sessionStorage es más adecuado para almacenar información a nivel de sesión cuya vida útil se sincroniza con la del navegador. Por ejemplo, sessionStorage en plataformas como Weibo podría almacenar el historial de navegación de la sesión actual. La variable lasturl podría corresponder a la URL visitada anteriormente, actualizándose dinámicamente y liberándose cuando se cierra la página, ya que su retención carecería de sentido.

3.3 Diferencias entre SessionStorage, LocalStorage y Cookies

  • Similitudes: Todos se almacenan en el lado del navegador y están sujetos a la política del mismo origen.
  • Diferencias: Se centran en la vida útil y el ámbito de aplicación.
    • Ámbito: localStorage es accesible si el protocolo, el nombre de host y el puerto son idénticos. sessionStorage es más estricto, requiriendo además que los datos se encuentren en la misma ventana (pestaña) del navegador.
    • Vida Útil: localStorage ofrece almacenamiento local persistente sin fecha de caducidad; los datos solo se eliminan manualmente. sessionStorage es un almacenamiento local temporal, a nivel de sesión, y los datos se liberan al cerrar la página.

Web Storage es una herramienta sencilla tanto en definición como en uso. Almacena datos en pares clave-valor, similar a objetos, pero solo puede almacenar cadenas. Para obtener objetos, se requiere un análisis previo de la cadena. En esencia, Web Storage es una extensión de las cookies, limitada al almacenamiento de pequeñas cantidades de datos simples. Para datos extensos y estructurados, Web Storage resulta insuficiente, lo que nos lleva a nuestra solución definitiva: IndexedDB.

  1. IndexedDB

IndexedDB es una API de bajo nivel para almacenar grandes cantidades de datos estructurados (incluidos archivos y blobs) en el lado del cliente. Utiliza índices para búsquedas de datos de alto rendimiento. IndexedDB es una base de datos no relacional que se ejecuta en el navegador. A diferencia de los límites de 5MB o 10MB de Web Storage, IndexedDB no tiene un límite de almacenamiento teórico estricto (generalmente no inferior a 250MB) y puede almacenar no solo cadenas, sino también datos binarios.

4.1 Características de IndexedDB

  • Almacenamiento Clave-Valor: IndexedDB utiliza "almacenes de objetos" (object stores) para guardar datos. Puede almacenar directamente cualquier tipo de dato, incluidos objetos JavaScript. Los datos se guardan como pares clave-valor, y cada registro de datos tiene una clave principal única.
  • Asíncrono: Las operaciones de IndexedDB no bloquean el navegador, permitiendo al usuario realizar otras acciones. Esto contrasta con localStorage, cuyas operaciones son síncronas. El diseño asíncrono previene la ralentización del rendimiento de la página debido a operaciones de lectura/escritura de grandes volúmenes de datos.
  • Soporte de Transacciones: IndexedDB admite transacciones, lo que significa que si un paso dentro de una serie de operaciones falla, toda la transacción se cancela y la base de datos se revierte a su estado anterior, evitando la modificación parcial de datos.
  • Restricción de Mismo Origen: IndexedDB está sujeto a la política del mismo origen; cada base de datos corresponde al dominio que la creó. Las páginas solo pueden acceder a las bases de datos bajo su propio dominio.
  • Gran Espacio de Almacenamiento: IndexedDB ofrece un espacio de almacenamiento considerablemente mayor que localStorage, generalmente no inferior a 250MB y potencialmente ilimitado.
  • Soporte para Almacenamiento Binario: IndexedDB puede almacenar no solo cadenas, sino también datos binarios (objetos ArrayBuffer y Blob).

4.2 Operaciones Comunes de IndexedDB

La mayoría de las operaciones de IndexedDB no siguen el patrón común de llamar a métodos y recibir resultados, sino que utilizan un modelo de solicitud-respuesta.

  • Abrir/Crear IndexedDB: window.indexedDB.open("nombreDB") Esta instrucción no devuelve directamente un objeto DB, sino un objeto IDBOpenDBRequest. El objeto DB deseado se encuentra en su propiedad result. Además de result, la interfaz IDBOpenDBRequest define propiedades importantes como onerror (manejador de callback para fallos de solicitud) y onsuccess (manejador de callback para éxito de solicitud), y onupgradeneeded (manejador para cambios de versión de la base de datos).

    
   function abrirDB(nombre) {
       var peticion = window.indexedDB.open(nombre); // Abrir o crear IndexedDB

       peticion.onerror = function(e) {
           console.log("Error al abrir IndexedDB");
       };

       peticion.onsuccess = function(e) {
           myDB.db = e.target.result; // Este es un objeto IDBDatabase, el objeto IndexedDB
           console.log(myDB.db); // Aquí se puede obtener la instancia de db
       };
   }

   var myDB = {
       nombre: "miBaseDeDatos",
       version: "1",
       db: null
   };

   abrirDB(myDB.nombre);

    En la consola se obtendrá un objeto IDBDatabase, que es el objeto IndexedDB.

  • Cerrar IndexedDB: db.close() ```javascript

      function cerrarDB(db) {
      db.close();
  }

  • Eliminar IndexedDB: window.indexedDB.deleteDatabase(nombreDB) ```javascript

      function eliminarDB(nombre) {
      indexedDB.deleteDatabase(nombre);
  }

4.3 Diferencias entre Web Storage, Cookies e IndexedDB

Como se puede observar en la tabla anterior (implícita en la discusión), las cookies ya no se recomiendan para el almacenamiento. Para necesidades de almacenamiento de datos que no sean masivas, se pueden utilizar localStorage y sessionStorage. Es preferible usar localStorage para datos que cambian poco y sessionStorage para los que sí.

Conclusión

La aparición y el desarrollo de tecnologías de almacenamiento y caché en el navegador han abierto posibilidades ilimitadas para las aplicaciones front-end. En los últimos años, han surgido numerosas bibliotecas de terceros basadas en tecnologías de almacenamiento y caché, y se han desarrollado modelos de aplicaciones web avanzados como PWA. Los puntos clave de este artículo son:

  • La función principal de las cookies no es el almacenamiento local, sino "mantener el estado".
  • Web Storage es un mecanismo de almacenamiento de datos proporcionado específicamente para el almacenamiento en el navegador por HTML5, que no se comunica con el servidor.
  • IndexedDB se utiliza para almacenar grandes volúmenes de datos estructurados en el lado del cliente.

Etiquetas: Almacenamiento Web Cookies localstorage sessionstorage IndexedDB

Publicado el 7-3 17:07

Etiquetas populares

©2026 Friki Work