304

Not Modified

El arte del caching HTTP. Optimización, ETags y el secreto de las páginas que cargan al instante.

Redirection

📋 ¿Qué narices es esto?

El código 304 Not Modified es el "no ha cambiado nada, usa lo que ya tienes" de HTTP. Es la estrella del caching inteligente, diseñado para hacer que las páginas carguen al instante sin descargar contenido innecesario. Como el bibliotecario que te dice "ese libro sigue igual, no necesitas una copia nueva".

Este código es pura optimización. Cuando el navegador tiene una versión cacheada de un recurso, pregunta al servidor "¿ha cambiado esto?" con headers como If-Modified-Since o If-None-Match. Si no ha cambiado, el servidor responde con 304 + cero bytes de contenido. El navegador usa su versión local, ahorrando ancho de banda y tiempo de carga.

El 304 aparece típicamente con:

  • Imágenes, CSS, JS que no han cambiado
  • Páginas con ETags o Last-Modified
  • APIs que devuelven los mismos datos
  • CDNs optimizando transferencias
  • Cualquier recurso con validación de cache

🎯 Dato curioso

El 304 es el único código 3xx que NO es una redirección. Técnicamente es "usar el recurso que ya tienes". Es HTTP diciéndote "ahorra tiempo y datos, genio".

La magia del 304 es que no envía cuerpo de respuesta, solo headers. El servidor hace la validación (fechas, ETags) y si nada cambió, responde prácticamente vacío. Es la diferencia entre descargar 2MB otra vez y confirmar en milisegundos que no necesitas hacerlo.

🔧 Cómo implementar esto

🖥️ Para servidores (validación de cache)

  1. Envía Last-Modified/ETag: En la respuesta inicial del recurso.
  2. Recibe If-Modified-Since/If-None-Match: El navegador pregunta si cambió.
  3. Valida el recurso: Compara fechas/hashes del contenido actual.
  4. Responde 304 si igual: Sin cuerpo, solo headers de validación.
  5. Navegador usa cache local: Carga instantánea del recurso.

📱 Para desarrolladores frontend

  1. Configura cache headers: En servidor web o aplicación.
  2. Usa ETags para contenido dinámico: Hash del contenido actual.
  3. Last-Modified para archivos: Fecha de modificación del archivo.
  4. Testea con DevTools: Network tab muestra 304s.
  5. Monitorea performance: Menos transferencias = mejor UX.

Problemas típicos con 304

  • Falta de headers de validación:
    Si no envías ETag o Last-Modified, el navegador no puede pedir 304 y siempre descargará el recurso completo.
  • Errores de sincronización de fechas:
    Si el servidor y el cliente tienen relojes desincronizados, puede que nunca se devuelva 304 aunque el recurso no haya cambiado.
  • ETags mal generados:
    Si el ETag cambia aunque el contenido sea igual (por ejemplo, incluye timestamp), el navegador nunca recibirá 304 y perderás el beneficio del cache.
  • Confusión con redirecciones:
    El 304 no es una redirección. Si tu app espera una URL nueva, no uses 304.

🚀 Respuesta rápida para emergencias

🔥 Si nunca ves 304 en DevTools:
1. Comprueba que el servidor envía ETag o Last-Modified.
2. Revisa que el navegador no tenga el cache desactivado.
3. Testea con recursos estáticos (CSS, JS, imágenes).
⚡ Si el recurso siempre se descarga completo:
1. Verifica que el ETag no cambie innecesariamente.
2. Asegúrate de no modificar la fecha de archivo sin cambios reales.
3. Comprueba la configuración de proxies/CDN.
🎯 Truco de optimización:
Combina Cache-Control con ETag y Last-Modified para máxima eficiencia. Así el navegador decide cuándo preguntar y cuándo reutilizar.