Render-blocking resources no WordPress: como eliminar

Tipo Performance & Velocidade

Nome do erro Render-blocking resources EN: Render-blocking resources

Severidade Grave

Descrição Render-blocking resources no WordPress são arquivos de CSS e JavaScript carregados no início da página que o navegador precisa baixar e processar antes de pintar qualquer conteúdo. Costumam vir de folhas de estilo e scripts enfileirados no head por tema e plugins, que atrasam a primeira pintura e elevam o LCP.

O que é os render-blocking resources no WordPress?

Os render-blocking resources no WordPress são os arquivos que o navegador é obrigado a buscar e interpretar antes de mostrar a página. Por padrão, toda folha de estilo no início do documento e todo script sem adiamento bloqueiam a renderização: o navegador para, baixa o arquivo, processa e só então pinta. Quando tema e plugins enfileiram muitos desses arquivos no topo, a tela fica em branco por mais tempo, o que piora o First Contentful Paint e o LCP. A correção é separar o CSS crítico do resto, adiar o JavaScript não essencial e reduzir o número e o tamanho dos arquivos que carregam antes do primeiro render.

Como identificar

O diagnóstico “Eliminar recursos que impedem a renderização” aparece como oportunidade no PageSpeed Insights, com a economia estimada em milissegundos.
O Lighthouse lista arquivos .css e .js específicos como bloqueadores no relatório de performance.
A página exibe uma tela em branco por um instante perceptível antes de qualquer conteúdo aparecer.
O waterfall da aba Network mostra vários CSS e JS sendo baixados no head antes da primeira pintura.

Como prevenir

Mantenha o adiamento de JavaScript e a geração de CSS crítico ativos no plugin de performance
Evite plugins que enfileiram CSS e JS em todas as páginas e limite cada recurso à página que o usa
Sempre que adicionar fontes ou bibliotecas, carregue-as sem bloquear o render (preload, async, font-display)

Causa

Folhas de estilo de tema e plugins enfileiradas no head, que bloqueiam o render até serem totalmente baixadas.
Arquivos JavaScript sem o atributo defer ou async carregados no topo do documento.
Fontes de ícones e bibliotecas de CSS completas (como frameworks inteiros) carregadas mesmo quando só uma fração é usada.
Plugins que injetam seu próprio CSS e JS em todas as páginas, inclusive onde o recurso não é necessário.
CSS crítico não separado, obrigando o navegador a baixar toda a folha de estilos antes de pintar o topo da página.

Como resolver

Liste os recursos bloqueadores: rode o PageSpeed Insights e abra "Eliminar recursos que impedem a renderização" para ver exatamente quais arquivos de CSS e JavaScript travam o primeiro render.
Adie o JavaScript não crítico: no plugin de performance, aplique o adiamento (defer) aos scripts que não são necessários para o conteúdo acima da dobra, para eles não bloquearem a pintura.
Gere e injete o CSS crítico: extraia o CSS necessário para o topo da página, coloque-o de forma embutida no início do documento e carregue o restante da folha de estilos de forma assíncrona.
Minifique e reduza CSS e JS: minifique os arquivos e remova CSS e scripts não usados por página, diminuindo o número e o peso dos recursos que carregam antes do render.
Carregue fontes sem bloquear: faça preload da fonte principal e use font-display: swap para o texto aparecer com uma fonte de fallback enquanto a definitiva carrega.
Meça de novo no PageSpeed: rode o teste outra vez e confirme que a oportunidade de render-blocking diminuiu e que o FCP e o LCP melhoraram.

HTML

<!-- 1) CSS critico embutido: pinta o topo sem esperar download externo -->
<style>
  /* so o essencial do above-the-fold (header, hero, tipografia base) */
  header{display:flex;align-items:center}
  .hero{min-height:60vh}
  body{margin:0;font-family:system-ui,sans-serif}
</style>

<!-- 2) Folha completa carregada de forma assincrona (nao bloqueia o render) -->
<link rel="preload" as="style"
      href="/wp-content/themes/tema/style.css"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/wp-content/themes/tema/style.css"></noscript>

<!-- 3) JS nao critico adiado: executa so apos a analise do HTML -->
<script src="/wp-content/themes/tema/main.js" defer></script>

Perguntas frequentes

O que são render-blocking resources no WordPress?

São os arquivos de CSS e JavaScript que o navegador precisa baixar e processar antes de pintar a página. Folhas de estilo no head e scripts sem defer bloqueiam a primeira pintura, deixando a tela em branco por mais tempo e piorando o FCP e o LCP.

Como eliminar recursos que bloqueiam a renderização?

