Summary

  • El primer borrador público de Navigation Timing apareció el 26 de octubre de 2010; la Recomendación del 17 de diciembre de 2012 fijó una serie de marcas del navegador desde el inicio de la navegación hasta la carga.
  • El navegador ofreció las horas. La aplicación conservó la tarea de reunirlas, compararlas y arreglar aquello que realmente retrasaba la visita.

Imagine a un viajero que entra en un hotel después de perder el tren, buscar la dirección y esperar ante una puerta cerrada. El recepcionista activa el cronómetro cuando lo ve cruzar el vestíbulo y anuncia, orgulloso, un registro de veinte segundos. La cifra es exacta. La experiencia del viajero ha durado mucho más. Algo parecido le ocurría a una página que intentaba medir su propia carga con un reloj iniciado en el primer script.

El borrador inicial del W3C, de 26 de octubre de 2010, usó precisamente ese problema. Un script colocado en la cabecera podía anotar la hora de ejecución y restarla de la hora del evento de carga. No sabía cuánto había tardado en llegar el documento que contenía el script. La petición, la conexión y la espera previa quedaban fuera de la factura. El usuario, naturalmente, había pagado cada segundo.

La propuesta pidió al navegador que aportara su propio registro. navigationStart situaba el comienzo de la visita antes de que el código de la página pudiera intervenir. Con performance.timing, la aplicación podía leer esa hora y compararla con los hitos posteriores. Una resta sencilla acercaba el cálculo al tiempo que había vivido la persona al otro lado de la pantalla. El salto conceptual era mayor que la operación: la página recibía datos de un tramo que por sí sola no podía observar.

El nuevo registro no se limitaba a una hora de salida y otra de llegada. fetchStart señalaba el inicio de la recuperación o de la consulta al caché. domainLookupStart y domainLookupEnd acotaban la búsqueda del nombre. connectStart y connectEnd marcaban la conexión. requestStart, responseStart y responseEnd dejaban ver la petición y la llegada del documento. Después venían las etapas de preparación del DOM y los eventos de carga. Si un sitio era lento, se podía preguntar en qué mostrador se había formado la cola.

La versión candidata del 2 de junio de 2011 llevó la propuesta por el proceso de normalización. La Recomendación de 17 de diciembre de 2012 estableció la interfaz PerformanceTiming y las reglas para interpretar sus campos. La historia de publicaciones del W3C muestra los peldaños entre el primer borrador de 2010 y el texto final. Un recibo útil necesitaba nombres y límites compartidos, no solo una colección de números que cada navegador entendiera a su manera.

Algunas líneas del recibo podían coincidir. Si el navegador reutilizaba una conexión, no había una nueva conexión que cronometrar. Si encontraba el documento en el caché, varias etapas de red se reducían o cambiaban de significado. Por eso dos marcas iguales no anunciaban necesariamente un fallo. El W3C describió estos casos en vez de fingir que todas las visitas salen de casa, toman el mismo taxi y pasan por las mismas puertas.

También cuidó la integridad del reloj. La Recomendación exigió que los tiempos sucesivos se construyeran con un reloj monótono, de modo que un ajuste de la hora del sistema durante la navegación no produjera una duración negativa. Sería difícil convencer al viajero de que la habitación estuvo lista tres minutos antes de que llegara al hotel. En medición, una pequeña regla del reloj puede sostener toda la conversación posterior.

Había, además, puertas que convenía mantener cerradas. Cuando una redirección cruzaba orígenes, las marcas detalladas de esa redirección se ponían a cero. Una página no debía recibir, por el mero hecho de ser destino de un enlace, un historial minucioso de otra. El texto de 2012 incluso advirtió que páginas de autores distintos bajo un mismo origen pueden compartir más información de la que esos autores imaginan. La precisión técnica tiene un perímetro social.

El estándar no recopilaba datos automáticamente ni ordenaba a un sitio qué mejorar. Su primer borrador dejó la recolección, el almacenamiento y la presentación fuera del alcance de la interfaz. La Recomendación añadió que aquellas marcas no servían, por sí mismas, para proclamar un navegador vencedor sobre otro. Una visita concreta depende del dispositivo, la red, el caché y la página. El reloj ayuda a diagnosticar; no repara el ascensor, ni decide qué obra conviene pagar.

Aun así, la discusión cambió. Antes se podía decir «la web tarda» y señalar al culpable habitual. Con Navigation Timing, una aplicación podía comprobar si la espera estaba antes del primer byte, durante la descarga o en su propia preparación del documento. El navegador llevó la cuenta a la recepción. Había menos espacio para cobrar todo el retraso a un único tramo del viaje.