| Etapa | Objetivo | Check de validação |
|---|---|---|
| Diagnóstico | Medir CSS e JS inutilizado por página real | Relatório do Chrome DevTools Coverage salvo |
| Used CSS | Gerar CSS usado por página no Perfmatters | Layout idêntico em desktop e mobile |
| Atraso de JS | Adiar scripts sem interação imediata | Botões e formulários funcionando ao clicar |
| Exclusões | Proteger checkout e widgets críticos | WooCommerce e popups intactos |
Legenda: a aba Assets do Perfmatters concentra as opções de Used CSS e atraso de JavaScript que reduzem o peso de cada página.
--- ## Por que CSS e JS não usado deixam o WordPress lento CSS e JS não usado deixam o WordPress lento porque cada arquivo enfileirado adiciona uma requisição de rede e um bloco de parsing antes de a tela pintar. Em testes de campo, páginas com mais de 25 arquivos enfileirados tendem a perder de 0,4 a 1 segundo de First Contentful Paint. O navegador baixa tudo sem saber o que será usado. Esse desperdício aparece com frequência em sites construídos no Elementor PRO com vários addons ativos. Cada widget registra seu próprio estilo, e o tema soma a folha global. A limpeza inteligente do código fonte resolve parte disso, mas a remoção de arquivos inteiros, conhecida como tree-shaking de CSS, é o que realmente reduz o payload. A minificação de CSS e JavaScript comprime o que sobra, enquanto a remoção elimina o que nunca seria executado. --- ## Como funciona o used CSS no Perfmatters O Used CSS do Perfmatters funciona analisando o HTML renderizado de cada página e mantendo apenas as regras de estilo que aparecem naquela URL, removendo o restante das folhas enfileiradas. A geração roda em segundo plano e armazena o CSS limpo por página. Na prática, vemos no suporte da FULL que a maioria dos sites Elementor reduz o CSS bloqueante com o modo por página ativo. A configuração vive em Perfmatters > Assets > CSS, com a opção Used CSS e o modo de geração por página. O detalhe técnico que evita dor de cabeça é o campo de exclusão: handles ou seletores que o plugin não deve mexer. Para entender o comportamento exato de cada opção, consulte o passo a passo oficial do Perfmatters, que descreve o fluxo de geração. O Perfmatters como plugin de otimização integra esse recurso ao mesmo painel de scripts e fontes. --- ## Passo a passo: Remover CSS e JS não usado no WordPress com o Perfmatters Remover CSS e JS não usado no WordPress com o Perfmatters leva cinco passos e cerca de 20 minutos por site, contando os testes de validação. O processo exige medir antes, ativar por página e excluir o que é crítico, porque uma ativação cega tende a quebrar layouts internos em até um terço das páginas complexas. Os passos a seguir seguem essa ordem segura. ### Passo 1: Meça o CSS e JS não usado com o coverage Abra o Chrome DevTools, vá em Coverage e recarregue a página: a aba mostra, em vermelho, a porcentagem de cada arquivo que não foi executado. Anote as três URLs mais pesadas do site, como home, página de blog e checkout, porque elas concentram a maior parte do desperdício. Esse diagnóstico é a base para validar o ganho depois do corte. ### Passo 2: Ative o used CSS por página no Perfmatters Em Perfmatters > Assets > CSS, ative o Used CSS e selecione a geração por página, não global. O modo por página gera um CSS limpo para cada URL e evita o erro clássico de servir o estilo da home para o checkout. Aguarde a fila de geração concluir antes de testar, já que o processo roda de forma assíncrona em segundo plano. ### Passo 3: Adie o JavaScript sem interação imediata Na aba JS, use o atraso de JavaScript para scripts que não precisam rodar no primeiro paint, como chat, mapas e pixels de anúncio. O atraso dispara esses scripts no primeiro toque ou rolagem do usuário, o que libera a thread principal durante o carregamento. A técnica complementa a remoção de CSS e melhora o tempo de interatividade. ### Passo 4: Exclua checkout, popups e widgets críticos Adicione handles e seletores de checkout do WooCommerce, popups e formulários na lista de exclusão. Remover CSS de um formulário de pagamento sem testar derruba a estilização e a conversão junto, então essa proteção não é opcional. Liste também os widgets de menu mobile, que costumam depender de classes injetadas por JavaScript. ### Passo 5: Valide layout e Core Web Vitals Abra cada URL crítica em desktop e mobile, com cache limpo, e compare com o relatório do Coverage do Passo 1. Rode o PageSpeed Insights para confirmar a queda no CSS bloqueante e a melhora do Core Web Vitals do WordPress. Se algum estilo sumiu, volte e ajuste as exclusões antes de publicar. --- ## Used CSS automático versus remoção manual de handles Remover CSS e JS não usado no WordPress de forma automática ou manual depende do controle que você precisa: o Used CSS automático cobre a maioria dos casos em minutos, enquanto a remoção manual via `wp_dequeue_style` serve para situações cirúrgicas. A limpeza manual exige código no tema filho e teste página a página, o que custa tempo. Para a maioria dos sites, o automático do Perfmatters resolve sem tocar em PHP. A remoção manual ainda vale quando um único plugin injeta um script pesado em todo o site sem necessidade, como uma biblioteca de slider em páginas sem carrossel. Nesse caso, o desenvolvedor usa `wp_dequeue_script` em um hook condicional. A diferença prática entre minificação e remoção é que a primeira encolhe o arquivo e a segunda o elimina quando ele não serve àquela página. --- ## O que a remoção de CSS e JS não resolve Remover CSS e JS não usado no WordPress não resolve um problema de hospedagem lenta, porque a técnica ataca o front-end, não o tempo de resposta do servidor. Se o TTFB está em 800 ms, cortar 100 KB de CSS economiza talvez 200 ms, mas o gargalo segue no back-end. A limpeza de assets trabalha junto com o cache de página, nunca no lugar dele. O caso clássico aparece em hospedagem compartilhada barata: o site melhora a nota de CSS no PageSpeed, mas continua demorando para carregar a primeira tela. Aqui entra a infraestrutura. A FULL conecta mais de 150 mil sites WordPress e, na prática, vemos que boa parte dos chamados de lentidão começa no servidor, não nos arquivos. Reduzir o TTFB exige cache de objeto e PHP recente, assunto que o guia de TTFB no WordPress detalha. --- ## Acelere com o bundle de plugins da FULL Montar essa stack avulsa custa caro: o Perfmatters sozinho sai por cerca de US$25 por ano por site. No plano PRO da FULL, por R$849, você ativa o bundle completo com Perfmatters, Rank Math PRO e mais de 15 plugins premium em vários sites, o que derruba o custo para cerca de R$85 por site. Veja o que cada plano inclui em FULL.services/planos e ative tudo em um clique, sem comprar licença a licença. Para agências com dezenas de instalações, esse rateio do bundle costuma pagar o plano só com a economia do Perfmatters e do Rank Math PRO somados, e ainda libera os outros plugins premium. --- ## Como o CSS crítico fecha a otimização de renderização Remover CSS e JS não usado no WordPress entrega o maior ganho quando vem acompanhado do CSS crítico: o navegador recebe inline apenas o estilo da primeira dobra e adia o resto, o que elimina o pedido bloqueante antes do primeiro paint. O Perfmatters gera esse CSS crítico no mesmo painel de Used CSS, então as duas técnicas operam juntas sem configuração extra. Quem combina a remoção do estilo inutilizado com o CSS crítico entrega um HTML mais enxuto e um caminho de renderização mais curto, e o LCP cai nas duas frentes ao mesmo tempo. Na prática, vemos no suporte da FULL que muitos sites Elementor param no meio do caminho: ativam o Used CSS, mas deixam a folha global ainda bloqueando a renderização no ``. O que fecha o ciclo não é só cortar o que não serve, e sim ordenar o que sobra, com o CSS da primeira dobra inline e o restante carregado de forma assíncrona. O Perfmatters, incluído no bundle, controla essa ordem de carregamento. CSS crítico não é atalho mágico: a base segue sendo medir cada URL antes e depois do corte. --- ## Próximos passos para remover CSS e JS não usado no WordPress Remover CSS e JS não usado no WordPress é uma das alavancas mais baratas de performance, mas só rende quando vem depois de cache e hospedagem decente. Comece medindo com o Coverage, ative o Used CSS por página e proteja checkout e popups antes de publicar. O ganho de LCP entre 0,3 e 1,2 segundo é real, e some-se a ele o caminho de renderização mais curto quando você ainda inline o CSS crítico da primeira dobra. Para aprofundar cada etapa, o guia de eliminação de JavaScript bloqueante mostra o lado dos scripts, e o tutorial de remoção de bloqueio de renderização fecha o ciclo. Para continuar aprendendo, o FULL Academy reúne tutoriais, guias e reviews de performance em um só lugar.Remover esses arquivos melhora o LCP porque o navegador deixa de baixar e processar estilos e scripts que aquela página nunca aplica, liberando a thread principal para pintar a tela antes. Em sites Elementor, o PageSpeed Insights costuma apontar de 80 KB a 200 KB de CSS inutilizado por página. Cortar esse peso reduz o bloqueio de renderização e adianta o maior elemento visível.
Sim, é possível remover CSS e JS não usado no WordPress sem quebrar o layout, desde que a geração seja feita por página e os elementos críticos entrem na lista de exclusão. O risco aparece quando o plugin serve o CSS de uma URL para todas ou remove estilos de menus mobile injetados por JavaScript. A forma segura é ativar o Used CSS no modo por página do Perfmatters, excluir checkout e popups, e validar cada URL em desktop e mobile com cache limpo.
A diferença é o alvo de cada técnica. A minificação encolhe o arquivo removendo espaços e comentários, mantendo todas as regras, enquanto remover CSS e JS não usado no WordPress elimina folhas inteiras. A remoção elimina folhas e scripts inteiros que aquela página não usa, o que reduz requisições de rede além do tamanho. As duas se somam: primeiro você remove o que não serve, depois minifica o que sobra para entregar o menor payload possível ao navegador.
O ganho típico de remover CSS e JS não usado no WordPress fica entre 0,3 e 1,2 segundo de LCP, dependendo de quanto CSS inutilizado o site carrega e da qualidade da hospedagem. Sites com muitos addons de Elementor tendem ao topo dessa faixa porque acumulam folhas redundantes. Vale lembrar que o ganho é de front-end: se o TTFB do servidor estiver acima de 600 ms, a limpeza ajuda pouco e o foco deve ir para cache e infraestrutura.
O Perfmatters analisa o HTML renderizado de cada página e mantém só as regras de CSS que aquela URL usa, removendo o restante das folhas enfileiradas. Ele também adia o JavaScript sem interação imediata, como chat e mapas, disparando os scripts no primeiro toque do usuário. As opções vivem em Assets, com geração de Used CSS por página e campos de exclusão por handle ou seletor para proteger áreas críticas.