| Tipo de recurso | Como ele bloqueia | Ação corretiva |
|---|---|---|
| CSS no head | Trava a primeira pintura até baixar a folha inteira. | Gerar CSS crítico inline e adiar o resto. |
| JS síncrono | Para o parser do HTML até executar o script. | Aplicar defer ou delay em scripts de terceiros. |
| Fontes via @import | Encadeia requisições e atrasa o texto visível. | Pré-carregar a fonte e usar font-display swap. |
Legenda: a seção "Elimine recursos que impedem a renderização" lista cada arquivo com a economia estimada em ms.
### Passo 1: Diagnostique os recursos no PageSpeed insights Rode a URL no PageSpeed Insights e abra a auditoria "Elimine recursos que impedem a renderização". Ela lista cada CSS e JS de bloqueio com o tamanho de transferência e a economia potencial em milissegundos. Anote os 3 arquivos com maior economia, porque são eles que justificam o trabalho. Em paralelo, abra a aba Coverage do Chrome DevTools para ver o percentual de cada arquivo realmente usado acima da dobra. Esse cruzamento separa o CSS do tema, que vale virar crítico, dos scripts de terceiros, que valem adiar. ### Passo 2: Gere o CSS crítico e adie o restante O CSS crítico é o subconjunto de estilos da dobra inserido inline no ``, enquanto a folha completa carrega de forma assíncrona. No WP Rocket 3.x, ative "Optimize CSS delivery" no modo "Remove Unused CSS" ou "Load CSS Asynchronously" na aba Arquivos. O plugin gera o CSS crítico por template e adia o resto. Valide o resultado em duas ou três páginas diferentes: home, post e página de contato. O passo a passo dedicado está em como remover CSS crítico bloqueante com WP Rocket, que detalha as exclusões por template. ### Passo 3: Aplique defer no JavaScript do tema O atributo `defer` faz o navegador baixar o script em paralelo e executá-lo só depois de montar o HTML, sem travar o parser. Ative "Load JavaScript deferred" na aba Arquivos do WP Rocket, ou use o Perfmatters, que permite escolher entre `defer` e `delay` por script. O `defer` é seguro para a maioria dos scripts do tema porque preserva a ordem de execução. Para scripts que dependem de jQuery carregado antes, mantenha-os fora da lista de defer para evitar erro de "$ is not defined" no console. ### Passo 4: Atrase scripts de terceiros com delay O delay (Delay JavaScript Execution) adia o script até a primeira interação do usuário: rolagem, clique ou toque. Diferente do defer, que executa ao montar o HTML, o delay espera o usuário agir. Use-o para Google Analytics, Meta Pixel, chat e mapas embutidos. No WP Rocket, ative "Delay JavaScript execution" e revise a lista de exclusões. Aqui mora a maior fonte de quebra: aplicar o delay global em sites Elementor PRO trava o menu mobile e popups. A correção é mover só os scripts de terceiros para o delay e manter os handles do tema fora. ### Passo 5: Valide o LCP e cheque o Console Depois de remover js e CSS de bloqueio, rode de novo o PageSpeed Insights e confirme que a auditoria de recursos de bloqueio sumiu ou caiu para 1 ou 2 arquivos. Abra o console do navegador em modo anônimo e clique pelos elementos interativos: menu, formulário, botões. Zero erro vermelho significa que o defer e o delay não quebraram nada. Compare o LCP antes e depois no relatório de laboratório do Lighthouse e, em 28 dias, no relatório de campo do Chrome User Experience. Se o LCP não cair, o gargalo provavelmente é o servidor, não o caminho crítico. ## Onde remover js e CSS de bloqueio não resolve nada Remover js e CSS de bloqueio não resolve nada quando o gargalo está no servidor, não no navegador. Se o TTFB passa de 600 ms, o site já gasta meio segundo antes de enviar o primeiro byte, e nenhum CSS crítico recupera esse tempo. Nesses casos, otimizar o caminho crítico é polir o que vem depois do problema real. A causa costuma ser hospedagem compartilhada lenta, ausência de cache de página ou PHP 8.2 sem OPcache. Antes de gastar tempo no front-end, meça o TTFB e resolva a origem: o guia de como reduzir o TTFB no WordPress mostra a ordem certa. Um plugin de cache de página bem configurado corta o TTFB pela metade na maioria dos sites que chegam ao suporte da FULL. Só depois disso o trabalho de remover js e CSS de bloqueio entrega ganho visível no LCP. A minificação de arquivos ajuda, mas é secundária diante de um servidor lento. ## Defer ou delay: Qual usar em cada cenário Defer e delay resolvem problemas diferentes ao remover js e CSS de bloqueio. O defer executa o script assim que o HTML termina de montar, preservando a ordem; serve para scripts do tema e do WordPress. O delay espera a primeira interação do usuário e serve para terceiros que ninguém precisa antes do clique. Usar o tipo errado quebra funcionalidade ou desperdiça o ganho. Em números: o defer costuma economizar 100 a 250 ms ao tirar o parser-blocking, enquanto o delay pode economizar 1 a 2 s de "Total Blocking Time" ao segurar 4 ou 5 scripts de terceiros até a rolagem. Em sites com Elementor PRO, o WP Rocket e o Perfmatters permitem listar handles específicos, o que evita o delay global que trava menu e popup. A documentação de configuração do Perfmatters detalha como adiar script por script, e a configuração recomendada do WP Rocket traz as exclusões padrão por construtor de página. ## Quanto custa automatizar isso na FULL Configurar e manter esse fluxo em vários sites manualmente consome horas a cada atualização de tema ou plugin. No bundle da FULL, o plano PRO sai por R$849 e inclui o WP Rocket e o Perfmatters já licenciados e prontos para ativar em 1 clique. Distribuído pelos 10 sites do plano, isso dá R$85 por site, com as duas ferramentas que automatizam remover js e CSS de bloqueio sem licença avulsa. A gente vê no suporte que a maior parte do retrabalho some quando o cliente ativa os dois pelo painel em vez de comprar e configurar cada plugin separado. Conheça os planos da FULL para comparar o custo por site. --- ## Próximos passos para deixar a renderização leve Remover js e CSS de bloqueio é uma etapa de um trabalho maior de performance que começa no servidor e termina no caminho crítico. A sequência que funciona é clara: meça o TTFB primeiro, ative cache de página, gere CSS crítico, aplique defer no tema, atrase os terceiros com delay e valide o LCP no campo após 28 dias. Pular a ordem é o erro mais comum que a gente vê no suporte: gente otimizando o front-end com o servidor ainda travado. Para continuar aprendendo, o FULL Academy reúne tutoriais, guias e reviews de performance em um só lugar. Com o caminho crítico enxuto e o servidor rápido, o LCP entra na faixa verde dos Core Web Vitals e o site para de perder visitantes na primeira pintura.Porque o ganho depende de onde está o gargalo. Em um site com TTFB de 200 ms, tirar recursos de bloqueio derruba o LCP de forma visível. Em um site com TTFB de 800 ms por hospedagem lenta, o navegador já perdeu o tempo antes de pintar, e o CSS crítico quase não muda o resultado. Por isso a ordem é medir o servidor primeiro e só depois mexer no caminho crítico.
Sim, desde que você não aplique o Delay JavaScript global. O delay agressivo em sites Elementor PRO trava o menu mobile e os popups, porque os handles do tema dependem de scripts que precisam rodar antes da interação. A correção é mover só os scripts de terceiros (analytics, pixel, chat) para o delay e manter os handles do Elementor fora da lista. O WP Rocket e o Perfmatters permitem essa exclusão por handle.
Adiar (defer) baixa o script em paralelo e o executa assim que o HTML termina de montar, preservando a ordem; serve para scripts do tema. Atrasar (delay) espera a primeira interação do usuário, como rolagem ou clique, e serve para terceiros que ninguém precisa antes. O defer costuma economizar 100 a 250 ms, enquanto o delay pode cortar 1 a 2 s de Total Blocking Time ao segurar vários scripts externos.
O plano PRO da FULL sai por R$849 e inclui o WP Rocket e o Perfmatters já licenciados, o que dá R$85 por site nos 10 sites do plano. As duas ferramentas automatizam a geração de CSS crítico, o defer e o delay sem precisar comprar cada licença avulsa, que custaria mais caro por site isolado. A ativação acontece em 1 clique pelo painel, sem instalar e configurar plugin por plugin.
O CSS crítico ataca diretamente o LCP e o First Contentful Paint ao colocar inline só os estilos da dobra e adiar a folha completa. Sem ele, o navegador segura a primeira pintura até baixar todo o CSS, mesmo a parte que só aparece ao rolar. Com o CSS crítico bem gerado, a dobra pinta antes, o que reduz o LCP em centenas de milissegundos em sites com folhas grandes de tema e construtor de página.