Ir al contenido 
HTTP Condicional Las peticiones reducen los costes de transmisión al garantizar que el cliente sólo cargue un recurso por completo si realmente se ha modificado desde la última petición. Mostraré cómo Validación de la caché con ETag, Last-Modified, If-None-Match, If-Modified-Since y 304 Not Modified funciona de forma fiable y los tiempos de carga se reducen notablemente.
Puntos centrales
- Validación en lugar de la descarga completa: 304 ahorra ancho de banda y tiempo.
- ETag y Last-Modified trabajan juntos para un control limpio.
- Control de la caché define la frescura, caduca sólo suplementos.
- Condiciones previas como los procesos de escritura segura If-Match.
- Seguridad requiere private/no-store para contenidos sensibles.
Qué hacen las peticiones condicionales en la vida cotidiana
He puesto Condicional para plantear al servidor una pregunta clara: ¿Realmente necesito transferir nuevos datos o mi caché es suficiente? El navegador o un proxy envía las condiciones, el servidor comprueba si un archivo ha cambiado y responde con 304 Not Modified sin cuerpo. Este patrón mantiene actualizados HTML, CSS, JavaScript, imágenes y respuestas de API y reduce significativamente la carga de la infraestructura. Para los activos válidos más largos, utilizo valores max-age largos y me aseguro de que estén actualizados mediante validación. Si dispone de Estrategias de control de la caché saca el máximo partido de las cachés sin arriesgarse a que los contenidos queden obsoletos.
Cabeceras que permiten la validación de la caché
Para una mayor fiabilidad Cache-El cliente necesita señales claras de la respuesta para tomar decisiones. Yo utilizo Cache-Control para la frescura y las reglas, Expires ocasionalmente como complemento, y Last-Modified y ETag para la validación real. Last-Modified proporciona una hora de modificación que puede comprobarse rápidamente, mientras que ETag proporciona un identificador de versión que también se utiliza para el contenido dinámico. Sigue siendo importante: no-cache significa validar antes de usar, no borrar. Si aplica correctamente esta semántica, conseguirá reducir notablemente el tráfico de datos a la vez que mantiene actualizado su contenido. Contenido.
Secuencia de una solicitud condicional sin desvíos
En la primera llamada, el cliente guarda el archivo y los valores de validación como ETag o Last-Modified en la caché. Más tarde, el recurso caduca o requiere una nueva comprobación antes de su uso, y el cliente envía If-None-Match o If-Modified-Since. El servidor compara la información con el estado actual y devuelve 200 OK con un nuevo cuerpo o 304 Not Modified sin carga útil. El cliente continúa entonces utilizando la copia existente y ahorra transmisión, carga de trabajo TLS y tiempo. Este ping-pong parece discreto, pero el Efecto sobre la sensación de carga y la carga del servidor es clara.
ETag vs. Last-Modified en comparación directa
Utilizo Última modificación Me gusta utilizar marcas de tiempo como una referencia rápida y sencilla, pero uso ETags para un control de grano fino. Las marcas de tiempo pueden llegar a sus límites con intervalos de cambio muy cortos o falsear los resultados dinámicos. Yo creo ETags a partir de hashes de archivos, versiones de bases de datos o variantes de renderizado, con lo que cada cambio en el contenido genera un nuevo identificador. Ambos mecanismos pueden combinarse: El cliente puede enviar If-None-Match e If-Modified-Since en paralelo, y el servidor selecciona la comprobación adecuada. Cómo garantizar la fiabilidad Validación, que se aplica por igual a los recursos estáticos y dinámicos.
| Criterio | Última modificación | ETag |
|---|---|---|
| Precisión | Segunda resolución, adecuada para archivos | Identificador de versión para cada cambio de contenido |
| Dinámica | Débil con cambios frecuentes no basados en archivos | Fuerte para API y contenido renderizado |
| Gastos | Bajo, disponible en el sistema de archivos | Baja a moderada, generación en app/proxy |
| Conflictos | Posibles desviaciones del reloj | Posibilidad de etiquetas débiles/fuertes mal configuradas |
Configuración correcta de la caché del navegador y las API
Para los activos estáticos, utilizo max-age y guardar mediante ETag o hash de nombre de archivo para que las actualizaciones se reconozcan inmediatamente. A menudo marco las respuestas HTML y API con no-cache para que el cliente las valide antes de usarlas sin tener que recargar todo cada vez. Marco las páginas personalizadas con private para que las cachés compartidas no muestren nada que haya sido retenido a otros. Los errores suelen deberse a directivas contradictorias o a la falta de cabeceras de validación, que evito con reglas claras. Si conoces los tropiezos típicos, puedes evitarlos fácilmente; el artículo sobre Trampas de cabecera en la caché, en la que me gusta orientarme.
Utilizar eficazmente los códigos de estado y las condiciones
Organizo Códigos de estado Claramente: 200 OK entrega el contenido, 304 Not Modified confirma el uso de la caché, y 412 Precondition Failed cancela si no se cumple una condición. Para operaciones de escritura seguras, utilizo If-Match para que las actualizaciones sólo tengan efecto si el ETag corresponde a la versión esperada. La lectura con If-None-Match o If-Modified-Since evita cargas superfluas y mantiene sincronizados a los clientes. Un comportamiento coherente es importante: El mismo endpoint debe responder de forma idéntica para condiciones previas idénticas. Para SEO y bots, presto atención a cómo las cachés y los rastreadores interpretan los mensajes de estado; una buena visión general de Códigos de estado HTTP y rastreo ayuda a tomar decisiones limpias.
Seguridad y protección de datos en la caché
Trato los contenidos sensibles con no-store y así evitar que acaben en la caché del navegador o del proxy. Marco las páginas personalizadas con Cache-Control: private y compruebo que no aparezcan datos personales en las URL almacenadas en caché a largo plazo. Diseño las ETags de forma neutral, sin permitir que se saquen conclusiones sobre cuentas de usuario o ID internos. Desactivo sistemáticamente todo almacenamiento en caché para las vistas de inicio de sesión y los flujos bancarios. Si combinas minimización de datos, directivas adecuadas y cabeceras limpias, reduces el riesgo y proteges tus datos. Confidencialidad.
Aplicación: Pasos para el servidor y la aplicación
Al principio separo estático de los recursos dinámicos y decido dónde tienen sentido los plazos largos y dónde tiene prioridad la validación. En Nginx, Apache o un servidor de aplicaciones, configuro el control de caché y activo last-modified y ETags, con lo que sitúo la generación de ETags en la aplicación para los endpoints dinámicos. Al procesar las peticiones entrantes, evalúo If-None-Match e If-Modified-Since y respondo con 304 si la condición coincide. Para las operaciones de escritura, utilizo If-Match y devuelvo 412 en caso de desviación para evitar la sobreescritura. Esto crea un comportamiento coherente que utiliza las cachés de forma eficiente y al mismo tiempo Corrección asegura.
Utilizar métricas, pruebas y supervisión con sensatez
Compruebo el Red-tab de las DevTools para comprobar si los recursos proceden de la caché, se están validando o acaban de cargarse. Superviso el estado, los valores de antigüedad, las ETags y el tamaño de la respuesta transferida. Bajo carga, mido la latencia, el volumen de transferencia y la CPU del servidor para ver el efecto real de las respuestas 304. Los registros del proxy inverso muestran si las cachés compartidas están haciendo su trabajo y cuántas validaciones tienen éxito. Utilizo estos datos para ajustar la edad máxima, las directivas de control de la caché y las estrategias ETag hasta que los tiempos de respuesta y la velocidad de transferencia se reducen. Tasa de aciertos votar.
Rendimiento del alojamiento: por qué las peticiones condicionales ahorran dinero
Cualquier 304-La respuesta de caché compartida ahorra ancho de banda, reduce la sobrecarga TLS y acorta el tiempo de respuesta, lo que es particularmente importante para muchas peticiones similares. En las configuraciones de alojamiento con proxies inversos, balanceadores de carga y CDN, logro el mayor efecto cuando permito claramente o excluyo específicamente las cachés compartidas. Menos transferencia a menudo también significa menores costes de tráfico en euros y más reservas para picos de carga reales. La experiencia del usuario también mejora porque las visitas repetidas a las páginas y los sondeos de API responden con mayor rapidez. De este modo, aprovecho el potencial de rendimiento que las actualizaciones de hardware no pueden ofrecer por sí solas y utilizo los recursos existentes para mejorar el rendimiento. Infraestructura mejor.
Errores comunes y soluciones pragmáticas
Contradictorio Encabezado como no-cache emparejados con expires far in the future confunden las cachés; yo establezco reglas claras sin duplicación. Las ETags que faltan en los endpoints dinámicos provocan descargas completas innecesarias; añado un identificador fiable y evalúo if-none-match. Los valores max-age demasiado cortos desperdician potencial con archivos que cambian raramente; estiro los plazos y aún así los aseguro con validación. El almacenamiento agresivo en caché del HTML retrasa los cambios visibles; combino no-cache con ETag y mantengo el contenido actualizado. Con decisiones claras sobre frescura, validación y validez, resuelvo estos escollos y refuerzo la Planificabilidad.
Utilice Vary de forma limpia y controle las representaciones
Para garantizar que las peticiones condicionales funcionen de forma segura en las cachés compartidas, me aseguro de utilizar el método correcto Variar. La cabecera define qué cabeceras de solicitud influyen en la representación. Ejemplos típicos son Aceptación de codificación (gzip, br), Aceptar idioma y Acepte. Si ofrezco contenidos por idioma, configuro Vary: Accept-Language para que un proxy no comparta la versión alemana en respuesta a una solicitud en francés. Para los contenidos personalizados, prescindo deliberadamente de Vary: Cookie y utilizo en su lugar Control de caché: privado, para evitar una explosión incontrolable de claves de caché. Para los recursos que sólo se entregan con una autorización válida, utilizo private o aseguro una separación clara con Vary: Authorisation o Vary en las cabeceras relevantes. La coherencia es importante: el conjunto seleccionado de dimensiones Vary debe permanecer estable; de lo contrario, la tasa de aciertos de la caché y los beneficios de la validación se desplomarán porque constantemente se crean nuevas variantes.
ETags fuertes frente a débiles, compresión e igualdad de bytes
ETags fuertes caracterizan representaciones idénticas byte a byte y permiten una validación precisa, también en combinación con solicitudes de rango. ETags débiles (W/...) sólo señalan igualdad de contenido, no necesariamente bytes idénticos. En la práctica, utilizo ETags fuertes si puedo generar un identificador único para cada representación (incluida la compresión). En cuanto un proxy inverso utiliza gzip o brotli sobre la marcha, adapto la generación de ETags o cambio a ETags débiles para que el servidor y el cliente no reconozcan erróneamente bytes diferentes como idénticos. Una variante robusta es crear el ETag a partir de los bytes finales de la respuesta entregada y al mismo tiempo utilizar Vary: Accept-Encoding . Esto garantiza que „gzip“ y „br“ reciban cada uno su propia ETag válida. Cuando no puedo garantizar la igualdad de bytes (por ejemplo, diferentes marcas de tiempo en HTML), elijo ETags débiles que siguen permitiendo respuestas 304 fiables siempre que el significado de la página no haya cambiado.
Control de caché en el ajuste fino: s-maxage, must-revalidate, stale-while-revalidate
Además de max-age En concreto, utilizo directivas más finas. s-maxage se dirige exclusivamente a Cachés compartidas (CDNs, proxies) y me permite cachear más agresivamente allí que en el navegador. debe revalidarse obliga a los clientes a no utilizar heurísticamente los contenidos caducados, sino a validarlos siempre, lo que resulta útil para los datos críticos. proxy-revalidar aborda esta obligación específicamente para las cachés compartidas. En stale-while-revalidate Permito que una copia ligeramente obsoleta se entregue brevemente mientras la validación se ejecuta en segundo plano; los usuarios ven algo inmediatamente y la siguiente solicitud se beneficia de metadatos frescos. stale-if-error como red de seguridad: Si el Origen falla o devuelve errores, se permite a la caché entregar la última copia conocida durante un tiempo definido. Para los activos build-hashed, combino long max-age con inmutable, ya que el nombre del archivo cambia con el contenido y las validaciones intermedias son innecesarias. Para HTML y API, no-cache más validador sigue siendo el estándar de oro para garantizar la actualización y ahorrar ancho de banda.
Otras condiciones y métodos: HEAD, alcance y conflictos de escritura
Las solicitudes condicionales no se limitan a GET. A HEAD-request sólo proporciona cabeceras y es ideal para validaciones rápidas sin cuerpo. Para archivos grandes utilizo alcance-solicitudes; con If-Range Me aseguro de que sólo se envíen áreas parciales si el recurso sigue coincidiendo con la versión esperada; de lo contrario, respondo con 200 y un cuerpo completo. Para las operaciones de escritura, aseguro la coherencia con Si coincide ab: PUT, PATCH o DELETE sólo funcionan si el ETag del cliente coincide con la versión actual; de lo contrario respondo con 412 Precondition Failed. Cuando quiero imponer precondiciones, por ejemplo con recursos propensos a conflictos, utilizo 428 Precondition Required para que los clientes utilicen If-Match. Elijo deliberadamente entre 409 Conflicto y 412: 412 señala las precondiciones violadas, 409 enfatiza los conflictos de contenido (por ejemplo, reglas de lógica de negocio). Esta claridad facilita las implementaciones de los clientes y evita las anulaciones ciegas.
Personalización, cookies y protección de datos en la práctica
Para las páginas personalizadas, marco las respuestas con privado o no-store. Evito codificar los estados de los usuarios en etiquetas electrónicas porque éstas pueden convertirse involuntariamente en marcadores de seguimiento. En su lugar, hago una distinción estricta entre representaciones públicas y privadas. Sólo establezco cookies en la clave de caché (Vary: Cookie) si es absolutamente necesario, porque aumentan el número de variantes y reducen drásticamente la tasa de aciertos. Para las respuestas API autorizadas me atengo a Control de caché: privado y, si es necesario, a Vary en el formato de la cabecera Authorisation. Así me aseguro de que las cachés compartidas no compartan inadvertidamente respuestas confidenciales. En las aplicaciones con contenido mixto (marco básico público, subáreas personalizadas), confío en el almacenamiento en caché fragmentado o en ESI/SSI de borde, mientras que las partes críticas siguen siendo privadas. El resultado es la protección de los datos sin merma del rendimiento.
Operación: CDN, sustitutos e invalidaciones
En las configuraciones CDN combino s-maxage con validadores claros y, si están disponibles, utilizar directivas específicas de sustitutos para controlar las cachés de los bordes de forma independiente del navegador. La revalidación reduce la carga sobre Origin, pero ocasionalmente es necesaria una invalidación dura (por ejemplo, corrección de seguridad). Entonces planeo dos maneras: Reventar la caché mediante hashes de nombres de archivo para activos estáticos y Purga/Invalidación para HTML y API. De este modo se evitan las „tormentas de purga“ y se mantiene un tiempo de actualización corto. También es importante tener una clave de caché coherente en la CDN (incluyendo host, ruta, parámetros de consulta y cabeceras Vary relevantes). Para los parámetros de consulta, diferencio conscientemente entre parámetros semánticos (por ejemplo, ?lang=) y parámetros puramente relacionados con el seguimiento; ignoro estos últimos en la clave de caché para evitar la fragmentación. De este modo, la cadena de caché del navegador, proxy intermedio y CDN se mantiene transparente y predecible.
304 en detalle: Actualizar correctamente la cabecera y los metadatos
También un 304-La respuesta contiene metadatos importantes. Entrego Fecha, Cache-Control, ETag/Last-Modified y -si es relevante- Expires y Vary de nuevo para que el cliente pueda actualizar sus entradas de caché. Content-Type y Content-Encoding no tienen que repetirse necesariamente, pero pueden contribuir a la claridad. Es importante que el 304 no contenga un cuerpo de carga útil y que envíe validadores coherentes: Cambiar el ETag en el 304 sin cambiar la representación lleva a confusión. Si se ajustan las directrices (por ejemplo, una max-age más larga), el cliente puede adoptar los metadatos sin tener que recargar el cuerpo: una pequeña palanca con un gran impacto en el rendimiento percibido.
Estrategias de prueba y depuración para una validación limpia
Compruebo específicamente los siguientes puntos en DevTools: desde la caché de disco vs. de la memoria caché vs. revalidado; Estado 200/304; cabecera Age en respuestas de cachés compartidas; coherencia ETag/Last-Modified y el efecto de Vary. Para realizar pruebas reproducibles, desactivo temporalmente la caché del navegador o utilizo un modo privado. Del lado del servidor, evalúo los registros en función de la proporción 200/304, el tamaño medio de la respuesta y la utilización de la CPU. Las señales de alerta son, por ejemplo, muchas respuestas 200 a recursos con intervalos de cambio cortos (falta de validadores), bucles de revalidación (tiempos desviados/desviación del reloj) o un número inusualmente grande de variantes por URL (Vary excesivo). Utilizo pruebas de carga para comprobar cómo se comportan s-maxage, stale-while-revalidate e if-none-match bajo presión, y ajusto las directivas hasta que el rendimiento y la latencia coinciden.
Casos extremos y valores por defecto robustos
No todos los recursos tienen reglas de cambio claras. Establezco valores predeterminados prudentes para sitemaps, feeds o cuadros de mando generados: no-cache más ETag/Last-Modified. Con relojes inestables entre sistemas upstream, evito las comparaciones rígidas de segundos y prefiero ETags independientes de las marcas de tiempo. Si la compresión es variable (diferentes niveles de gzip), incluyo el resultado de la compresión en la generación de ETags o cambio a ETags débiles. Y si los clientes solicitan sin validadores, envío señales claras: O bien frescura clara (max-age/immutable) o validación clara (no-cache + ETag). Estos valores por defecto robustos garantizar que ni siquiera los clientes incompletos o defectuosos provoquen picos de carga no deseados.
Breve resumen
Conectar solicitudes condicionales Velocidad y puntualidad haciendo que los clientes sólo recuperen recursos completos cuando el contenido ha cambiado. Utilizo el control de caché para mantener la frescura, combino la última modificación y ETag para realizar comprobaciones fiables y respondo sistemáticamente con 304 si se cumplen las condiciones. Aíslo los contenidos personalizados y confidenciales con private o no-store para que ningún dato acabe en cachés compartidas. Las mediciones en DevTools, los registros y las métricas me muestran dónde puedo ampliar los plazos o ajustar la lógica de validación. Si piensas en estos componentes básicos de forma conjunta, conseguirás páginas más rápidas, una menor carga del servidor y un más redondo Experiencia de usuario sin desperdiciar datos.
