Para corrigir o INP no WordPress, descubra nos dados de campo quais interações estão lentas e corte o trabalho na main thread em volta delas. O INP (Interaction to Next Paint) mede o tempo entre um clique, toque ou tecla e o momento em que o navegador pinta o próximo frame. O Google considera bom um valor de até 200 milissegundos no percentil 75, e ruim acima de 500 milissegundos. No WordPress as causas de sempre são scripts de terceiros, JavaScript de plugin carregado em todas as páginas, handlers pesados em menus, filtros e carrinho, e DOMs grandes de page builder. Remova ou adie scripts, quebre tarefas longas e diminua o DOM.
O INP virou Core Web Vital em março de 2024, no lugar do First Input Delay. Um site WordPress que passava fácil no FID pode reprovar no INP, porque o INP mede uma parte muito maior do trabalho. Este guia mostra como encontrar a interação lenta e o que mudar num site WordPress. Para entender como o INP se relaciona com o LCP e o CLS, veja Core Web Vitals no WordPress: o guia completo.
O que o INP mede?
Toda interação (clique, toque ou tecla) tem três fases:
- Input delay: o tempo até o navegador conseguir começar a rodar os seus event handlers, normalmente porque outra tarefa já está rodando na main thread.
- Processing duration: o tempo que os seus handlers levam para rodar, contando todos os listeners ligados àquele evento.
- Presentation delay: o tempo de recalcular estilos, rodar o layout e pintar o próximo frame depois que os handlers terminam.
O navegador observa as interações durante a visita inteira. O INP de uma página fica perto da interação mais lenta. Em páginas com muitas interações, um ponto fora da curva é ignorado a cada 50 interações, então o INP reporta um percentil alto em vez de um único clique azarado. Hover e scroll não contam.
O FID só media o input delay da primeira interação. O INP soma processamento e apresentação, e olha todas as interações. Por isso sites com o primeiro clique rápido, mas com um mega menu, um filtro ou um botão de adicionar ao carrinho lento, agora reprovam.
Por que o Lighthouse não mostra o INP?
Um teste do Lighthouse carrega a página sem ninguém tocar nela, então não existe interação para medir. No lugar, o Lighthouse mostra o Total Blocking Time, que conta quanto bloqueio da main thread acontece durante o carregamento. TBT alto normalmente indica INP ruim, mas uma página pode ter TBT baixo e ainda assim uma interação péssima mais adiante na visita. Aprofundo isso em Core Web Vitals: dados de campo vs laboratório.
Para encontrar as interações lentas:
- Veja o valor de INP no PageSpeed Insights ou no relatório de Core Web Vitals do Search Console para saber quais templates reprovam, e em qual dispositivo.
- Adicione o build de attribution da biblioteca web-vitals para coletar interações reais. Ele informa o elemento alvo, o tipo de evento, as três fases e os scripts por trás dos long animation frames.
- Reproduza no painel Performance do Chrome DevTools. Ligue o throttling de CPU, porque o seu notebook é muito mais rápido que os celulares dos seus dados de campo, e grave enquanto abre o menu, escolhe uma variação ou aplica um filtro.
O que causa INP ruim no WordPress?
| Causa | Onde aparece | Correção |
|---|---|---|
| Tags de terceiros (tag manager, chat, heatmaps, consentimento, anúncios) | Input delay durante e depois do carregamento | Remova tags sem uso, carregue o resto depois, teste as ferramentas de consentimento e chat num celular |
| JavaScript de plugin em todas as páginas | Input delay e processamento | Dequeue por template, troca de plugins pesados |
| Event handlers pesados | Processing duration em menus, filtros, seletores de variação, adicionar ao carrinho | Mostre o retorno visual primeiro, adie o resto, faça yield entre as etapas |
| DOM grande de page builder | Presentation delay depois de cada interação | Layouts mais simples, menos wrappers, menos widgets por página |
| “Atrasar JavaScript até a interação” | O primeiro toque dispara o carregamento e a execução de todos os scripts atrasados | Exclua os scripts de que as primeiras interações precisam, meça no campo |
| Layout thrashing nos scripts | Processing duration | Agrupe as leituras do DOM antes das escritas, evite layout síncrono forçado |
A linha dos terceiros é a que mais encontro, e a mais difícil de resolver politicamente. O marketing colocou cada tag por um motivo, e ninguém lembra quais ainda importam. Comece com um inventário: tag, responsável, finalidade, páginas onde dispara. Remover as tags que ninguém consegue justificar costuma ser o ganho de INP mais rápido do site inteiro.
A linha do JavaScript atrasado merece atenção porque parece uma correção. Plugins de cache conseguem segurar scripts até a primeira interação do usuário. As notas de laboratório melhoram, já que nada roda durante o carregamento. Aí o visitante toca no menu, todos os scripts atrasados carregam e rodam de uma vez, e esse toque vira a interação mais lenta da visita. Use o recurso, mas exclua os scripts de que as primeiras interações dependem, e avalie pelo INP no campo, não pelo Lighthouse.
Como reduzir o trabalho de JavaScript no WordPress?
Comece carregando menos. Nos seus próprios scripts, use as estratégias de carregamento que chegaram no WordPress 6.3:
wp_enqueue_script( 'my-menu', $src, array(), $ver, array( 'strategy' => 'defer', 'in_footer' => true ) );
Para scripts de plugin que carregam em todo lugar, faça o dequeue nos templates que não usam esses scripts. Use o hook wp_enqueue_scripts com prioridade maior que a do plugin, confira o template com conditional tags como is_singular() ou is_page() e chame wp_dequeue_script() com o handle do plugin. O Query Monitor lista os scripts enfileirados e os handles de cada um.
Depois, deixe o trabalho que sobrou mais barato:
- Dê o retorno visual primeiro. Atualize o estado do botão ou abra o menu, e faça o trabalho caro numa tarefa seguinte.
- Quebre tarefas longas em tarefas menores e devolva a main thread entre elas. O
scheduler.yield()faz isso onde o navegador suporta, e osetTimeoutserve de fallback. - Aplique debounce nos handlers de input de campos de busca e filtros para não rodarem a cada tecla.
- Leia os valores de layout (tamanhos, posições) antes de escrever estilos, e não alternando leitura e escrita dentro de um loop.
- Evite renderizar de novo uma parte grande da página quando só um pedaço pequeno mudou, problema comum em filtros AJAX e cart fragments.
A Interactivity API ajuda no INP?
A Interactivity API, estável no core desde o WordPress 6.5, é o jeito padrão de adicionar interatividade no front-end aos blocos. Blocos do core como Navigation, Search, a paginação do Query e o lightbox de imagem usam essa API. O markup é renderizado no servidor, o comportamento é declarado com diretivas, e blocos interativos de plugins diferentes compartilham um único runtime em vez de cada um trazer sua própria biblioteca.
Isso ajuda o INP de forma indireta: menos JavaScript para baixar, interpretar e rodar, e nenhum framework separado por plugin. Mas não deixa rápido um handler lento. Se a lógica da sua loja faz um trabalho pesado a cada clique, ela continua bloqueando a main thread. Para blocos interativos customizados novos, prefiro a Interactivity API a um plugin jQuery ou a um bundle React avulso, porque o custo fica visível e compartilhado.
Como os page builders afetam o INP?
Toda interação que muda a página faz o navegador recalcular estilos e layout. Quanto mais elementos na página, mais caro isso fica, e o custo cai no presentation delay. Page builders como Elementor e Divi aninham vários wrappers em volta de cada widget, e landing pages longas feitas com eles podem chegar a um tamanho de DOM que o Lighthouse marca como excessivo.
No Elementor, os layouts com containers geram menos wrappers que a estrutura antiga de seções e colunas. Fora isso, as correções são editoriais: menos widgets por página, nada de seções duplicadas e escondidas para mobile e desktop, e nada de mega menu que renderiza centenas de links em todas as páginas. Os assets do builder também afetam o carregamento, assunto que trato em como melhorar o LCP no WordPress. Conteúdo que se desloca durante as interações é outro problema, explicado em como reduzir o CLS no WordPress.
Como confirmar uma correção de INP?
Grave a mesma interação no DevTools antes e depois, com o mesmo throttling de CPU, e compare as três fases. Depois acompanhe os dados do monitoramento de usuários reais, que mostram a mudança em poucos dias. O CrUX precisa da janela completa de 28 dias, então o PageSpeed Insights e o Search Console vão ficar para trás. Se o INP só melhora no laboratório, provavelmente você mudou o trabalho de lugar em vez de removê-lo.
Quer uma segunda opinião sobre o seu INP?
Problemas de INP muitas vezes estão espalhados entre o tema, alguns plugins e um tag manager, e cada responsável acha que o problema está em outro lugar. Eu rastreio as interações lentas dos dados de campo até os scripts que causam cada uma e entrego uma lista de correções priorizada. Saiba mais sobre como é trabalhar comigo como especialista em Core Web Vitals.