Programación y sistemas

El fichero traffic-advice: qué es, para qué sirve y cómo configurarlo

Servidor web conectado a Chrome a través de un proxy anónimo, ilustrando el funcionamiento del fichero traffic-advice

Si monitoreas los logs de acceso de tu servidor web con cierta regularidad, probablemente hayas visto peticiones a una ruta como /.well-known/traffic-advice. En este artículo te explico qué es ese fichero, qué función cumple, cómo configurarlo correctamente y qué ventajas e inconvenientes tiene tenerlo en tu sitio.

¿Qué es el fichero traffic-advice?

El fichero traffic-advice es un documento JSON que los servidores web pueden publicar en la ruta /.well-known/traffic-advice. Su propósito es proporcionar instrucciones legibles por clientes automatizados —principalmente navegadores y proxies de red— sobre cómo deben gestionar el tráfico hacia ese sitio.

El estándar está impulsado principalmente por Google y forma parte de la especificación Private Prefetch Proxy, un mecanismo por el cual el navegador Chrome puede precargar recursos de páginas externas a través de un proxy anónimo, mejorando los tiempos de carga percibidos sin revelar la IP del usuario al servidor de destino hasta que este realiza la navegación real.

El fichero sigue el convenio .well-known definido en el RFC 8615, un directorio reservado en la raíz del dominio para metadatos y descubrimiento de servicios (como security.txt, robots.txt o apple-app-site-association).

¿Para qué sirve?

El principal caso de uso del fichero traffic-advice es comunicar al Private Prefetch Proxy de Chrome si el sitio acepta o rechaza que sus páginas sean precargadas a través de ese mecanismo.

Cuando un usuario de Chrome visita una página con enlaces a sitios externos, el navegador puede, de forma anticipada y anónima, precargar esos recursos a través del proxy de Google. Esto permite que, si el usuario hace clic en uno de esos enlaces, la página de destino ya esté (parcialmente) cargada.

El fichero traffic-advice permite al propietario del sitio de destino:

  • Autorizar explícitamente esa precarga (opt-in).
  • Denegarla completamente (opt-out).
  • Controlar qué fracción del tráfico de precarga se acepta.
  • Dar instrucciones específicas a distintos user-agents.

Formato y estructura del fichero

El fichero debe servirse desde https://tu-dominio.com/.well-known/traffic-advice con el Content-Type application/trafficadvice+json. Su estructura es un array JSON donde cada objeto define las instrucciones para un user-agent concreto.

Ejemplo básico: permitir la precarga

[
  {
    "user_agent": "prefetch-proxy",
    "google_prefetch_proxy_eap": {
      "fraction": 1.0
    }
  }
]

El campo fraction acepta valores entre 0.0 y 1.0 e indica qué proporción del tráfico de precarga se permite. Un valor de 1.0 lo habilita al 100%; un valor de 0.5 permitiría solo la mitad.

Ejemplo: denegar la precarga

[
  {
    "user_agent": "prefetch-proxy",
    "disallow": true
  }
]

Ejemplo: instrucciones combinadas para varios agentes

[
  {
    "user_agent": "prefetch-proxy",
    "google_prefetch_proxy_eap": {
      "fraction": 0.5
    }
  },
  {
    "user_agent": "*",
    "disallow": true
  }
]

Cómo configurarlo en tu servidor

Opción 1: fichero estático

La forma más sencilla es crear el fichero directamente en el sistema de ficheros y asegurarse de que el servidor lo sirve con el Content-Type correcto.

Crea el fichero en .well-known/traffic-advice dentro del directorio raíz de tu sitio web con el contenido JSON deseado.

Luego, en Apache, añade en tu .htaccess o en la configuración del virtualhost:

<Files "traffic-advice">
    Header set Content-Type "application/trafficadvice+json"
</Files>

En Nginx, añade en tu bloque server:

location = /.well-known/traffic-advice {
    default_type application/trafficadvice+json;
    try_files $uri =404;
}

Opción 2: respuesta dinámica

Si tu stack lo requiere, puedes servirlo mediante un endpoint de tu aplicación. En PHP sería tan simple como:

<?php
header('Content-Type: application/trafficadvice+json');
echo json_encode([
    [
        'user_agent' => 'prefetch-proxy',
        'google_prefetch_proxy_eap' => ['fraction' => 1.0]
    ]
]);

Verificar que funciona

Puedes comprobarlo desde la línea de comandos con curl:

curl -I https://tu-dominio.com/.well-known/traffic-advice

Deberías ver un 200 OK y el Content-Type application/trafficadvice+json.

Pros y contras

