Fundamentos de Caché que Todo Desarrollador Web Debería Conocer

Feb 24, 2026 · 4 min read

Fundamentos de Caché que Todo Desarrollador Web Debería Conocer

Tus usuarios acaban de hacer clic en un botón y no pasó nada durante tres segundos. La consulta a la base de datos finalizó, el servidor respondió, pero los mismos datos que se cargaron ayer tuvieron que viajar a través de toda internet nuevamente. Este es el problema que resuelve el caché.

Comprender los fundamentos del caché HTTP no es opcional para los desarrolladores frontend. Es la diferencia entre una aplicación ágil y una que se siente rota. Esta guía cubre lo que necesitas saber sobre caché del navegador vs. caché CDN, encabezados Cache-Control y mecanismos de validación como ETag y Last-Modified.

Puntos Clave

Establece encabezados Cache-Control explícitos en cada respuesta para evitar heurísticas impredecibles del navegador.
Usa valores largos de max-age combinados con cache busting (nombres de archivo con hash de contenido) para recursos estáticos.
Usa no-cache con ETag o Last-Modified para contenido que debe mantenerse actualizado.
Siempre marca el contenido personalizado o autenticado como private para evitar fugas de datos a través de cachés compartidos.

Qué Es el Caché y Por Qué Importa

El caché almacena una copia de datos más cerca de donde se necesitan. Cuando tu navegador solicita una imagen, puede guardar esa imagen localmente. La siguiente solicitud omite completamente la red.

Las mejoras de rendimiento son dramáticas. Por ejemplo, una consulta a la base de datos puede tomar decenas de milisegundos, mientras que leer desde un caché del navegador es típicamente casi instantáneo y evita completamente un viaje de ida y vuelta por la red.

El caché ofrece tres beneficios principales:

Latencia reducida: Los datos viajan distancias más cortas.
Menor carga del servidor: Menos solicitudes llegan a tu origen.
Mejor experiencia de usuario: Las páginas cargan más rápido en visitas repetidas.

Entendiendo las Capas de Caché

Las solicitudes pasan por múltiples cachés antes de llegar a tu servidor. Cada capa sirve un propósito diferente.

Caché del Navegador (Caché Privado)

El caché del navegador reside en el dispositivo del usuario. Almacena respuestas que solo ese usuario debería ver. Cuando marcas una respuesta como private, permanece aquí y nunca se comparte con otros usuarios.

Aquí es donde pertenece el contenido personalizado: perfiles de usuario, respuestas de API autenticadas, cualquier cosa vinculada a una sesión específica.

Caché CDN (Caché Compartido)

Un caché CDN se sitúa entre los usuarios y tu servidor de origen, distribuido en ubicaciones geográficas. Cuando un usuario en Tokio solicita tu bundle de JavaScript, el CDN lo sirve desde un servidor edge cercano en lugar de tu centro de datos de origen.

Los CDN sobresalen en el almacenamiento en caché de recursos estáticos: imágenes, CSS, JavaScript y fuentes. También pueden almacenar en caché respuestas de API públicas, aunque esto requiere una configuración cuidadosa.

Caché del Lado del Servidor

Más allá del caché HTTP, los servidores a menudo mantienen sus propios cachés usando herramientas como Redis o Memcached. Como desarrollador frontend, no configurarás estos directamente, pero entender que existen te ayuda a razonar por qué algunas respuestas de API son más rápidas que otras.

Encabezados Cache-Control: Las Directivas Principales

El encabezado Cache-Control indica a los cachés cómo manejar las respuestas. Estas son las directivas que usarás con más frecuencia:

Directiva	Significado
`max-age=3600`	Almacenar en caché durante 3600 segundos (1 hora)
`no-cache`	Almacénalo, pero revalida antes de usar
`no-store`	No almacenes esta respuesta en ningún lugar
`private`	Solo el caché del navegador puede almacenar esto
`public`	Cualquier caché puede almacenar esto

Un error común: no-cache no significa “no almacenar en caché”. Significa “siempre verifica con el servidor antes de usar la copia en caché”. Usa no-store cuando realmente no quieras ningún tipo de caché.

Para recursos estáticos con nombres de archivo con hash, usa caché agresivo:

