Para diminuir o input lag, comece pelo que o software consegue encurtar: um driver segurando um núcleo do processador, um hook no caminho de entrada ou uma porta USB suspensa, e a fila de apresentação da GPU quando a GPU é o gargalo. O resto da cadeia é do dispositivo, do jogo e da tela. Como ler o teste de latência mostra como achar o primeiro desses na sua própria máquina; no CS2, o limite de quadros e a taxa de atualização que o próprio jogo salvou estão no checklist do CS2. Entre o instante em que um switch fecha sob o seu dedo e o instante em que a tela mostra o resultado, há cerca de uma dúzia de etapas. O software é dono de três delas. O firmware é dono de quatro, a tela é dona de três, e o jogo é dono do resto. Toda ferramenta que promete "eliminar o input lag" ou está falando dessas três, ou não está te dizendo a verdade.
Esta página percorre a cadeia inteira, diz de quem é cada etapa, e depois dá três listas: o que uma ferramenta consegue encurtar, o que só um hardware diferente encurta, e o que nada encurta. Ela existe porque as outras três páginas sobre latência deste site só são confiáveis se esta aqui existir.
Uma causa no Windows 11 tem correção própria: a atualização da Microsoft de 13 de outubro de 2026 corrige um problema que podia fazer a entrada do mouse travar em alguns jogos; é a KB5127648 nas versões 24H2, 25H2 e 26H2 e a KB5127646 na 26H1 (Microsoft). Se o seu mouse começou a travar em alguns jogos, confira se essa atualização está instalada antes de mudar qualquer outra coisa.
A cadeia, etapa por etapa
| # | Etapa | Dono | Encurtável por software? |
|---|---|---|---|
| 1 | O switch fecha; o controlador do dispositivo varre e faz o debounce | Firmware do dispositivo | Não |
| 2 | O dispositivo disponibiliza um relatório no intervalo de polling dele | Firmware do dispositivo | Não |
| 3 | Salto de rádio, se o dispositivo for sem fio | Dispositivo + receptor | Não |
| 4 | O controlador do host recolhe o relatório; os drivers de classe o passam para cima | Windows + driver de chipset | Só corrigindo um driver ruim |
| 5 | Drivers de filtro e hooks de baixo nível no caminho de entrada | Software de terceiros | Sim |
| 6 | O jogo lê a entrada — na maioria das engines, uma vez por frame | O jogo | Indiretamente, pela taxa de quadros |
| 7 | O jogo simula o tick e monta o frame | O jogo | Não |
| 8 | O frame entra na fila de apresentação da GPU | Jogo + driver de vídeo | Em parte |
| 9 | A GPU renderiza o frame | GPU | Não |
| 10 | O frame espera a próxima varredura da tela | Intervalo de atualização da tela | Não |
| 11 | O processamento da própria tela — escalonador, overdrive, qualquer modo de imagem | Firmware do monitor | Não |
| 12 | Os pixels do painel mudam fisicamente | Painel | Não |
Nove dessas doze não são software. Essa proporção é o argumento inteiro desta página.
Os três custos fixos que as pessoas esquecem
O intervalo de atualização
Um frame pronto não aparece quando fica pronto. Ele aparece na próxima varredura da tela. Como um frame termina num ponto arbitrário dentro desse intervalo, em média ele espera metade de um, e essa média é aritmética, não medição:
| Taxa de atualização | Um intervalo | Espera média pela próxima varredura |
|---|---|---|
| 60 Hz | 16,7 ms | 8,3 ms |
| 120 Hz | 8,3 ms | 4,2 ms |
| 144 Hz | 6,9 ms | 3,5 ms |
| 240 Hz | 4,2 ms | 2,1 ms |
| 360 Hz | 2,8 ms | 1,4 ms |
É por isso que uma tela mais rápida reduz a latência de um jeito que nenhum valor de registro consegue comprar.
Há uma exceção que vale conferir agora mesmo, porque não custa nada: um monitor que suporta uma taxa de atualização alta, mas roda a 60 Hz, por exemplo porque ninguém mudou isso depois de instalar o Windows ou de trocar um cabo. A página Início do w0a confere cada tela conectada e avisa direto — "Seu monitor não está rodando na velocidade máxima" — com um botão que sobe a tela que ela aponta. Num notebook, ela deixa como está um painel de 60 Hz que oferece 120 Hz ou mais, porque a taxa de atualização dinâmica pode rodá-lo a 60 Hz de propósito. O caminho do próprio Windows é Configurações → Sistema → Tela → Exibição avançada.
O processamento da própria tela e o painel
Depois que a varredura começa, o monitor ainda tem trabalho a fazer: escalonamento, se o sinal não estiver na resolução nativa, overdrive, e o que quer que o modo de imagem atual aplique. Depois disso os pixels têm que mudar fisicamente, e isso é o tempo de resposta do painel.
Nenhum dos dois números é legível a partir do seu PC. O Windows enxerga uma tela, não uma pipeline, e nenhum software na sua máquina consegue medir ou encurtar qualquer um dos dois. Os números de tempo de resposta dos fabricantes são medidos em condições escolhidas pelo próprio fabricante e não são comparáveis entre marcas, então, se isso importa para você, a única fonte honesta é uma análise independente que publique o método dela.
O que você consegue fazer não custa nada: rode o painel na resolução nativa dele, para que nenhum escalonador entre no caminho, e procure um modo de imagem de baixa latência ou de jogo no menu do próprio monitor — essa configuração normalmente desliga o processamento que mais acrescenta.
O cabo
O cabo está nesta lista para ser tirado dela. A viagem do sinal por um cabo de vídeo é uma questão de nanossegundos; ele não é fonte de nada que você consiga sentir. Um cabo fora de especificação para a sua resolução e taxa de atualização causa quedas, telas em branco e um link que cai para uma taxa de atualização menor — e essa queda de taxa de atualização é um custo real de latência, pela tabela acima. Então confira em que taxa de atualização você está rodando de verdade. Não compre cabo para reduzir lag.
A fila de apresentação — o único ponto no meio que é negociável
Entre o jogo terminar um frame e a GPU renderizá-lo existe uma fila. Uma fila mais profunda mantém a GPU alimentada e aumenta a vazão; ela também significa que o frame que você está olhando foi montado a partir de uma entrada lida mais longe no passado.
Esta é a etapa em que os recursos de latência dos fabricantes atuam, e vale ser preciso sobre o que eles fazem:
- Eles reduzem a fila quando a GPU é o gargalo. Quando ela não é, não há nada para eles reduzirem.
- Eles reduzem latência. Não existe medição publicada mostrando que eles melhoram os percentis de tempo de quadro, e é fácil confundir as duas coisas. Instalação limpa para 1% lows estáveis percorre em detalhe a evidência publicada sobre as configurações de sincronia e de limite, com fontes.
O modo de apresentação também importa aqui, e essa parte é do Windows: se um jogo é composto pela área de trabalho ou apresentado diretamente muda quantos buffers ficam no caminho. Se essas configurações foram alteradas na sua máquina, otimizações de tela cheia e apresentação de jogos em janela restauram os padrões do Windows, e tweaks de vídeo e gráficos é a página por entrada do que o w0a altera ali.
O que dá para medir de fato a partir da sua própria máquina
O total, não. Três partes dele, e o Teste de Latência do w0a é explícito sobre quais três. A página imprime um número chamado Piso do sistema, e ele é a soma exatamente de:
- Caminho de entrada (P99) — a espera do 1% pior dos seus relatórios de entrada
- Interrupção de driver mais longa — o maior tempo que um driver segurou um núcleo do processador, somado apenas quando ele foi de fato medido
- Espera da tela (meia varredura) — metade do seu intervalo de atualização, pela razão da tabela acima
E então a página diz, dentro do produto, o que está faltando: "Isto é um piso, não um total. A amostragem de entrada do próprio jogo, sua fila de renderização, o trabalho da GPU e o tempo de resposta do painel não estão nele — nenhum deles pode ser medido a partir desta máquina. Ferramentas que imprimem um único número de 'input lag: X ms' estão estimando essas partes."
Essa frase é a razão de este artigo existir. Uma ferramenta que imprime um único número confiante de latência de ponta a ponta estimou as etapas 6 a 12 da tabela acima. Pode ter estimado de forma razoável. Ela não as mediu, e deveria dizer isso.
Medir de ponta a ponta direito exige uma câmera. O método estabelecido é uma câmera de alta velocidade apontada para o mouse e para a tela, contando os quadros entre o clique e a resposta, ou um aparelho dedicado de medição de latência. Nada que rode como um programa dentro da máquina que está sendo medida consegue fazer isso, porque o programa está dentro daquilo que ele tenta medir.
O que uma ferramenta consegue fazer, honestamente
Três coisas, e elas não são pouca coisa:
- Encontrar um driver segurando um núcleo do processador. Um driver dentro de uma interrupção ou de uma chamada adiada roda acima de qualquer prioridade de thread — ele não aparece em nenhum gráfico de tempo de quadro nem em nenhum gerenciador de tarefas. O Teste de Latência diz o nome do arquivo e ordena pela retenção mais longa. A 1 ms ele está deslocando relatórios; a 4 ms a máquina não consegue sustentar um tempo de quadro estável. A solução é atualizar aquele driver pelo fabricante do hardware.
- Mostrar a taxa de relatório medida ao lado da alegada. A página Portas USB mostra o que cada dispositivo pediu ao lado do que ele entrega. Por que minha mira parece atrasada é a versão longa.
- Tirar software do caminho de entrada e impedir que portas sejam suspensas. Um hook travado ou uma porta suspensa é um atraso real e removível. Por que as teclas parecem responder com atraso nos jogos percorre isso.
Todo o resto que uma ferramenta de ajuste altera é sobre consistência — menos despertares em segundo plano, um plano de energia que não derruba os clocks no meio de um confronto, um agendador que cumpre os prazos dele. Isso vale a pena ter e é mensurável em tempo de quadro. Não é a mesma afirmação que menos latência de entrada, e este site não vai apresentá-la como se fosse.
O que nos recusamos a fazer, e por quê
Algumas configurações que circulam como correções de latência são justamente as que o w0a se recusa a gravar:
- Valores de gerenciamento de memória do kernel.
DisablePagingExecutive,LargeSystemCache,NtfsMemoryUsage, sobrescritas de resolução de timer. Esses são recusados sem exceção. A página Fix ainda consegue removê-los, porque uma máquina em que uma ferramenta mais velha já mexeu tem que ser reparável. - Valores de registro de MPO e de TDR.
OverlayTestMode,DisableOverlays,TdrDelay,TdrLevel. Numa máquina real, esses travaram o CS2. O w0a reparaTdrDelayde volta ao padrão do Windows em vez de aumentá-lo. Se uma ferramenta anterior desativou o multi-plane overlay no seu sistema, tela e vídeo devolve o padrão e recuperação de travamento da GPU cobre o lado do TDR.
Uma ferramenta que se recusa a gravar um valor que não consegue defender é mais útil que uma que grava tudo e deixa você descobrir depois.
Um protocolo que de fato te diz alguma coisa

