# Como corrigir render-blocking resources no WordPress

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)

Erros relacionados

- [Como corrigir LCP alto no WordPress (Core Web Vitals)](https://full.services/wp-fixer/corrigir-lcp-alto-wordpress/)
- [Como corrigir TBT alto e JavaScript bloqueante](https://full.services/wp-fixer/corrigir-tbt-alto-wordpress/)
- [Como corrigir INP alto (Interaction to Next Paint) no WordPress](https://full.services/wp-fixer/corrigir-inp-alto-wordpress/)

## 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

## Código

```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.

**Fonte:** [web.dev — Render blocking resources](https://web.dev/articles/render-blocking-resources)