Cache-Control: public, max-age=31536000

Para páginas HTML que cambian frecuentemente (y especialmente para contenido sensible o altamente dinámico):

Cache-Control: no-cache, private

ETag y Last-Modified: Mecanismos de Validación

Cuando el contenido en caché expira, los navegadores no siempre necesitan descargar todo nuevamente. Los encabezados de validación permiten una revalidación eficiente.

Last-Modified contiene una marca de tiempo. En solicitudes posteriores, el navegador envía un encabezado If-Modified-Since con esa marca de tiempo. Si nada cambió, el servidor devuelve 304 Not Modified — sin cuerpo, ancho de banda mínimo.

ETag contiene un identificador único (a menudo un hash de contenido). En solicitudes posteriores, el navegador envía un encabezado If-None-Match con ese identificador. Mismo resultado: un 304 si el contenido no ha cambiado.

Los ETags son más precisos que las marcas de tiempo porque detectan cambios reales de contenido, no solo tiempos de modificación de archivos. Un archivo podría volver a guardarse sin cambiar su contenido, actualizando su marca de tiempo pero no su ETag.

Cache Busting para Recursos Estáticos

Quieres que los recursos estáticos se almacenen en caché el mayor tiempo posible, pero también necesitas que los usuarios obtengan actualizaciones cuando despliegues. El cache busting resuelve esto cambiando la URL cuando el contenido cambia.

Las herramientas de construcción modernas agregan hashes de contenido a los nombres de archivo:

bundle.a1b2c3d4.js
styles.e5f6g7h8.css

Cuando despliegues código nuevo, el hash cambia, la URL cambia y los navegadores obtienen la nueva versión. Los archivos antiguos en caché simplemente expiran naturalmente.

Errores Comunes a Evitar

Almacenar en caché contenido autenticado públicamente: Siempre usa private para datos específicos del usuario. Filtrar los datos de un usuario a otro a través de un caché compartido es un problema de seguridad grave.

Almacenar en caché excesivamente respuestas de API: Los datos dinámicos necesitan TTLs cortos o no-cache. Precios obsoletos durante el checkout causan problemas reales.

Olvidar establecer encabezados: Sin encabezados Cache-Control explícitos, los navegadores pueden aplicar caché heurístico basado en metadatos de respuesta, lo que puede llevar a comportamientos que no pretendías.

Conclusión

El caché no es algo que configures una vez y olvides. Establece encabezados Cache-Control explícitos en cada respuesta. Combina valores largos de max-age con nombres de archivo con hash de contenido para recursos estáticos. Usa no-cache junto con ETag o Last-Modified para contenido que debe mantenerse actualizado, y siempre marca el contenido personalizado como private. Verifica tus encabezados en DevTools, confirma el comportamiento de tu CDN y prueba lo que los usuarios realmente experimentan.

Preguntas Frecuentes

no-cache le indica al navegador que puede almacenar la respuesta pero debe revalidar con el servidor antes de usarla. no-store le indica al navegador que no guarde la respuesta en absoluto. Usa no-store para datos sensibles como detalles bancarios, y no-cache para contenido que cambia a menudo pero se beneficia de la revalidación condicional.

Abre las DevTools de tu navegador, ve a la pestaña Network y selecciona cualquier solicitud. La sección Response Headers muestra los valores de Cache-Control, ETag y Last-Modified. Mira también la columna de tamaño. Si dice disk cache o memory cache, la respuesta se sirvió desde el caché del navegador en lugar de la red.

Depende de los datos. Los datos públicos que rara vez cambian, como categorías de productos, pueden usar valores cortos de max-age. Los datos específicos del usuario o que cambian frecuentemente deberían usar no-cache con encabezados de validación o no-store. Siempre marca las respuestas autenticadas como private para evitar que los CDN sirvan los datos de un usuario a otro.

Los hashes de contenido te permiten establecer tiempos de vida de caché muy largos para recursos estáticos mientras sigues entregando actualizaciones instantáneamente. Cuando el contenido del archivo cambia, el hash cambia, produciendo una nueva URL que evita cualquier caché existente. Esta técnica se llama cache busting y es el enfoque estándar utilizado por herramientas como Webpack, Vite y Rollup.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.