Você não consegue medir latência de ponta a ponta sem uma câmera. Você consegue medir se uma mudança ajudou, e essa costuma ser a pergunta que você tem de verdade.
- Resolva primeiro o problema de hardware que é grátis. Confira se a taxa de atualização está no máximo, se o painel está na resolução nativa, e se o monitor está no modo de imagem de baixa latência dele.
- Tire o piso. Rode o Teste de Latência pelos 12 segundos inteiros e anote o Piso do sistema e as três partes dele.
- Faça uma captura de referência. Abra o Benchmark, grave a mesma cena por um ou dois minutos, e guarde o FPS médio, o 1% low e o número de engasgos.
- Mude uma coisa. Uma. Cinco mudanças e uma medição não te dizem nada sobre qual delas importou.
- Repita os passos 2 e 3 de forma idêntica. Mesma cena, mesmas configurações, mesmos aplicativos em segundo plano.
- Julgue contra o seu próprio ruído. Rode a configuração sem alteração três vezes. Se essas três variarem mais do que a diferença que te empolgou, o que você achou foi ruído.
- Desfaça o que não mexeu em nenhum número. É para isso que servem os cartões da página Fix, e esse é um desfecho melhor do que carregar uma mudança que não faz nada e sair dizendo aos outros que funciona.
Se o que você está perseguindo é um solavanco ocasional em vez de um atraso constante, o que a análise de engasgos procura é a página certa — ela rotula cada achado como comprovado, provável, candidato ou não verificado, e é deliberadamente honesta sobre o que não consegue enxergar dentro de um jogo.
O resumo, em um parágrafo
Das doze etapas entre o seu dedo e o fóton, o software consegue encurtar três, e só quando alguma coisa está de fato errada nelas. Os maiores custos que sobram — o intervalo de polling do dispositivo, a leitura de entrada por frame do jogo, o intervalo de atualização da tela e o próprio painel — pertencem ao hardware e ao jogo. Uma ferramenta que vale a pena instalar te diz quais das três que ela alcança estão quebradas na sua máquina, mede o que honestamente consegue medir, e se recusa a estimar o resto. É uma promessa menor que a que você vem lendo por aí, e é a única que sobrevive a uma câmera.
Relacionados
- Por que as teclas parecem responder com atraso nos jogos
- Por que minha mira parece atrasada
- Ouço os passos depois de ver o inimigo
- Como ler o teste de latência
- O que a análise de engasgos procura
- Como ler o benchmark
Esta página ajudou?
O que faltou, ou o que não funcionou? Lemos cada uma dessas respostas.
Se esta página não resolveu, escreva para nós — diga qual artigo você leu, e nós vamos corrigi-lo.