Como criar um benchmark no navegador que não trava

Benchmarks falham de maneiras constrangedoras. Travam em 97%. Mostram um número que muda 30% entre testes. Dão ao notebook uma pontuação menor por ele ter uma tela melhor. Ao reconstruir o nosso para a versão 2.0, mantivemos esses modos de falha à vista e projetamos uma resposta específica para cada um. Aqui estão algumas notas do processo.

Invertendo a medição

Carga fixa mais FPS medidos é o formato tradicional e, no navegador, quase inútil: máquinas rápidas encostam na taxa de atualização da tela — o navegador não renderiza além do vsync, portanto tudo que é bom informa “60” ou “120” —, enquanto máquinas lentas produzem uma apresentação de slides que mede paciência, não desempenho.

Então fixamos o alvo: um orçamento de 16,67 ms por quadro, deixando a carga variar. Cada cena aumenta a contagem de partículas até os quadros ultrapassarem o orçamento, faz uma busca binária no limite e exige três janelas limpas consecutivas antes de aceitar um nível. O resultado, a “carga estável máxima”, tem significado físico fácil de imaginar: esta máquina move 840.000 partículas de nebulosa antes de começar a perder quadros.

Um benchmark invertido também falha de forma útil por construção. Um dispositivo modesto não produz um teste quebrado; apenas se acomoda em um degrau inferior da mesma escala.

Percentis, porque engasgos mentem

Cada janela é julgada pelo tempo médio de quadro e pelo 95º percentil. O critério p95 existe porque médias lavam engasgos: uma máquina que entrega 95 quadros no prazo e 5 a 40 ms parece ruim e tem média aceitável. Portas por percentil transformam “parece ruim” em número. Uma janela anormal — notificação ou pausa do coletor de lixo — é repetida em vez de contada, mas duas falhas seguidas rejeitam o nível. Tolerante com acidentes, intolerante com padrões.

A máquina de estados paranoica

O requisito “não pode travar” produziu o código menos vistoso e mais essencial do projeto. Cada cena percorre uma máquina de estados — preflight, baseline, warmup, ramp, bracket, confirm e anchor — e todo estado tem uma saída rígida:

• uma cena recebe 30 segundos e o teste, 150; ponto final;
• ocultar a aba invalida a janela atual e pausa a medição; mais de 30 segundos em segundo plano encerram o teste com um motivo explícito;
• redimensionar ou mudar a proporção de pixels reconstrói e reaquece a cena em vez de medir lixo;
• perda do contexto WebGL, GPU sem entregar quadro por vários segundos ou exceção da cena têm motivos próprios de saída, e um watchdog continua marcando o tempo mesmo quando o loop de renderização não consegue;
• Escape funciona em todos esses estados, porque um botão de cancelar que só responde quando tudo está saudável não é um botão de cancelar.

O teste pode terminar cedo, degradado ou cancelado. A única coisa que não pode fazer é ficar parado para sempre.

Honestidade térmica

Carga contínua aquece a máquina; uma máquina quente reduz a velocidade; um benchmark que ignora isso mistura em silêncio o melhor minuto do dispositivo com o pior. Cada cena mede uma carga leve duas vezes — no início e no fim. Se a segunda leitura ficar mais de 15% lenta, a cena recebe a marca degradada. A marca chega à folha de resultados e à pontuação — com dedução limitada — e, se você enviar a amostra, também ao conjunto de dados, para que as medianas públicas excluam testes limitados por temperatura em vez de absorvê-los.

Justiça para telas de alta frequência

Uma armadilha sutil: se julgarmos pela própria janela de atualização, um notebook de 120 Hz precisa renderizar cada quadro em 8,3 ms para “acompanhar a tela” — o dobro da exigência de uma máquina de 60 Hz. Nosso orçamento é 16,67 ms para todos. Telas rápidas continuam mostrando sua vantagem quando a carga é leve, mas a linha de aprovação fica no mesmo lugar em todo painel. O monitor é uma escolha de visualização; o benchmark mede o computador por trás dele.

O que deixamos de fora de propósito

WebGPU ainda não. Se chegar, será um perfil separado com seu próprio espaço de pontuação, nunca uma troca silenciosa sob o mesmo número. Também não usamos web workers para renderizar nesta versão: a superfície extra de falhas — morte do worker, transferência de contexto, entrada entre threads — contrariava a exigência de nunca travar, e a carga medida seria igual. E não exibimos percentis no resultado até o conjunto anônimo cruzar limiares reais: um percentil calculado sobre quarenta testes é uma impressão fantasiada de número.

A especificação completa, incluindo a matemática da pontuação, está na metodologia. Se você encontrar um dispositivo em que algo disso não se sustenta, é um bug: admin at screentest.pro.