DK Damir Khaibulin
🇷🇺 RU Ruso 🇬🇧 EN Inglés 🇩🇪 DE Alemán 🇫🇷 FR Francés 🇮🇹 IT Italiano 🇪🇸 ES Español
Hablemos
← Volver a los artículos
Rendimiento y bases de datos

Caching del navegador: cómo hacer que tu sitio «recuerde» los datos y cargue al instante

Una guía práctica del caching del navegador: encabezados Cache-Control, ETags con respuestas 304, LocalStorage para el estado del cliente y Service Workers para estrategias offline avanzadas.

Hablemos ↗ Leer el artículo
Idiomas disponibles
EN RU DE FR IT ES
Caching del navegador: cómo hacer que tu sitio «recuerde» los datos y cargue al instante
Artículo destacado ↗

Caching del navegador: cómo hacer que tu sitio «recuerde» los datos y cargue al instante

Cache-Control, ETag, LocalStorage — no son magia, sino herramientas esenciales. Entendamos cuándo y cómo usar cada una.

Imagina esto: un usuario visita tu sitio web por segunda vez, pero se carga como si fuera la primera — todos los scripts, estilos e imágenes se descargan de nuevo. Frustración, solicitudes innecesarias, carga adicional en el servidor. ¿Te suena familiar?

La solución es un caching del lado del cliente inteligente. No se trata solo de «acelerar las cosas»; es un principio fundamental para construir aplicaciones web rápidas y receptivas.

Desglosemos tres mecanismos clave que todo desarrollador frontend debería conocer y entender cuándo usar cada uno. Para mayor claridad, incluiré ejemplos en Laravel (el backend a menudo gestiona la configuración del caché).

1. Cache-Control: el director del caching HTTP

Este es un encabezado HTTP que da al navegador instrucciones estrictas sobre cuánto tiempo almacenar un recurso (JS, CSS, imágenes, fuentes).

  • Cache-Control: public, max-age=3600 — almacenar en el caché del navegador y cualquier proxy intermedio durante 1 hora.
  • Cache-Control: no-cache — almacenar en caché, pero siempre verificar la frescura con el servidor.
  • Cache-Control: no-store — no almacenar en caché en absoluto (para datos sensibles).

Cuándo usar: Para todos los recursos estáticos cuyas versiones cambian con poca frecuencia (archivos de build, fuentes, iconos). Usa nombres de archivo con hash (app.a1b2c3.css) para poder establecer max-age durante años.

Ejemplo en Laravel (para assets estáticos): Puedes establecer reglas en .htaccess (Apache) o en la configuración de Nginx, que a menudo es el método preferido. Sin embargo, en Laravel, puedes enviar encabezados al servir assets a través de una ruta o middleware:

// En Middleware o un controlador para servir un asset específico Route::get('/static/{file}', function ($file) { $path = storage_path('app/static/' . $file); return response()->file($path, [ 'Cache-Control' => 'public, max-age=31536000', // 1 año ]); });

2. ETag: verificación ligera de frescura

ETag (Entity Tag) es un digest hash de un recurso generado por el servidor. El navegador guarda el recurso y su ETag. En la siguiente solicitud, envía el ETag en el encabezado If-None-Match. El servidor compara: si el ETag coincide, el recurso no ha cambiado — devuelve una respuesta vacía con estado 304 Not Modified. Esto ahorra ancho de banda y tiempo.

Cuándo usar: Para datos que podrían cambiar, pero verificarlos desde cero cada vez es costoso (listas de productos, artículos, respuestas de API).

Ejemplo en Laravel: Laravel puede generar ETags automáticamente para las respuestas. O puedes hacerlo manualmente:

use Symfony\Component\HttpFoundation\Response; Route::get('/api/products', function () { $products = Product::all(); $content = $products->toJson(); // Crear un ETag basado en el contenido $etag = md5($content); // Verificar si el ETag del cliente coincide con el nuestro if (request()->header('If-None-Match') === $etag) { return response(null, 304); // Not Modified } // Devolver respuesta con ETag return response($content) ->header('Cache-Control', 'no-cache') // Almacenar, pero validar vía ETag ->header('ETag', $etag); });

3. LocalStorage / SessionStorage: caché de datos de la aplicación

Esto no es sobre HTTP, sino sobre la Web Storage API. Un almacén clave-valor completo en el navegador (hasta 5-10 MB). Sincrónico, funciona solo dentro del mismo origen.

  • LocalStorage — persiste para siempre, hasta que se borre.
  • SessionStorage — vive solo durante la sesión (pestaña).

Cuándo usar: Para datos no críticos necesarios para el funcionamiento de la aplicación cliente, donde puedes tolerar la obsolescencia:

  • Token de autorización (¡cuidado! mejor en cookies HttpOnly)
  • Datos no 100% críticos: ajustes de tema de UI, borradores de formularios, resultados rápidos de búsqueda.
  • Estado de la aplicación SPA después de recargar la página.

Ejemplo en frontend (JavaScript):

// Guardar datos de respuesta de API async function loadProducts() { const cached = localStorage.getItem('products'); if (cached) { return JSON.parse(cached); // Retorno instantáneo desde el caché } const response = await fetch('/api/products'); const products = await response.json(); localStorage.setItem('products', JSON.stringify(products)); return products; } // Recuerda invalidar el caché cuando los datos cambien function clearProductCache() { localStorage.removeItem('products'); }

Consejo avanzado: Service Workers para control total

Para tener control total sobre el caching y la funcionalidad offline, considera los Service Workers. Actúan como un proxy de red programable, permitiéndote implementar estrategias como «Cache First, Network Fallback» o «Stale-While-Revalidate».

Resumen: qué, cuándo y por qué

  1. Cache-Control + nombres de archivo con hash — para assets estáticos (CSS, JS, imágenes). Resultado: El navegador los sirve desde el disco, haciendo cero solicitudes de red.
  2. ETag / no-cache — para datos dinámicos y API. Resultado: El navegador hace una solicitud pero recibe una respuesta vacía 304 si los datos no han cambiado.
  3. LocalStorage — para el estado de la aplicación cliente. Resultado: Acceso instantáneo a los datos en visitas repetidas o recargas de página.
  4. Service Worker — para estrategias avanzadas offline y de rendimiento. Resultado: Control total sobre la red y el caché.

La regla de oro: El caching debe ser invalidable. Siempre debe haber un mecanismo para purgar datos obsoletos (mediante cambio de nombre de archivo, actualización de ETag o limpieza manual del LocalStorage).

Una combinación inteligente de estos enfoques reduce el número de solicitudes, ahorra ancho de banda del usuario y hace que la interacción con tu sitio se sienta verdaderamente instantánea. Los usuarios lo agradecerán, y tus Core Web Vitals mejorarán.

Tecnologías y temas

Etiquetas del artículo

No hay artículos que coincidan con estos filtros.

¿Tienes un proyecto o una idea para discutir?

Hablemos ↗