Como observamos o tempo de entrada
Usamos performance.now() dentro de um ciclo requestAnimationFrame para observar intervalos entre eventos de entrada. A coleta dura 10 segundos e exige ao menos 30 amostras válidas. O resultado descreve a observação pelo navegador, não o atraso completo entre apertar um botão e ver a resposta na tela.
O que significa Como observamos o tempo de entrada
O algoritmo de medição exato
Tudo abaixo reflete o código em produção no testador do navegador. Sem caixa preta - a fonte é aberta, as constantes são documentadas, e cada limite tem uma justificativa específica em vez de ser números redondos de marketing.
- 01
loop de polling via requestAnimationFrame
O testador executa um loop de polling contínuo ligado ao ciclo de atualização do display via requestAnimationFrame. Em cada quadro, ele lê a captura Gamepad atual com navigator.getGamepads(), compara cada eixo e botão contra os valores do quadro anterior, e registra um timestamp com performance.now() no momento em que qualquer mudança de entrada é detectada.
- 02
Limites de detecção de mudança
Uma mudança qualifica como evento quando qualquer eixo se move mais de 0.02 em valor absoluto da leitura anterior, ou quando o estado pressionado de qualquer botão inverte. O limite de eixo 0.02 filtra ruído de sensor em analógicos centralizados; sem ele, controles propensos a drift gerariam eventos falsos a cada quadro e distorceriam o resultado artificialmente para baixo.
- 03
Captura de delta entre eventos
Quando uma mudança dispara, o testador registra delta = performance.now() - timeOfPreviousChange. Esse delta é o intervalo que o navegador levou para observar a próxima entrada distinta do controle. Deltas acima de 500ms são descartados como valores atípicos - eles representam pausas entre rajadas de entrada, não latência de medição.
- 04
Janela de amostragem de 10 segundos
A janela ativa dura exatamente 10.000ms após o usuário pressionar iniciar. Durante essa janela, os usuários são instruídos a girar continuamente ambos os analógicos e apertar botões - o objetivo é um fluxo denso de mudanças de estado para que tenhamos deltas suficientes para caracterizar estatisticamente o comportamento real do controle.
- 05
Métricas agregadas
Ao fim da janela, exigimos ao menos 30 deltas válidos para reportar um resultado. A partir desses calculamos mínimo, média, percentil 95 e máximo, mais um histograma de 12 baldes da distribuição completa. A média é o que é avaliado contra a tabela de limites; o histograma revela comportamento bimodal ou instável que uma única média esconderia.
Como observamos o tempo de entrada: limites de latência reportada
As faixas de veredicto abaixo são faixas de interpretação do GPADLAB usadas consistentemente no painel de resultado do testador e no estágio de latência da Pontuação de Saúde do Controle. Elas se aplicam a esta medição de loop de polling observada pelo navegador, não a latência ponta a ponta instrumentada por hardware - um controle reportando 4ms aqui não é equivalente a um resultado de 4ms do botão até a tela.
| Delta médio entre eventos | Avaliação | Significado |
|---|---|---|
| Abaixo de 5 ms | Excelente | Excelente resultado de polling observado pelo navegador neste teste. Pontuação completa de 150 pontos na etapa de latência do Controller Health Score. |
| 5-10ms | Bom | Um resultado forte observado pelo navegador. A latência real de entrada ponta a ponta ainda pode variar por controle, conexão, plataforma, jogo e display. Fica na faixa de 90% da pontuação de saúde. |
| 10-20ms | Intermediária | Um intervalo moderado observado pelo navegador. Modo de conexão, firmware do controle, plataforma, agendamento do navegador e carga do sistema podem influenciar o resultado. Fica na faixa de severidade parcial para pontuação. |
| 20-40ms | Elevada | Um intervalo mais lento observado pelo navegador. Repita o teste em condições semelhantes e compare modos de conexão antes de atribuir o resultado a uma causa específica. |
| ≥ 40ms | Muito elevada | Um intervalo alto observado pelo navegador. Refaça o teste em condições controladas e investigue conexão, carga do sistema, navegador, firmware e comportamento do controle. Pontua zero na etapa de latência. |
Os limites são codificados como T_EXCELLENT=5, T_GOOD=10, T_ACCEPTABLE=20, T_DEGRADED=40 em LatencyTester.tsx e espelhados por scoreLatency() em scoring/index.ts. Ambos os arquivos são a fonte confiável em caso de dúvida.
Teste de Como observamos o tempo de entrada
Soluções Como observamos o tempo de entrada
Outros termos do glossário
perguntas Como observamos o tempo de entrada
Não, e essa distinção importa. O testador lê navigator.getGamepads() dentro de um loop requestAnimationFrame e registra o momento em que mudanças sucessivas de estado se tornam observáveis para a página. Comportamento de reporte do controle, transporte USB ou sem fio, o sistema operacional, agendamento do navegador e cadência do display podem influenciar quando essas mudanças são observadas, mas a medição no lado do navegador não consegue isolar ou somar diretamente esses estágios. O teste não registra o pressionamento físico do botão no controle, a chegada do transporte ao sistema operacional, o processamento do motor do jogo ou a resposta final na tela. Medições ponta a ponta instrumentadas por hardware, portanto, respondem a uma pergunta diferente e não são diretamente comparáveis a este resultado observado pelo navegador.
Duas razões. Primeiro, esse equipamento custa mais de 500 dólares e requer uma configuração física em cada controle - inviável para uma ferramenta no navegador que qualquer um pode usar em dez segundos. Segundo, testes instrumentados por hardware medem uma quantidade fundamentalmente diferente (polegar até fóton) que inclui latência do display, que varia por monitor. Nossa medição isola um componente da cadeia de entrada - o delta do loop de polling - que é comparável entre sessões e controles na mesma máquina host. Ferramenta diferente, trabalho diferente.
A janela de 10 segundos equilibra duas necessidades concorrentes. Tempo suficiente para coletar 200-500 deltas válidos em um controle sendo ativamente trabalhado (entrada densa gera amostras densas); tempo curto o suficiente para que os usuários realmente completem o teste sem ficar entediados e parar antes. Em testes, estender a janela para 30 segundos mudou a média reportada em menos de 5% em controles estáveis - o tamanho da amostra já é grande o suficiente para significância estatística aos 10 segundos.
Abaixo de 30 amostras, o erro padrão da média é grande o suficiente para que reportar um número de latência específico seria uma precisão enganosa. Se o testador terminar a janela com menos de 30 deltas válidos, ele descarta silenciosamente a execução e retorna o usuário a um estado pronto - um sinal para refazer o teste com entrada mais contínua. Esse limite corresponde à verificação sampleCount < 30 em scoreLatency() da biblioteca de pontuação Controller Health Score.
A Gamepad API reporta valores de eixo em ponto flutuante que podem flutuar ligeiramente quadro a quadro mesmo em um analógico parado. Um limite muito pequeno pode fazer com que ruído do sensor ou drift do analógico sejam contados como mudanças repetidas de entrada, o que pode distorcer o intervalo observado para baixo. GPADLAB portanto usa 0.02 como um limite de implementação para reduzir ruído enquanto permanece responsivo a movimentos deliberados do analógico. É um limite prático de detecção de mudança, não um valor de calibração de hardware.
Neste método entre eventos, um delta acima de 500ms geralmente reflete uma pausa longa entre mudanças de estado geradas pelo usuário em vez de uma sequência densa de entradas adequada para o cálculo. Incluir essas pausas faria a média depender fortemente de quão continuamente o usuário moveu os analógicos ou pressionou botões. GPADLAB portanto exclui deltas acima de 500ms deste cálculo; o corte é uma regra de amostragem de entrada, não uma afirmação sobre a latência máxima possível de hardware de um controle.
Números de latência de controle de primeira parte, quando publicados, podem ser medidos com configurações de hardware ou definições que não são diretamente comparáveis a este método baseado em navegador. Os resultados GPADLAB são mais úteis como um sinal comparativo quando o mesmo host, navegador, condições de conexão, procedimento de teste e execuções repetidas são usados. Uma diferença entre duas execuções únicas não deve ser automaticamente tratada como uma diferença de latência em nível de hardware porque cadência do requestAnimationFrame, agendamento do navegador, padrão de entrada do usuário e carga do sistema podem afetar os valores observados.
Sim - este é o aviso mais importante. Chrome, Firefox e Safari limitam os callbacks requestAnimationFrame de abas em segundo plano para 1fps ou menos. Executar o teste em uma aba em segundo plano produzirá resultados sem sentido. O testador requer uma aba ativa em primeiro plano. Não controlamos atualmente o teste na visibilidade do documento, mas adicionar essa verificação está no backlog de polimento. Enquanto isso, execute o teste na aba ativa e não troque de abas durante a janela de 10 segundos.
Leituras complementares
- Gamepad API - MDN Web Docs · MDN Web Docs
- Performance.now() - timestamps de alta resolução · MDN Web Docs
- Limitação do requestAnimationFrame em abas em segundo plano · Chrome for Developers