Corrigir o aviso eliminate render-blocking resources do Lighthouse
Livre-se dos recursos que bloqueiam a renderização e melhore os Core Web Vitals
'Eliminate render-blocking resources' em resumo
Quando um navegador encontra CSS ou JavaScript que bloqueia a renderização no <head>, ele para tudo. Nenhum pixel é pintado até que esses recursos terminem de ser baixados e executados. É isso que o aviso 'Eliminate render-blocking resources' no Lighthouse está lhe dizendo: algo no seu <head> está atrasando a primeira pintura.
Corrija este aviso do Lighthouse removendo ou adiando esses recursos que bloqueiam a renderização. De acordo com o Web Almanac 2025, apenas 15% das páginas móveis passam nesta auditoria. Isso significa 85% da web com atrasos de renderização desnecessários.
O que é o aviso 'Eliminate render-blocking resources' do Lighthouse?
Última revisão por Arjen Karel em março de 2026
O que causa o aviso Eliminate render-blocking resources no Lighthouse? O Lighthouse sinaliza páginas que possuem:
- Uma tag script no head que não é adiada.
Scripts no head da página bloqueiam a renderização por padrão se não possuírem o atributo defer ou async. - Uma folha de estilo vinculada que corresponde à mídia do dispositivo.
Um <link rel="stylesheet"> bloqueará a renderização da página se não estiver desativado e corresponder à mídia do navegador. Por exemplo, <link rel="stylesheet" media="print"> não bloqueará a renderização em dispositivos de tela.
Muitos recursos que bloqueiam a renderização provavelmente afetarão o First Contentful Paint (FCP) e o Largest Contentful Paint (LCP) diretamente. A Vodafone reduziu o JavaScript que bloqueia a renderização e obteve uma melhoria de 31% no LCP, o que se traduziu em um aumento de 8% nas vendas.
De acordo com o Web Performance Calendar, 67,7% dos sites carregam pelo menos um recurso de terceiros que bloqueia a renderização. Apenas o Google Fonts é responsável por requisições que bloqueiam a renderização em mais de 5,8 milhões de sites.
O que causa 'render-blocking resources'?
Recursos que bloqueiam a renderização são sempre folhas de estilo e JavaScripts no head da página. Isso significa que eles só podem ser adicionados pelo seu CMS, pelo seu desenvolvedor web ou por um plugin. Ao tentar encontrar a origem de um recurso que bloqueia a renderização, tente procurar nestes lugares:
- O template. O template do seu site é o primeiro lugar a se olhar. Encontre o local onde o código <head> está localizado e procure por estilos e scripts inseridos diretamente no código (hardcoded).
- O CMS. Às vezes, o próprio CMS requer alguns scripts (por exemplo, jQuery) para funcionar corretamente.
- Plugins. Plugins são notórios por injetar estilos e scripts na página. Mesmo quando um plugin é usado em apenas uma página, ele frequentemente carrega seus recursos em todas as páginas.
O capítulo sobre JavaScript do Web Almanac 2024 (a edição mais recente com dados em nível de script) descobriu que, embora 87% das páginas usem async em pelo menos um script, apenas 49% das tags de script individuais realmente o possuem. E apenas 13% dos scripts usam defer. A maioria dos scripts na web ainda é carregada sem nenhum dos atributos, o que significa que eles bloqueiam a renderização.
Como corrigir 'Eliminate render-blocking resources'
Para corrigir os recursos que bloqueiam a renderização, você precisa garantir que eles não bloqueiem mais a renderização. A melhor correção é remover o recurso inteiramente. Scripts e folhas de estilo antigos e não utilizados que ainda estão no <head> são mais comuns do que você imagina. Se você não puder removê-los, adie-os.
Adiando o JavaScript
O JavaScript pode ser adiado adicionando o atributo defer ou async à tag script.
<!-- deferred: baixa em paralelo, executa após a análise do HTML, em ordem --> <script defer src="script.js"></script> <!-- async: baixa em paralelo, executa imediatamente quando pronto (em qualquer ordem) --> <script async src="script.js"></script>
Para a maioria dos scripts, defer é a escolha mais segura porque preserva a ordem de execução. Use async para scripts que são completamente independentes, como analytics. Se você usa módulos ES (<script type="module">), você obtém o comportamento de defer automaticamente. Scripts de módulo nunca bloqueiam a renderização.
Para um guia completo sobre todas as maneiras de controlar o tempo do JavaScript, veja 16 métodos para adiar o JavaScript. Se você quiser entender como async e defer afetam os Core Web Vitals de forma diferente, também temos um artigo dedicado a isso.
Adiando folhas de estilo
Adiar folhas de estilo é mais complicado do que adiar scripts. Quando uma folha de estilo é adiada, a página renderiza sem esses estilos primeiro e, em seguida, o navegador os aplica uma vez carregados. Isso causa cintilação e mudanças de layout. É por isso que você precisa combinar folhas de estilo adiadas com CSS crítico inline.
Passo 1: Coloque seu CSS crítico inline. O CSS crítico é o conjunto mínimo de estilos necessário para renderizar a parte visível da página. Coloque-o inline diretamente em uma tag <style> no <head>. Isso dá ao navegador tudo o que ele precisa para pintar o conteúdo acima da dobra sem esperar por um arquivo externo. Extrair o CSS crítico manualmente é entediante. Você pode usar nosso Gerador de CSS Crítico para automatizar isso.
<style>/* CSS crítico aqui */</style>
Passo 2: Carregue o restante com baixa prioridade. Para a folha de estilo não crítica, adicione fetchpriority="low" para dizer ao navegador que este recurso não deve competir com o conteúdo crítico:
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
Você pode ver artigos mais antigos recomendando um hack de media="print" que muda para media="all" no carregamento. Eu não recomendo isso. Isso abusa do atributo media para algo para o qual ele não foi projetado, depende de um manipulador onload frágil e, se esse manipulador falhar, seus estilos nunca serão aplicados. Usar fetchpriority="low" é a abordagem semântica correta: isso diz ao navegador exatamente o que você quer dizer, sem truques.
Para folhas de estilo que você não precisa de forma alguma na página atual (por exemplo, estilos usados apenas em um tipo de página específico), a solução mais limpa é remover o CSS não utilizado dessa página inteiramente.
Reduza o impacto dos recursos que bloqueiam a renderização
Às vezes você não consegue eliminar os recursos que bloqueiam a renderização. Você pode não ter acesso ao template ou o seu CMS pode exigir certos scripts. Existem algumas maneiras de reduzir o impacto:
- Minifique e comprima seus estilos e scripts.
Recursos menores têm menos impacto no desempenho de carregamento do que recursos maiores. Certifique-se de que a compressão gzip ou brotli esteja ativada no seu servidor. - Evite encadear requisições críticas.
Se uma folha de estilo que bloqueia a renderização carrega outra folha de estilo via@import, você criou uma cadeia de requisições. O segundo arquivo não pode começar a ser baixado até que o primeiro esteja totalmente carregado e analisado. Use tags<link>separadas para que ambas sejam baixadas em paralelo. - Descarregue recursos por página.
Quando um recurso não pode ser removido de uma página, isso não significa que ele seja necessário em todas as páginas. Os plugins do WordPress tendem a adicionar scripts e estilos a todas as páginas, mesmo quando o plugin está ativo em apenas algumas. - Priorize o que importa.
Use a priorização de recursos para garantir que os recursos críticos sejam carregados primeiro e que os recursos não críticos não compitam por largura de banda.
Nos dados de monitoramento do CoreDash, sites que eliminaram todos os recursos que bloqueiam a renderização viram seu FCP melhorar em 420 ms, em média.
I built CoreDash for my own audits.
Under 1KB. EU hosted. No consent banner. Now with MCP support.
Try CoreDash free
