--- title: "INP no WordPress: como corrigir interações lentas" id: "521" type: "post" slug: "inp-no-wordpress" published_at: "2026-10-06T15:19:35+00:00" modified_at: "2026-10-06T20:23:42+00:00" url: "https://danielpazwp.com/pt/inp-no-wordpress/" markdown_url: "https://danielpazwp.com/pt/inp-no-wordpress.md" excerpt: "Por que sites WordPress reprovam no INP, como achar a interação lenta nos dados de campo e como cortar scripts de terceiros, JS de plugins e DOM grande." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 8 min de leitura # INP no WordPress: como corrigir interações lentas Por que sites WordPress reprovam no INP, como achar a interação lenta nos dados de campo e como cortar scripts de terceiros, JS de plugins e DOM grande. Publicado **06/10/2026**8 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) 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](https://danielpazwp.com/pt/core-web-vitals-no-wordpress/) . ## O que o INP mede? Toda interação (clique, toque ou tecla) tem três fases: 1. 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. 2. Processing duration: o tempo que os seus handlers levam para rodar, contando todos os listeners ligados àquele evento. 3. 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](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) . 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 o `setTimeout` serve 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](https://danielpazwp.com/pt/lcp-no-wordpress/) . Conteúdo que se desloca durante as interações é outro problema, explicado em [como reduzir o CLS no WordPress](https://danielpazwp.com/pt/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](https://danielpazwp.com/pt/especialista-core-web-vitals/) . [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) [Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) [Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)