Corrigir o aviso do Lighthouse eliminate render-blocking resources
Livre-se de 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 (render-blocking) 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á te dizendo: algo no seu <head> está atrasando a primeira pintura (first paint).
Corrija este aviso do Lighthouse removendo ou adiando (deferring) esses recursos que bloqueiam a renderização. De acordo com o Web Almanac de 2025, apenas 15% das páginas móveis passam nesta auditoria. Isso é 85% da web com atrasos desnecessários na renderização.
O que é o aviso do Lighthouse 'Eliminate render-blocking resources'?
Ú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 de script no head que não é adiada (deferred).
Os scripts no head da página são render-blocking por padrão se eles não tiverem o atributo defer ou async. - Uma folha de estilos vinculada que corresponde à mídia do dispositivo (device media).
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 com tela.
Muitos recursos que bloqueiam a renderização afetarão mais provavelmente o First Contentful Paint (FCP) e o Largest Contentful Paint (LCP) diretamente. A Vodafone reduziu o JavaScript render-blocking e viu 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 terceiro (third party) que bloqueia a renderização. Apenas o Google Fonts é responsável por solicitações render-blocking em mais de 5,8 milhões de sites.
O que causa 'render-blocking resources'?
Os 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 procurar. Encontre o local onde o código <head> está localizado e procure por estilos e scripts hardcoded.
- O CMS. Às vezes, o próprio CMS requer alguns scripts (por exemplo, jQuery) para funcionar corretamente.
- Plugins. Os 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 de 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 se certificar de que eles não bloqueiem mais a renderização. A melhor correção é remover o recurso completamente. Scripts antigos e não utilizados e folhas de estilo que ainda estão no <head> são mais comuns do que você pensa. Se você não puder removê-los, adie-os (defer).
Adiando o JavaScript
O JavaScript pode ser adiado adicionando o atributo defer ou async à tag do script.
<!-- deferred: baixa em paralelo, executa após o parsing 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, o defer é a escolha mais segura porque preserva a ordem de execução. Use async para scripts que são completamente independentes, como análises (analytics). Se você usa módulos ES (<script type="module">), você obtém o comportamento defer automaticamente. Scripts de módulo nunca bloqueiam a renderização.
Para um guia completo sobre todas as maneiras de controlar o timing 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 é renderizada primeiro sem esses estilos e, em seguida, o navegador os aplica depois de carregados. Isso causa cintilação (flickering) e mudanças de layout (layout shifts). É por isso que você precisa emparelhar 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 de que ele precisa para pintar o conteúdo acima da dobra (above-the-fold) sem esperar por um arquivo externo. Extrair CSS crítico manualmente é tedioso. Você pode usar nosso Gerador de CSS Crítico para automatizar isso.
<style>/* CSS crítico aqui */</style>
Passo 2: Carregue o resto 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 conteúdo crítico:
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
Você pode ver artigos mais antigos recomendando um hack media="print" que muda para media="all" no carregamento (load). Eu não recomendo isso. Ele abusa do atributo media para algo para o qual não foi projetado, depende de um manipulador (handler) onload frágil e, se esse manipulador falhar, seus estilos nunca serão aplicados. Usar fetchpriority="low" é a abordagem semântica e correta: ela diz ao navegador exatamente o que você quer dizer, sem truques.
Para folhas de estilo das quais você não precisa 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 completamente.
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 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 do carregamento do que recursos maiores. Certifique-se de que a compactação gzip ou brotli esteja ativada no seu servidor. - Evite encadear solicitações críticas (chaining critical requests).
Se uma folha de estilo que bloqueia a renderização carregar outra folha de estilo via@import, você criou uma cadeia de solicitações (request chain). O segundo arquivo não pode começar a ser baixado até que o primeiro seja totalmente carregado e analisado (parsed). Use tags<link>separadas para que ambos sejam baixados em paralelo. - Descarregue (Unload) 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 apenas em algumas. - Priorize o que importa.
Use a priorização de recursos (resource prioritization) para garantir que os recursos críticos sejam carregados primeiro e os não críticos não concorram por largura de banda.
Nos dados de monitoramento da CoreDash, sites que eliminaram todos os recursos render-blocking viram seu FCP melhorar em [CD:placeholder]ms em média.
The RUM tool I built for my own clients.
CoreDash is what I use to audit enterprise platforms. Under 1KB tracking script, EU hosted, no consent banner. AI with MCP support built in. The same tool, available to everyone.
Create Free Account
