Timing-Allow-Origin: qué ve la analítica en la Resource Timing API
La cabecera Timing-Allow-Origin controla cuánto detalle de timing entre orígenes puede leer una página. Esto es lo que significa para la medición del rendimiento centrada en la privacidad.
La cabecera que nadie configura a propósito
La mayoría de los equipos se topa con Timing-Allow-Origin (TAO) solo cuando un gráfico de su herramienta de monitorización muestra ceros sospechosos. Los recursos entre orígenes —fuentes, imágenes de una CDN, un script de terceros— aparecen en la Resource Timing API, pero sus sub-tiempos detallados se leen como 0 a menos que el servidor que responde lo permita explícitamente. Esa autorización es la cabecera TAO, y entenderla es esencial si quieres datos de rendimiento honestos sin recurrir a un seguimiento invasivo.
El estándar Resource Timing expone una entrada PerformanceResourceTiming por cada fetch que hace una página. Para los recursos del mismo origen obtienes el desglose completo: búsqueda de DNS, conexión TCP, negociación TLS, inicio de la petición y tiempos de respuesta. Para los recursos entre orígenes, la especificación restringe deliberadamente lo que un documento puede leer, porque esos tiempos detallados pueden filtrar información sobre el estado de la red del usuario, el contenido de la caché o el comportamiento interno de otro origen.
Qué se pone a cero
Sin una cabecera TAO que coincida, los siguientes atributos de una entrada PerformanceResourceTiming entre orígenes se fijan a cero: redirectStart, redirectEnd, domainLookupStart, domainLookupEnd, connectStart, connectEnd, secureConnectionStart, requestStart, responseStart, transferSize, encodedBodySize y decodedBodySize. Aun así obtienes startTime, duration, responseEnd y el name e initiatorType del recurso. En la práctica, eso significa que puedes saber que un recurso se cargó y cuánto tardó en total, pero no en qué se fue el tiempo ni cuántos bytes cruzaron la red.
La comprobación está definida por el algoritmo timing allow check de la especificación Resource Timing. Un recurso la supera si su respuesta lleva Timing-Allow-Origin con un valor que coincide con el origen del documento que hace la petición o que es el comodín *.
Timing-Allow-Origin: https://example.com
# o, para permitir cualquier origen
Timing-Allow-Origin: *
Por qué esto importa para la analítica centrada en la privacidad
Monoid mide el rendimiento desde el campo —navegaciones reales de visitantes reales— sin cookies, sin localStorage y sin fingerprinting. Las APIs Resource Timing y Navigation Timing son la forma basada en estándares de lograrlo, y TAO es el mecanismo que la plataforma utiliza para mantener confidenciales por defecto los datos de timing entre orígenes.
Ese comportamiento por defecto es una característica de privacidad, no un obstáculo. El poner a cero existe precisamente para impedir que una página sondee orígenes de terceros en busca de canales laterales de timing. Cuando te recomendamos configurar Timing-Allow-Origin en tus propios recursos estáticos y CDN, te pedimos que habilites la visibilidad de tu propia infraestructura para tu propia medición, no que debilites la protección de nadie.
Los Core Web Vitals refuerzan el argumento. El Largest Contentful Paint es con frecuencia una imagen entre orígenes o una fuente web. Si a esas respuestas les falta una cabecera TAO, aún puedes observar el elemento LCP a través de la Largest Contentful Paint API, pero pierdes los sub-tiempos de petición y respuesta que te dirían si el retraso lo causó un DNS lento, un handshake TLS en frío o una transferencia grande. Añadir la cabecera a los orígenes de tus recursos convierte un número opaco en uno accionable.
Configurarla correctamente
Unas cuantas notas prácticas. Primero, que transferSize sea distinto de cero también te permite distinguir un acierto de caché (un tamaño de transferencia pequeño) de un fetch de red, lo cual es invaluable al diagnosticar el rendimiento en visitas repetidas. Segundo, si sirves fuentes entre orígenes, el atributo CSS crossorigin y CORS son una cuestión distinta de TAO: puede que necesites ambos. Tercero, prefiere nombrar orígenes específicos en lugar de * cuando puedas, para que solo los documentos que legítimamente necesitan los datos los reciban.
En Cloudflare, puedes añadir la cabecera en el edge con una Transform Rule o en la respuesta de un Worker, aplicándola a las rutas de tus recursos. Como Monoid se ejecuta en el mismo edge, los datos de timing que recopilan los navegadores de tus visitantes fluyen directamente a métricas agregadas y sin identificadores: no se requiere ningún perfil por usuario para saber que tu imagen principal pasa 400 ms en TLS.
La conclusión
Timing-Allow-Origin es una cabecera pequeña con una influencia desproporcionada sobre cuánto puedes aprender de los datos de rendimiento de campo. El comportamiento por defecto del navegador —poner a cero los sub-tiempos entre orígenes— es una salvaguarda de privacidad deliberada, y encaja perfectamente con cómo debería funcionar la analítica centrada en la privacidad: medir agregados desde APIs estándar, habilitar explícitamente el detalle de tus propios orígenes y nunca tratar el fingerprint de red de un usuario como algo que recolectar. Configura TAO en tus recursos y la depuración de tus Web Vitals se afinará sin ningún tipo de seguimiento.
Comments
Loading comments…