Adie o JavaScript não crítico com defer, separe e embuta o CSS crítico do topo, carregue o restante da folha de estilos de forma assíncrona e minifique tudo. Plugins de performance fazem boa parte disso, mas exigem teste para não quebrar o layout.

O que é CSS crítico e por que ele ajuda?

CSS crítico é o conjunto mínimo de estilos necessários para renderizar o conteúdo acima da dobra. Embutido no início do documento, ele permite pintar o topo da página de imediato, enquanto o resto da folha de estilos carrega de forma assíncrona, sem bloquear o render.

Qual a diferença entre defer e async no JavaScript?

Tanto defer quanto async baixam o script sem bloquear a análise do HTML. O defer executa em ordem, só após o HTML ser analisado, ideal para a maioria dos scripts. O async executa assim que baixa, em ordem imprevisível, adequado a scripts independentes como analytics.

Adiar CSS e JavaScript pode quebrar o site?

Pode. Se um script depender de outro ainda não executado ou se o CSS crítico estiver incompleto, o layout pode aparecer quebrado por um instante (FOUC). Por isso, teste o site após cada otimização e exclua do adiamento os recursos que apresentarem problema.

Plugins de cache resolvem o render-blocking sozinhos?

Ajudam bastante, porque trazem recursos de adiar JS, gerar CSS crítico e minificar. Mas não são automáticos: é preciso ativar e calibrar cada opção e testar o resultado, já que configurações agressivas podem combinar mal scripts essenciais.

Crítico

Como recuperar o site após a otimização de banco do WP Rocket

Database Optimization do WP Rocket é a limpeza de banco que apaga revisões, rascunhos, comentários de spam e transientes de forma permanente. A própria documentação avisa que, depois de executada, não há como desfazer, então conteúdo apagado por engano ou tabelas que quebraram só voltam com a restauração de um backup.

Atenção

Como corrigir a compressão de imagem com qualidade ruim no WP-Optimize no WordPress

A compressão de imagem ruim no WP-Optimize acontece quando o modo lossy com prioridade em economia máxima de espaço, a recompressão de imagens já otimizadas ou um redimensionamento agressivo reduzem a qualidade das fotos. A solução é restaurar o original e recomprimir escolhendo lossless ou um nível lossy de maior qualidade.

Atenção

Como corrigir o erro de imagens WebP que não carregam no WP Rocket com Imagify

As imagens WebP não carregam no WP Rocket com Imagify quando a opção WebP Compatibility do WP Rocket é ativada junto com o método de tag picture do Imagify, gerando cache duplicado e referências quebradas; o WP Rocket só deve cuidar do WebP quando o Imagify não serve a imagem sozinho.

Grave

Como corrigir scripts do Tutor LMS removidos pelo Perfmatters no WordPress

O Perfmatters remove scripts do Tutor LMS quando o Script Manager desativa o JavaScript do plugin nas páginas de curso, ou quando o Delay JavaScript adia o carregamento dos scripts da sala de aula até uma interacao, deixando player de vídeo, quiz e progresso sem funcionar.

Grave

Como corrigir o conflito de nonce expirado entre WP Rocket e reCAPTCHA

O nonce do reCAPTCHA expira com o WP Rocket quando a página do formulário é entregue do cache com um token de segurança gerado horas antes. O visitante envia esse nonce já vencido, o reCAPTCHA ou o formulário rejeita a verificação e a submissão falha, mesmo o usuário sendo humano.

Informativo

Como corrigir o cache do WP Rocket que serve Custom Fields dinâmicos do ACF PRO desatualizados no WordPress

O cache ACF WP Rocket entrega valores antigos quando o WP Rocket guarda o HTML já renderizado da página e não regenera esse arquivo ao salvar um Custom Field dinâmico do ACF PRO; o visitante continua vendo o valor anterior até o cache expirar ou ser purgado.

Setores

Extensões

Integrações

Como corrigir render-blocking resources no WordPress

O que é os render-blocking resources no WordPress?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como recuperar o site após a otimização de banco do WP Rocket

Como corrigir a compressão de imagem com qualidade ruim no WP-Optimize no WordPress

Como corrigir o erro de imagens WebP que não carregam no WP Rocket com Imagify

Como corrigir scripts do Tutor LMS removidos pelo Perfmatters no WordPress

Como corrigir o conflito de nonce expirado entre WP Rocket e reCAPTCHA

Como corrigir o cache do WP Rocket que serve Custom Fields dinâmicos do ACF PRO desatualizados no WordPress

Setores

Extensões

Integrações

Extensões

Hero Sections

Seções de CTA

Login

Blog

Cabeçalhos

Seções de FAQ

Cadastro

Blog individual

Rodapés

Seções de contato

Seções de preços

Faixas

Portfólio

Seções de equipe

Números

Logotipos