localStorage y sessionStorage son dos mecanismos proporcionados por la API Web Storage, un estándar integrado en todos los navegadores modernos. Permiten a los sitios web almacenar pares clave-valor directamente en el navegador del visitante, sin involucrar al servidor en cada carga de página. Si alguna vez has activado el modo oscuro en un sitio web y has comprobado que tu preferencia seguía allí al día siguiente, lo más probable es que el sitio guardara esa elección en localStorage.
Cómo funciona la API Web Storage
La API Web Storage es intencionadamente simple. Llamas a localStorage.setItem('key', 'value') para escribir datos, localStorage.getItem('key') para leerlos y localStorage.removeItem('key') para eliminarlos. sessionStorage usa exactamente los mismos métodos. Ambos almacenes solo aceptan cadenas de texto, así que los objetos suelen serializarse con JSON.stringify() antes de guardarse. No hay lenguaje de consulta, ni indexación, ni estructura relacional. Es un almacén plano de clave-valor diseñado para lecturas y escrituras rápidas y ligeras.
localStorage frente a sessionStorage: diferencias clave
- Persistencia: los datos de localStorage permanecen en el navegador hasta que el usuario o el sitio los eliminen explícitamente. No hay fecha de caducidad. Los datos de sessionStorage, en cambio, se borran en el momento en que se cierra la pestaña del navegador.
- Ámbito entre pestañas: localStorage se comparte entre todas las pestañas y ventanas que pertenecen al mismo origen (protocolo + dominio + puerto). sessionStorage está aislado a una única pestaña. Si abres la misma página en dos pestañas, cada una tiene su propio sessionStorage.
- Límites de almacenamiento: ambos suelen ofrecer entre 5 y 10 MB por origen, dependiendo del navegador. Chrome y Firefox usan por defecto unos 5 MB por origen para cada almacén. Safari puede ser más estricto, especialmente en modo de navegación privada, donde a veces limita el almacenamiento a tan solo unos cientos de kilobytes.
- Comportamiento en red: ni localStorage ni sessionStorage se envían al servidor con las peticiones HTTP. Esta es la diferencia fundamental respecto a las cookies, que se adjuntan automáticamente a la cabecera de cada petición.
Qué almacenan habitualmente los sitios WordPress
Los plugins y temas de WordPress utilizan el almacenamiento del navegador para una gran variedad de propósitos. Estos son los más comunes:
- Preferencias del tema: interruptores de modo oscuro, estado contraído/expandido de la barra lateral, opciones de tamaño de fuente. Casi siempre se guardan en localStorage porque deben sobrevivir al cierre de la pestaña.
- Datos del carrito de la compra: WooCommerce y plugins similares a veces almacenan en caché fragmentos del carrito en localStorage para evitar viajes adicionales al servidor cuando se muestra el mini-carrito en la cabecera.
- Borradores de formularios: los plugins de formularios de contacto pueden autoguardar la entrada del usuario en sessionStorage para que un formulario parcialmente rellenado no se pierda si el usuario navega accidentalmente fuera y luego vuelve mediante el botón Atrás.
- Decisiones de consentimiento de cookies: algunos plugins de banner de consentimiento (como Complianz o CookieYes) almacenan el estado de consentimiento del visitante en localStorage en lugar de en una cookie, aunque usar una cookie es más común.
- Estado de la interfaz de administración: el propio panel de administración de WordPress utiliza ambos mecanismos de almacenamiento. Por ejemplo, recuerda qué metaboxes están contraídos, qué columnas son visibles en la lista de entradas y si el menú de administración está plegado.
- Buffers de analítica y seguimiento: algunos scripts de analítica agrupan eventos en localStorage y los envían al servidor en lotes para reducir las peticiones de red.
Consideraciones de seguridad
Web Storage es cómodo, pero tiene compromisos reales en seguridad que los desarrolladores deben entender.
- Exposición a XSS: cualquier JavaScript que se ejecute en la página puede leer localStorage y sessionStorage. Si un atacante consigue inyectar un script a través de una vulnerabilidad de cross-site scripting (XSS), puede extraer todos los valores almacenados. Las cookies pueden protegerse con la marca
HttpOnly, que bloquea por completo el acceso desde JavaScript. No existe una protección equivalente para Web Storage. - Política del mismo origen: el almacenamiento está limitado al origen, lo que significa que
https://ejemplo.comno puede leer el almacenamiento dehttps://otro.com. Sin embargo, cualquier script en el mismo origen, incluidos scripts de terceros que cargues (analítica, redes publicitarias, widgets de chat), tiene acceso completo al mismo almacenamiento. - Sin cifrado: los datos se guardan en texto plano en disco. Cualquiera con acceso físico al dispositivo, o malware que se ejecute en él, puede leerlos. Nunca almacenes contraseñas, tokens u otras credenciales sensibles en Web Storage.
- Sin validación del lado del servidor: como los datos viven solo en el navegador, un usuario o un script puede modificarlos libremente. Nunca confíes en valores de Web Storage para decisiones de autorización o seguridad en el servidor.
Implicaciones del RGPD y la privacidad
Bajo el RGPD y la Directiva ePrivacy, localStorage y sessionStorage se tratan igual que las cookies en cuanto a requisitos de consentimiento. El principio legal es neutro respecto a la tecnología: si almacenas o lees información en el dispositivo de un usuario para un propósito que no es estrictamente necesario para el servicio que el usuario ha solicitado, necesitas consentimiento. Esto significa que un carrito de WooCommerce almacenado en localStorage probablemente sea "estrictamente necesario" y no requiera consentimiento. Pero un identificador de analítica almacenado en localStorage para rastrear visitantes recurrentes sí lo requiere absolutamente. Muchos propietarios de sitios pasan esto por alto porque las herramientas de consentimiento de cookies tradicionalmente se centran en cookies, pero los reguladores han dejado claro que las normas se aplican a todas las tecnologías de almacenamiento del lado del cliente.
Web Storage frente a cookies: cuándo usar cada uno
- Usa cookies: cuando el servidor necesita leer el valor en cada petición (IDs de sesión, tokens de autenticación), cuando necesitas la protección
HttpOnlycontra XSS o cuando necesitas un control fino de la caducidad. - Usa localStorage: cuando necesitas persistir preferencias del lado del cliente o almacenar datos en caché entre sesiones, los datos no necesitan viajar al servidor y los datos no son sensibles.
- Usa sessionStorage: cuando los datos solo deben vivir durante la duración de una única sesión de pestaña, como el progreso de un asistente de formulario, estado temporal de la interfaz o tokens de redirección de un solo uso.
Comparación de rendimiento
Leer y escribir en Web Storage es síncrono y ocurre en el hilo principal. Para pequeñas cantidades de datos esto es rápido, normalmente por debajo de un milisegundo. Pero si una página escribe o lee grandes volúmenes de datos en cada interacción, puede provocar tirones. Las cookies, en cambio, añaden sobrecarga de otra forma: aumentan el tamaño de la cabecera de cada petición HTTP, lo que ralentiza cada llamada de red. Para almacenar un puñado de pequeños valores, ambos enfoques rinden bien. Para conjuntos de datos más grandes (decenas de KB o más), considera IndexedDB, que es asíncrona y no bloquea el hilo principal.
Cómo inspeccionar el almacenamiento en DevTools
Todos los navegadores principales permiten inspeccionar Web Storage. En Chrome, abre DevTools (F12), ve a la pestaña Application y busca "Local Storage" y "Session Storage" en la barra lateral izquierda. Puedes ver cada par clave-valor, editar valores manualmente y eliminar entradas. Firefox tiene un panel similar bajo la pestaña Storage. Esta es la forma más fácil de ver exactamente qué guarda un sitio WordPress en tu navegador y de solucionar comportamientos inesperados.
Qué comprueba InspectWP
InspectWP lista todas las entradas de localStorage y sessionStorage establecidas por tu sitio WordPress durante el rastreo. Esto te da una imagen clara de lo que tu sitio almacena en el lado del cliente, qué plugins son responsables y si alguna entrada podría plantear problemas de privacidad bajo el RGPD o las normas de ePrivacy.