Antes de comprar más tráfico de proxy para un monitor de contenido, inspecciona las cabeceras que tu cliente envía realmente. En nuestro sitio web en producción, añadir Cache-Control: no-cache convirtió las comprobaciones de páginas sin cambios de respuestas 304 sin cuerpo en descargas 200 completas, aunque las peticiones llevaban el ETag coincidente.
En una comparación controlada, 12 peticiones condicionales sin esa cabecera adicional transfirieron cero bytes de cuerpo de respuesta; 12 con ella transfirieron 271.968 bytes de HTML sin cambios. Las seis descargas iniciales necesarias para obtener los ETags costaron otros 135.984 bytes y están incluidas en los registros publicados.
Es un hallazgo sobre un sitio Next.js 16.3.4 desplegado y una política de peticiones concreta. No es un consejo para eliminar los requisitos de frescura de un monitor. La decisión útil es si cambiar la política del cliente, elegir una representación más pequeña o investigar el comportamiento de revalidación del servidor.
La tarea: monitorizar contenido conocido sin descargarlo innecesariamente
Probamos dos artículos existentes de ipvolt: la guía de benchmarks de proxy y la explicación de errores de proxy, cada uno como HTML y como Markdown. Nuestro monitor vigilaba el título del artículo y dos encabezados de sección especificados. También comprobaba los tipos de medio y, para HTML, el título de la página y la URL canónica.
Esas comprobaciones establecen que la información vigilada está presente. No convierten a Markdown en un sustituto del diseño, del comportamiento de JavaScript ni de un flujo de registro funcional. Las aserciones exactas están en la configuración del estudio.
La recopilación usó conexiones de proxy de terceros autenticadas dirigidas a EE. UU., Reino Unido y Países Bajos. El experimento inicial también incluyó un control directo. Las respuestas de comprobación de país informaron de los países solicitados en los puntos de control; una dirección de salida cambió durante la ejecución inicial de EE. UU., así que se trata de observaciones de ruta y no de resultados de fiabilidad de IP fija o de todo un país. Se omite el proveedor de la conexión; esto no fue una prueba de un servicio de proxy de ipvolt disponible.
Los tres experimentos HTTP se ejecutaron el 11 de septiembre de 2026. Realizaron 234 peticiones y transfirieron 2.975.066 bytes de cuerpo de respuesta, incluidas descargas iniciales, descargas de verificación e hipótesis fallidas. Todas las peticiones intentadas se completaron sin error de transporte de curl. Las sondas geográficas adicionales y el QA de navegador se registran por separado en la nota de método; quedan fuera de ese total del experimento HTTP.
La primera descarga más pequeña no respondió a la pregunta sobre la caché
El experimento inicial solicitó gzip de forma consistente y midió los bytes de cuerpo recibidos. En doce observaciones iniciales por representación, los tamaños fueron:
| Representación del artículo | Bytes de cuerpo recibidos por petición inicial |
|---|---|
| HTML del benchmark | 26.521 |
| Markdown del benchmark | 7.056–7.061 |
| HTML de la guía de errores | 18.807 |
| Markdown de la guía de errores | 5.081 |
Ambos endpoints HTML proporcionaron ETags. Ninguno de los endpoints Markdown proporcionó un validador ETag ni Last-Modified en este experimento. Las comprobaciones condicionales de HTML sin cabecera Cache-Control adicional devolvieron 304; el ejecutor reutilizó el cuerpo coincidente aceptado previamente en lugar de interpretar la respuesta vacía como un documento nuevo.
La ejecución exploratoria realizó 144 peticiones: 120 respuestas 200 completas y 24 respuestas 304 aceptadas. Omitió 36 ranuras condicionales porque el Markdown no tenía validador o la página de inicio estaba marcada como no-store. Las peticiones omitidas no se cuentan como éxitos ni como observaciones de red de cero bytes.
Después ejecutamos cinco comprobaciones sucesivas por representación a través de cada una de las tres rutas de proxy. Cada comprobación enviaba explícitamente Cache-Control: no-cache, y el cliente conservaba los validadores elegibles entre comprobaciones. Las 60 peticiones devolvieron 200, incluidas las 24 recomprobaciones de HTML que llevaban un ETag coincidente. La expectativa de que la validación repetida de HTML evitaría descargar el cuerpo no se cumplió bajo esta política.
Aislar la cabecera que cambió la respuesta
Para investigar, mantuvimos constantes la URL, la configuración de ruta, Accept, el idioma, la preferencia de gzip y el ETag semilla exacto. Para cada una de las seis combinaciones ruta/artículo, hicimos una petición semilla y cuatro peticiones condicionales. El orden fue A/B/B/A o B/A/A/B, donde A omitía la cabecera Cache-Control adicional y B enviaba no-cache.
| Política de la petición condicional | Intentos | Respuestas | Bytes de cuerpo recibidos |
|---|---|---|---|
| If-None-Match coincidente; sin cabecera Cache-Control adicional | 12 | 12 × 304 | 0 |
| Mismo If-None-Match; Cache-Control: no-cache | 12 | 12 × 200 | 271.968 |
Las 24 observaciones condicionales coincidieron con los valores vigilados y el contenido decodificado de la semilla. Incluidas las seis semillas, este experimento controlado transfirió 407.952 bytes de cuerpo en 30 peticiones. Usó un orden equilibrado, no un muestreo aleatorio, y establece el comportamiento observado de estos endpoints durante esta breve ventana.
La implementación explica un mecanismo plausible. Comparamos los archivos de dependencias realmente desplegados con la instalación local de Next.js 16.3.4: los hashes de los archivos fuente relevantes coincidieron. Su helper de respuesta con ETag llama a fresh antes de devolver 304; la comprobación de frescura incluida devuelve false cuando la petición contiene no-cache, antes de evaluar el ETag coincidente. Una prueba local independiente de la función reprodujo la misma rama. Helper de respuesta de Next.js, implementación de fresh.
Es un comportamiento específico del stack, coherente con los resultados en producción. HTTP no define no-cache como una instrucción universal para descargar un cuerpo completo. Recibir 304 tampoco demuestra que la petición llegara al origen y no a una caché que respondió. Caché HTTP.
La optimización útil depende de la frescura que necesitas
Para el experimento de cinco comprobaciones que usó explícitamente no-cache, los totales reales fueron:
| Representación | Peticiones, incluidas las descargas iniciales | Bytes de cuerpo recibidos |
|---|---|---|
| HTML | 30 | 679.920 |
| Markdown | 30 | 182.070 |
| Diferencia | Mismo número de peticiones | 497.850 |
Markdown transfirió un 73,2 % menos de bytes de cuerpo de respuesta para el contenido vigilado bajo esa política. No redujo el número de peticiones. Son diferencias de carga útil medidas, no un ahorro medido en la factura ni una previsión de tráfico mensual. La métrica de tamaño de descarga de curl excluye las cabeceras y otra sobrecarga de red. Contabilidad de carga útil de curl.
Hay otra opción cuando los requisitos de frescura lo permiten: las respuestas Markdown anunciaban public, max-age=300, must-revalidate. Una caché puede reutilizar una representación almacenada todavía fresca sin hacer una petición. La ausencia de validadores no la hace no cacheable. Nuestros ejecutores comprobaron deliberadamente a través de la red; no implementaron esa política de programación basada en la frescura. Frescura y reutilización.
Usa el resultado para elegir la siguiente acción:
| Tu requisito de monitorización | Acción respaldada por este caso |
|---|---|
| La reutilización dentro de la ventana de frescura del servidor es aceptable | Evalúa una caché local consciente de la frescura antes de programar otra descarga. |
| Pedir al servidor o a la caché que responde que valide cada comprobación | Prueba las cabeceras finales de la petición contra el endpoint real; no des por hecho que un ETag garantiza una respuesta sin cuerpo. |
| Necesitas el texto vigilado, y cada comprobación devuelve un cuerpo completo | Compara el HTML comprimido con una representación de texto o Markdown que contenga esos mismos datos. |
| Necesitas el diseño renderizado o un flujo interactivo | Mantén las comprobaciones con navegador; la representación de texto más pequeña no cubre esa tarea. |
No elimines no-cache solo para reproducir la fila de cero bytes. Las dos políticas de cabeceras pueden tener consecuencias distintas para la frescura. Establece qué debe detectar tu monitor y luego mide la implementación permitida.
Reproduce el resultado y adapta la comprobación
Descarga el script de análisis offline y las grabaciones saneadas en el mismo directorio. Basta con Python 3.10 o posterior; este comando no realiza peticiones de red:
python3 reproduce.py recordings.zipRecalcula los recuentos de intentos, los totales de cuerpo, la comparación de cabeceras y el porcentaje de Markdown. Compara su salida con el resultado registrado. El conjunto de datos incluye marcas de tiempo, políticas de petición, cabeceras de respuesta seleccionadas, comprobaciones de contenido y hashes. Las credenciales, las IP de salida, las cabeceras sin filtrar y las capturas de cuerpo sin procesar siguen siendo privadas; la reproducción verifica la aritmética publicada en lugar de autenticar de forma independiente las respuestas históricas.
Las instrucciones de descarga enlazan los programas de recopilación exactos, las configuraciones y 27 pruebas offline superadas. Los programas en vivo requieren curl 8.4 o posterior, conservan la verificación TLS, acotan las peticiones y la transferencia de cuerpo, y pasan la autenticación del proxy de forma privada a través de la entrada de curl. Su lista de permitidos está restringida al sitio público de este caso; adapta tanto la lista de permitidos como las aserciones de contenido para una propiedad que operes.
No observamos una actualización real de contenido ni medimos el retraso de detección. El contenido decodificado se mantuvo estable en todos los endpoints probados; algunos flujos de bytes gzip difirieron a pesar de que el texto decodificado era idéntico. Eso es una razón para comparar el contenido que le importa a tu monitor, no una evidencia de que este estudio eliminara las falsas alertas operativas. Es un sitio, dos artículos y una breve ventana de observación, no una clasificación de proveedores ni un benchmark universal de caché.
Método: recopilación y análisis asistidos por agente, con revisiones independientes de evidencia, editorial y de búsqueda. Todas las observaciones de red informadas se ejecutaron realmente; las pruebas offline ejercitan fixtures controlados y están etiquetadas por separado.
Avísame cuando se abra el acceso. Un correo cuando se abra el acceso. Nada más.