O sistema abre rapidamente, mas trava quando alguém filtra uma tabela, escolhe um cliente ou confirma uma solicitação. A equipe chama tudo de “lentidão”, embora o problema possa estar no navegador, no servidor ou na forma como a interface responde enquanto espera.
INP, Interaction to Next Paint, ajuda a avaliar a capacidade da página de responder visualmente às interações. Ele não mede sozinho o tempo necessário para concluir uma consulta ou uma tarefa de negócio.
Carregamento e interação são problemas diferentes
Uma página pode entregar o conteúdo inicial rapidamente e ocupar a thread principal com trabalho pesado depois. Ao clicar, o usuário espera o navegador processar eventos e apresentar a atualização visual. Isso produz a sensação de botão que não funciona, mesmo antes de uma requisição chegar ao servidor.
A documentação do web.dev descreve INP e orientações para avaliar responsividade. Como referência de classificação, apresenta até 200 ms como bom, acima de 500 ms como ruim e a faixa intermediária como precisando de melhoria, observando o percentil apropriado. Esses limites não substituem a análise da tarefa e do dispositivo utilizado.
Descubra onde o tempo está sendo gasto
Em um exemplo hipotético, um dashboard recebe muitos registros e recalcula todos os agrupamentos a cada tecla digitada. O backend responde bem, mas a interface bloqueia enquanto processa. Aumentar a VPS não corrige esse trabalho no navegador.
Em outro caso, a interface reconhece o clique imediatamente, mostra carregamento e aguarda uma consulta lenta. A experiência ainda precisa melhorar, mas a causa é diferente. Medir a reação visual e a conclusão da tarefa separadamente evita otimizar a camada errada.
| Sintoma | Hipótese | Como investigar |
|---|---|---|
| Clique demora a reagir | Thread principal ocupada | Perfil de desempenho no navegador |
| Indicador aparece, dados demoram | API ou processamento remoto | Duração da requisição e rastreamento |
| Digitação engasga | Cálculo ou renderização por tecla | Comparar com processamento adiado |
| Tela fica pesada após uso longo | Acúmulo de estado ou elementos | Repetir a jornada e observar recursos |
Tabelas e filtros merecem atenção especial
Carregar todo o histórico para depois filtrar no navegador pode parecer simples no protótipo. Em produção, o volume muda. Paginação, filtros no servidor e seleção de campos podem reduzir transferência e trabalho, desde que preservem o resultado correto e as permissões.
Virtualização pode ajudar a renderizar listas grandes, mas exige cuidado com acessibilidade, navegação e altura dos elementos. Não deve ser aplicada apenas porque o nome parece uma otimização avançada. Teste se a solução melhora a tarefa sem esconder informação ou quebrar o teclado.
Quando o usuário digita um filtro, nem sempre é necessário executar a operação completa em cada caractere. Adiar uma busca pode reduzir trabalho, mas o intervalo não deve deixar a pessoa sem resposta. Mostre o estado de forma clara e descarte resultados antigos que chegam fora de ordem.
Feedback rápido não pode criar confirmação falsa
Uma interface pode mostrar que recebeu o clique antes de o servidor concluir a operação. Isso é útil quando o estado é apresentado honestamente: enviando, processando ou aguardando confirmação. Exibir “salvo” antes da persistência exige uma estratégia consistente para falha e reversão.
Também impeça efeitos duplicados. Um usuário pode clicar novamente porque não percebeu resposta. Desabilitar temporariamente o botão ajuda na interface, mas o servidor precisa tratar repetição quando a ação tem impacto, como uma cobrança ou um envio.
Meça no dispositivo que a equipe realmente usa
Um notebook potente de desenvolvimento não representa todos os usuários. Teste celulares, máquinas comuns, conexão variável e sessões com dados representativos. O objetivo é identificar os caminhos que limitam o trabalho, não apenas obter uma pontuação alta em um cenário favorável.
Dados de campo e testes de laboratório se complementam. O laboratório ajuda a reproduzir e diagnosticar; o campo revela a distribuição real. Sistemas autenticados ou com pouco volume podem não ter dados públicos suficientes. Nesse caso, instrumentação própria, com minimização de dados, pode ser necessária.
Roteiro de otimização
- Escolher uma interação problemática concreta.
- Medir reação visual e conclusão da tarefa.
- Identificar trabalho no navegador, rede e servidor.
- Corrigir o maior gargalo comprovado.
- Testar volume, teclado e dispositivos representativos.
- Comparar antes e depois com o mesmo cenário.
- Acompanhar erros e qualidade do resultado, além de velocidade.
Perguntas frequentes
Melhorar INP garante um sistema rápido?
Não. É um indicador de responsividade. Consultas, processamento em fila, carregamento e qualidade da experiência também precisam ser avaliados.
Uma nota de laboratório representa todos os clientes?
Não. Ela depende das condições de teste. Use resultados controlados para diagnóstico e observe dados reais quando disponíveis.
Preciso trocar a tecnologia do frontend?
Não necessariamente. Volume de dados, renderização, cálculos e desenho da interação podem ser causas mais importantes do que a biblioteca usada.
Referência e próximo passo
Consulte a documentação de INP no web.dev para definição e classificação. Os exemplos e o roteiro são aplicações editoriais para sistemas de gestão.
Se sua operação convive com telas travadas, comece pela auditoria técnica e conheça a evolução de sistemas da A2CR.
