Summary

  • O primeiro rascunho público do W3C, de 26 de outubro de 2010, apontou o buraco no cronômetro iniciado por script: a navegação já tinha começado antes de o script executar.
  • A Recomendação de 17 de dezembro de 2012 padronizou marcas do navegador para navegação, DNS, conexão, resposta e preparação do documento. Cabe ao site escolher o que medir e consertar.

O hóspede chega ao hotel com a mala torta e a paciência gasta. Esperou transporte, procurou o endereço, achou a entrada e ainda encarou uma fila. O recepcionista só liga o cronômetro quando ele alcança o balcão. Entrega a chave em meio minuto e comemora a agilidade. O hóspede conhece outra história, bem mais comprida. Um script no topo de uma página media o carregamento mais ou menos assim.

O primeiro rascunho público de Navigation Timing, publicado em 26 de outubro de 2010, mostrou a falha usando um pequeno exemplo. O código registra a hora quando roda e compara com o evento de carregamento. A conta esquece o tempo necessário para obter o documento que contém o próprio código. Antes do script falar, o navegador já podia ter procurado o endereço, aberto uma conexão e esperado a resposta. O usuário pagou por esses segundos; o relógio da página não os recebeu.

A proposta pediu ao navegador uma memória melhor. navigationStart assinalava o começo da navegação, e performance.timing expunha esse e outros momentos à página. A subtração entre o fim do carregamento e o começo da viagem era simples. O avanço era de posição: quem anotava o início estava presente no início. O aplicativo passava a ter acesso a observações que jamais reconstruiria olhando apenas para seu próprio script.

O recibo ganhou linhas. fetchStart marcava o início da busca ou da consulta a cache. domainLookupStart e domainLookupEnd cercavam a resolução do nome; connectStart e connectEnd, a conexão. requestStart, responseStart e responseEnd distinguiam o pedido, a chegada do primeiro byte e o recebimento do documento. Outras marcas acompanhavam o DOM até o estado interativo e o evento de carregamento. Uma página lenta deixava de ser um réu genérico. Era possível descobrir se a fila estava na porta, na cozinha ou na arrumação do quarto.

A versão candidata de 2 de junho de 2011 levou a proposta adiante. A Recomendação de 17 de dezembro de 2012 consolidou PerformanceTiming e as regras de cada campo. O histórico de publicações do W3C registra a passagem pelo rascunho de 2010, pelas versões candidatas de 2011 e pelo documento final de 2012. Essa sequência importa: um recibo precisa de nomes aceitos por todos antes de servir numa discussão sobre a conta.

A leitura exige cuidado. Se o navegador aproveita uma conexão já aberta, não existe nova conexão para cronometrar. Se usa cache, algumas etapas da rede encolhem ou passam a compartilhar horário. Marcas iguais não indicam, por si, erro. Quem interpreta uma linha vazia como prova de pane pode acabar cobrando do hóspede um táxi que ele não tomou. A Recomendação especificou como representar esses casos justamente para que a economia de uma etapa não parecesse defeito de medição.

Ela também cuidou do relógio. Os horários da navegação precisam avançar de forma monotônica; um ajuste do relógio do sistema não pode produzir um intervalo negativo entre eventos sucessivos. Imagine uma fatura dizendo que o elevador chegou antes de sair. O problema já não seria a velocidade do hotel, mas a credibilidade da fatura. Para decidir o que corrigir, primeiro é preciso confiar na ordem dos acontecimentos.

Alguns detalhes ficam ocultos por desenho. Quando um redirecionamento cruza origens diferentes, os campos que revelariam seus horários detalhados são zerados. A página de destino não recebe uma janela para o trajeto privado de outra origem. O texto de 2012 também observou que autores diferentes hospedados sob o mesmo nome podem compartilhar uma origem, ainda que não compartilhem interesses. Medir mais não dispensa pensar em quem pode ver a medição.

O navegador não enviava relatórios por conta própria e a interface não acelerava um site. Desde 2010, o W3C deixava coleta, armazenamento e divulgação para a aplicação. O documento de 2012 ainda dizia que esses horários não constituíam, sozinhos, um campeonato entre navegadores. Uma visita carrega aparelho, rede, cache e página específicos. O recibo identifica partes do percurso; quem administra o serviço precisa comparar viagens parecidas e escolher uma intervenção.

Essa divisão mudou o tom da investigação. «A página está lenta» permite que todos apontem para alguém. «O primeiro byte chegou rápido, mas o DOM demorou a ficar interativo» já coloca uma peça concreta sobre a mesa. O navegador entregou a conta discriminada. Faltava ler as linhas antes de chamar o gerente do hotel.