Ventajas

  • Mejora la experiencia de usuario. Al permitir la precarga a través del proxy de Chrome, los visitantes que lleguen desde Google u otros sitios que enlacen al tuyo percibirán tiempos de carga más rápidos.
  • Control explícito. Puedes decidir con precisión si permites la precarga, en qué porcentaje y para qué agentes. No estás a merced del comportamiento por defecto del navegador.
  • Privacidad del usuario. El Private Prefetch Proxy anonimiza al usuario frente a tu servidor durante la fase de precarga, por lo que no recibes la IP real del visitante hasta que este navega efectivamente a tu sitio.
  • Mejora de señales de rendimiento. Un sitio que carga rápido impacta positivamente en métricas como el Core Web Vitals (LCP), que Google utiliza como factor de posicionamiento.
  • Fichero ligero y sin mantenimiento. Una vez configurado, prácticamente no requiere atención.

Inconvenientes

  • Consumo de recursos del servidor. Aceptar precargas implica que tu servidor recibirá y procesará peticiones de usuarios que quizá nunca lleguen a completar la navegación a tu sitio, lo que puede aumentar la carga.
  • Estadísticas y analítica distorsionadas. Las peticiones del proxy pueden interferir en herramientas de analítica si no están correctamente filtradas, generando visitas fantasma o inflando el número de peticiones.
  • Caché y contenido dinámico. Si tu sitio sirve contenido personalizado o basado en cookies (sesiones, precios, contenido A/B), la precarga puede devolver al usuario una versión genérica del recurso que luego no coincida con lo que esperaba.
  • Exclusivo de Chrome. Ninguno de los otros navegadores mayoritarios —Firefox, Safari o Edge en modo no-Chromium— consulta el fichero traffic-advice ni implementa el Private Prefetch Proxy. Esto significa que configurar este fichero solo tiene efecto sobre los usuarios de Chrome, que según los datos globales de uso ronda el 65% del tráfico de escritorio, pero deja sin cubrir al resto. No existe ningún grupo de estandarización (W3C, IETF) que esté trabajando activamente en extender este mecanismo al resto de navegadores, por lo que no hay garantías de que la situación cambie a medio plazo.
  • Soporte aún en evolución. Al ser una especificación relativamente reciente, su comportamiento puede cambiar con futuras versiones del navegador o del proxy.

Cómo gestionan la precarga Firefox y Safari

Dado que traffic-advice es territorio Chrome, vale la pena entender qué alternativas existen en los otros navegadores mayoritarios. En todos los casos el control reside en el HTML del documento que enlaza a tu sitio, no en un fichero en el servidor de destino.

Firefox

Firefox soporta los hints estándar de recursos HTML, que el sitio que enlaza puede incluir en su <head>:

  • <link rel="dns-prefetch" href="//tu-dominio.com">: resuelve el DNS del dominio de forma anticipada, sin establecer conexión todavía.
  • <link rel="preconnect" href="https://tu-dominio.com">: va un paso más allá y pre-establece la conexión TCP y el handshake TLS.
  • <link rel="prefetch" href="https://tu-dominio.com/pagina">: descarga el recurso en segundo plano para una navegación futura. Firefox lo implementa con prioridad baja y respetando la política de caché.

Firefox no dispone de un proxy intermedio anónimo como el de Chrome, por lo que cualquier precarga expone directamente la IP del usuario al servidor de destino desde el primer momento.

Safari

Safari tiene un comportamiento deliberadamente conservador en materia de precarga, influenciado por su fuerte apuesta por la privacidad. Soporta dns-prefetch, preconnect y preload (para recursos críticos de la página actual), pero su implementación de prefetch para navegación futura ha sido históricamente limitada y sujeta a restricciones internas que el desarrollador no puede controlar directamente.

Apple ha optado por gestionar la precarga a nivel de sistema operativo en iOS y macOS —a través de mecanismos propios como el prefetching de Safari en el historial o las sugerencias de Siri— en lugar de exponer un mecanismo que los sitios web puedan activar de forma explícita. Esto significa que, como propietario de un sitio, tienes muy poco control sobre cómo Safari precarga tu contenido.

El Speculation Rules API de Chrome

Además del Private Prefetch Proxy, Chrome ha introducido la Speculation Rules API, una alternativa más moderna y flexible que permite al sitio que enlaza declarar reglas de prefetch y prerender mediante un bloque JSON en el HTML:

<script type="speculationrules">
{
  "prefetch": [
    { "source": "list", "urls": ["https://tu-dominio.com/pagina"] }
  ]
}
</script>

Esta API también es exclusiva de Chrome por ahora, pero representa la dirección en la que se mueve el navegador para sustituir los hints clásicos de <link>. En este caso el control lo tiene el sitio que enlaza, no el sitio de destino, a diferencia de traffic-advice.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.