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 baixar e executar. É isso que o aviso 'Eliminate render-blocking resources' no Lighthouse está 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 de 2025, apenas 15% das páginas mobile passam nessa auditoria. Isso significa que 85% da web tem 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 têm:
- 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 tiverem 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 for 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 observou 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 uma third party que bloqueia a renderização. O Google Fonts sozinho é responsável por solicitações de bloqueio de renderização em mais de 5,8 milhões de sites.
O que causa os '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 procurar. Encontre o local onde o código <head> está localizado e procure por estilos e scripts fixos no código (hardcoded).
- O CMS. Às vezes o próprio CMS exige 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 geralmente carrega seus recursos em todas as páginas.
O capítulo sobre JavaScript do Web Almanac de 2024 (a edição mais recente com dados ao nível do 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 desses atributos, o que significa que eles bloqueiam a renderização.
Como corrigir 'Eliminate render-blocking resources'
Para corrigir 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 totalmente. 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 o parseamento do HTML, em ordem --> <script defer src="script.js"></script> <!-- async: baixa em paralelo, executa imediatamente quando pronto (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ê usar 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, consulte 16 métodos para adiar o JavaScript. Se você quiser entender como async e defer afetam os Core Web Vitals de forma diferente, nós 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 então o navegador os aplica assim que são carregados. Isso causa cintilação e layout shifts. É por isso que você precisa combinar folhas de estilo adiadas com critical CSS inline.
Passo 1: Coloque seu critical CSS inline. Critical CSS é 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 (above-the-fold) sem esperar por um arquivo externo. Extrair o critical CSS manualmente é tedioso. Você pode usar nosso Gerador de Critical CSS para automatizar isso.
<style>/* critical CSS aqui */</style>
Passo 2: Carregue o restante com baixa prioridade. Para a folha de estilo não crítica, adicione fetchpriority="low" para informar ao navegador que esse 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. Ele abusa do atributo media para algo para o qual 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 correta e semântica: 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 pode eliminar os recursos que bloqueiam a renderização. Você pode não ter acesso ao template ou 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 solicitaçõ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 solicitações. O segundo arquivo não pode começar a ser baixado até que o primeiro esteja totalmente carregado e parseado. Use tags<link>separadas para que ambos sejam baixados em paralelo. - Descarregue os recursos por página.
Quando um recurso não pode ser removido de uma página, isso não significa que ele seja obrigató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 apenas em algumas. - Priorize o que importa.
Use a priorização de recursos para garantir que recursos críticos sejam carregados primeiro e recursos não críticos não concorram por largura de banda.
Nos dados de monitoramento do CoreDash, os sites que eliminaram todos os recursos que bloqueiam a renderização viram seu FCP melhorar em 420ms, em média.
A performance cai no momento que você para de olhar.
Monto o monitoramento, os budgets e o processo. É isso que separa um fix de uma solução.
Vamos conversar
