--bot-performance-timing: señales de tiempo y huella del navegador
Conoce los modos básico y avanzado de --bot-performance-timing, las API de Performance Timing observables y los límites de las comprobaciones de proxy y anti-bot.
Quieres la documentación estructurada de Huella digital?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
--bot-performance-timing controla en el motor la coherencia de las superficies de tiempo que observa una página. No promete que un sitio acepte una sesión ni oculta los datos de red que puede exponer un proxy. La pregunta útil es más concreta: ¿los valores describen una navegación y una carga de recursos plausibles?
Qué controla la opción
Una página puede leer performance.now(), PerformanceNavigationTiming, PerformanceResourceTiming y el objeto antiguo performance.timing. Si solo se modifica un acceso, los demás pueden contradecirlo. El control actúa en el modelo del navegador para que esas vistas describan el mismo ciclo de vida.
BotBrowser documenta dos niveles. Básico conserva valores plausibles y coherentes para el uso normal del perfil. Avanzado aplica los intervalos documentados, cuyos parámetros exactos siguen siendo experimentales. El registro del issue no define una semilla global ni de página: la referencia reproducible es la consulta de tiempos sin mutación y su resumen estable. Son descripciones de alcance, no una puntuación de detector ni una garantía de invisibilidad.
Antes de elegir un modo, define la ventana de observación. Una primera visita en frío, una página restaurada y un cambio de ruta en una aplicación de una sola página exponen eventos distintos. Mantener ese contexto junto al modo evita marcar una diferencia esperada como defecto.
Modo básico: ciclo de vida coherente
El modo básico mantiene el orden de las fases: el inicio de una solicitud precede a su respuesta, una navegación real tiene hitos no nulos y una misma entrada no cambia entre lecturas. Las entradas modernas y el objeto antiguo proceden del mismo ciclo de vida.
Esto no hace que todas las páginas tarden igual. Caché, red, redirecciones, service workers y planificación del procesador siguen influyendo. Las lecturas repetidas deben mantenerse estables para entradas de recursos finalizadas y para una navegación después de responseEnd; antes de responseEnd se permite una transición única de Básico a Avanzado al finalizar la navegación. La finalidad es evitar contradicciones artificiales creadas por parches selectivos. El tiempo debe tratarse como contexto diagnóstico, no como identidad.
El modo básico también sirve como línea base de compatibilidad. Ejecútalo con la precisión de privacidad habitual y con los estados de caché admitidos. Si falta una medida, deja que la función continúe con un respaldo documentado en vez de inventar un número.
Modo avanzado: intervalos experimentales entre vistas
El modo avanzado aplica los intervalos documentados y conserva la forma de una navegación válida. No tiene una semilla global ni de página. Las lecturas repetidas permanecen estables para entradas de recursos finalizadas y para una navegación después de responseEnd; antes de responseEnd se permite una transición única de Básico a Avanzado al finalizar la entrada. Los parámetros de intervalo siguen siendo experimentales, por lo que deben compararse cargas acotadas y no una identidad.
El registro público incluye getEntries(), entradas de navegación y recursos, performance.timing y performance.toJSON(). También nombra una consulta de tiempos sin mutación y un resumen estable, pero no establece una semilla global o de página. La comprobación correcta compara vistas: las fases correspondientes deben mantenerse dentro de la tolerancia documentada y representar la misma secuencia de eventos. El modo avanzado es una configuración experimental de intervalos, no una nueva identidad con semilla.
La configuración de intervalos debe revisarse como dato experimental. El resumen estable pertenece a la consulta de tiempos sin mutación, no a una semilla global o de página, y no vuelve deterministas la carga del servidor, la planificación del sistema ni un paquete JavaScript que cambia. Mantén esas variables visibles al comparar ejecuciones.
Qué puede observar una página
Performance expone tiempos transcurridos y entradas, sujetos a la precisión y a las reducciones de privacidad del navegador. Se pueden observar hitos de navegación, cargas de recursos, marcas creadas por la aplicación y el objeto antiguo cuando está disponible. También se pueden comparar orden, estados cero/no cero y relaciones entre entradas.
Son observaciones del documento y de su entorno de carga, no una medición fiable del procesador ni de la identidad. Caché, tareas en segundo plano y políticas del navegador cambian las muestras. La guía de tiempos de rendimiento sitúa esta señal junto a otras superficies, sin mezclarlas.
Esta separación ayuda durante un incidente. Un recurso lento puede ser un fallo de caché, de ruta o trabajo de la aplicación tras la respuesta. Empieza por el ciclo de vida y la propiedad de la medida, e inspecciona otras señales solo si responden a otra pregunta.
Cruce con proxy y sistemas anti-bot
El tiempo es una sola capa. Un servicio puede comparar hitos del navegador con la llegada de solicitudes al servidor, reutilización de conexiones, redirecciones y cabeceras de caché. Un proxy puede añadir latencia o cambiar la ruta sin cambiar los valores locales. Un registro local plausible tampoco corrige una ruta, un perfil TLS o una reputación de IP incoherentes.
En una revisión autorizada, compara categorías: entradas del navegador, marcas del servidor y eventos de salud del proxy deben responder a la misma pregunta operativa. Define tolerancias para cada carga y no publiques umbrales de detección. Un recurso ausente debe conservar una alternativa usable. Consulta la guía de coherencia de red.
Cuando haya una discrepancia, conserva la categoría y la marca temporal originales en vez de reducirlo todo a una etiqueta de «bot». Así se puede corregir una ruta, una política de caché o una regresión sin cambiar innecesariamente el modo de tiempos.
Límites y uso responsable
La opción no amplía la compatibilidad de Performance, no iguala sistemas operativos y no elimina toda variación. Tampoco autoriza acceso ni demuestra que una sesión sea humana. Úsala para pruebas reproducibles, coherencia del perfil y revisión de privacidad. No unas trazas con identificadores de cuenta ni las conserves más tiempo del necesario.
Antes de publicar, verifica hitos ordenados y no nulos, acuerdo entre vistas modernas y antiguas, y una alternativa cuando falta un recurso. Registra modo y configuración de intervalos como metadatos de prueba, no como identificador. Revisa el contrato después de actualizar el navegador.
Haz que la fijación sea observable sin volverla identificable. Un identificador breve de ejecución, la versión del navegador, la revisión del perfil y la carga bastan para unir registros de página, servidor y gateway. Limita esa clave a la ejecución, elimina consultas antes de exportar trazas y conserva agregados cuando termine el diagnóstico. Así el cambio se puede explicar sin crear una señal persistente entre sesiones.
Una revisión de regresión debe conservar la configuración de prueba, el navegador y el resultado agregado. Esa separación permite repetir el diagnóstico sin convertir una medición temporal en un identificador.
Leer una entrada de navegación de forma segura
Las entradas de navegación describen una solicitud de documento, pero cada campo tiene un significado distinto. Un redireccionamiento puede añadir fases antes de la respuesta final. Un service worker puede atender la solicitud sin la misma ruta de red que una carga en frío. Un acierto de caché puede hacer rápido un recurso sin indicar un procesador más veloz. Lee la entrada como un registro del ciclo de vida y conserva esas diferencias en paneles y notas de soporte.
La aplicación debe detectar primero la API y después gestionar una lista vacía. Una página prerenderizada, restaurada desde back-forward cache o que aún no alcanzó una fase puede no mostrar los mismos campos al mismo tiempo. Una medición opcional ausente no debe bloquear la tarea principal. Este comportamiento también protege la privacidad: evita recopilar un identificador sustituto por cada señal no disponible.
En producción, copia solo los campos que respondan a una pregunta definida y etiqueta el estado de navegación que los produjo. Un redireccionamiento, una restauración de caché y una carga en frío son eventos distintos. Mantén los analizadores tolerantes a campos nuevos y trata un campo no soportado como ausente, sin inventar un reemplazo. Así los paneles son más interpretables y se reduce la recopilación innecesaria.
Temporización de recursos sin sobreinterpretar
Las entradas de recursos ayudan a explicar una hoja de estilos, imagen, script o fetch lento, pero no son una traza de red completa. El navegador puede aplicar reglas de timing-allow-origin, reducir precisión, omitir entradas o expulsar las antiguas del búfer. Un recurso también puede venir de memoria o de un service worker. Compara su función y resultado, no solo una duración.
Al registrar resultados, prefiere agregados acotados como «la vista previa opcional terminó» o «se mantuvo visible la fuente de respaldo». No subas por defecto una lista completa de URLs y tiempos. Si soporte necesita una traza, haz explícita la captura, limita su vida y elimina consultas o identificadores innecesarios.
Los búferes son estado operativo. Una aplicación ocupada puede llenarlos y expulsar entradas antiguas; una prueba temprana puede ver una lista incompleta. Define el momento de observación, registra si el búfer estaba lleno y no interpretes una lista vacía como prueba de que no hubo solicitud. Para recursos de otro origen, explica los límites de timing-allow-origin para no confundir una duración ausente con un fallo de red.
Marcas, medidas y trabajo de la aplicación
performance.mark() y performance.measure() describen trabajo nombrado por la propia página. Son útiles para regresiones porque el equipo controla los puntos inicial y final, pero no equivalen a hitos de navegación. Una medida larga puede incluir planificación, entrada del usuario o una pestaña en segundo plano, mientras un campo de navegación representa una fase del navegador.
Mantén nombres estables y documenta qué incluye cada medida. Una medida que cruza una solicitud opcional debe informar por separado cancelación y reintento. Así un cambio temporal es accionable sin convertir nombre, duración o URL en un perfil entre sesiones. La regla vale con configuración básica o avanzada: compara el resultado de la aplicación junto con el modo documentado.
Para regresiones, relaciona cada medida con un criterio visible: contenido utilizable, interacción completada o alternativa mostrada. Coloca las marcas cerca de la operación y registra la cancelación aparte. Esto evita que una tarea secundaria domine la comparación y permite comparar modos sin exigir distribuciones numéricamente idénticas.
Precisión, privacidad y repetibilidad
Los navegadores reducen deliberadamente la precisión de algunos relojes. El aislamiento entre orígenes, las políticas de seguridad, la limitación en segundo plano y las versiones pueden cambiar la resolución disponible. Una prueba que espera una fracción exacta es frágil. Comprueba orden, estados razonablemente no nulos y relaciones entre entradas.
El modo avanzado sirve cuando se necesitan los intervalos documentados para una carga controlada. Guarda modo, configuración de intervalos, versión del navegador, versión del perfil y nombre de carga en el registro de prueba. El resumen estable describe la consulta de tiempos sin mutación, no una propiedad del usuario. Borra trazas tras la ventana de comparación y conserva solo el resultado necesario.
La repetibilidad tiene límites. Un resumen estable de una consulta de tiempos sin mutación no congela la carga del servidor, la planificación del sistema, la congestión ni un paquete JavaScript cambiante. Registra esas dimensiones y compara rangos u orden, no una única muestra. Si una fijación cambia, revisa primero la carga y la política del navegador.
Revisar una ruta de proxy
La revisión es más sólida cuando separa responsabilidades. El navegador posee las entradas locales; el servidor, las marcas de recepción, el estado y la finalización; el proxy o gateway, la salud de la ruta, los fallos de conexión y los eventos de política. Comparar puede localizar un segmento lento sin atribuir toda demora a una capa.
Usa un endpoint sintético o una carga autorizada de staging. Incluye caché caliente y fría, redirección, fallo de un recurso opcional y reintento. Compara fases amplias y resultados, no microsegundos para clasificar un navegador. Un cambio de proxy que altera el transporte se revisa como cambio de red aunque el navegador siga siendo coherente.
Escribe el mapa de responsabilidades junto a la fijación: qué tiempos vienen de página, servidor y gateway. Usa identificadores de correlación que caduquen con la ejecución, no identificadores de cuenta. Una discrepancia invita a inspeccionar el segmento relevante; no demuestra engaño de una capa.
Las señales anti-bot no son una sola API
Los sistemas anti-bot pueden combinar API del navegador, observaciones del servidor, historial de cuenta, ritmo y metadatos de transporte. La opción resuelve una cuestión de coherencia del navegador, pero no reescribe IP, TLS, cookies, acciones o autenticación. Un tiempo plausible es solo una entrada de una decisión mayor.
En una integración autorizada, documenta lo que puedes medir y lo que no. No copies la lógica privada de un desafío en una prueba del cliente. Valida que la aplicación funcione con precisión reducida, una entrada ausente o una ruta lenta. Así obtienes compatibilidad sin exponer reglas privadas.
La misma disciplina sirve al evaluar proveedores. Prueba comportamiento documentado con tráfico sintético y no infieras una puntuación oculta a partir de pocas muestras. Juzga la configuración por compatibilidad, pruebas previsibles y límites claros de privacidad.
Lista de despliegue acotada
Empieza con el modo básico en un perfil representativo y confirma entradas de navegación y recursos en los navegadores admitidos. Añade el avanzado solo cuando una prueba o política documentada necesite sus intervalos experimentales. Conserva una fijación que compare entradas modernas con la representación antigua y otra que ejercite un recurso opcional ausente.
Durante el despliegue compara finalización, cancelación, reintento y recuperación. No compares usuarios por trazas crudas. Si cambia el resultado tras una versión, comprueba primero API, precisión, caché y carga. Solo después decide si hay que revisar la configuración.
Mantén un registro corto y reproducible: modo, configuración de intervalos si aplica, versión del navegador, versión de la fijación y resultado agregado. Revísalo tras cambios de navegador, caché o rutas. Si la página sigue siendo utilizable sin una medición opcional, conserva ese comportamiento en vez de crear otra vía de recopilación.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.