JavaScript Defer vs Async e como isso afeta os Core Web Vitals
Aprenda quando aplicar async ao JavaScript e quando aplicar defer para obter os melhores resultados dos Core Web Vitals
JavaScript Defer vs Async e como isso afeta os Core Web Vitals
Sempre que audito os Core Web Vitals de um cliente, frequentemente descubro que há pouca distinção em uma página entre JavaScript que bloqueia o parser (sync), assíncrono ou com defer (deferred). Isso é uma pena porque scripts diferentes têm tempos ótimos diferentes.
Última revisão por Arjen Karel em março de 2026
Table of Contents!
- JavaScript Defer vs Async e como isso afeta os Core Web Vitals
- Em resumo
- 1. JavaScript Síncrono (sync)
- 2. JavaScript Assíncrono (async)
- 3. JavaScript Deferred (defer)
- 4. Module scripts
- Tabela de comparação
- Perguntas comuns
- Como async e defer afetam os Core Web Vitals
- Dando um passo além: carregue scripts sob demanda
De acordo com o Web Almanac 2025, apenas 15% das páginas móveis passam na auditoria de recursos de bloqueio de renderização (render-blocking resources). A página mediana carrega 22 scripts totalizando mais de 630 KB, com 251 KB desse JavaScript ficando completamente sem uso. A maioria dos sites está carregando muito JavaScript, e carregando na hora errada.
Em resumo
JavaScript 'Normal' no head da página bloqueia o navegador de fazer o parsing do HTML até que ele seja baixado e executado. Scripts Async baixam em segundo plano, mas são executados assim que estão prontos, o que ainda pode interromper o parsing. Scripts Deferred baixam em segundo plano e esperam até que o parsing esteja completo antes de executar, na ordem do documento.
Use defer para qualquer coisa que toque no DOM. Use async para scripts que são completamente independentes (analytics, pixels de rastreamento). Não use nenhum dos dois (sync) apenas se o script deve ser executado antes da página renderizar. Em caso de dúvida, use defer.
1. JavaScript Síncrono (sync)
Por padrão, scripts no head da página são síncronos. Quando o navegador encontra um script síncrono ele para o parsing do HTML, baixa o script e o executa antes de continuar. Isso significa que nenhum pixel é pintado (painted) até que todos os scripts sync terminem. Para scripts grandes ou lentos, isso cria um atraso visível no First Contentful Paint.
<!DOCTYPE html> <html> <head> <title>Exemplo de JavaScript Sync</title> <script src="script1.js"></script> <script src="script2.js"></script> </head> <body> <!-- Conteúdo da página aqui --> </body> </html>
O navegador deve baixar e executar script1.js antes mesmo de começar o script2.js. Enquanto isso, nada renderiza. A página móvel mediana já tem um Total Blocking Time de quase 2 segundos em 2025. Scripts síncronos no head pioram isso.
2. JavaScript Assíncrono (async)
Adicionar o atributo async diz ao navegador para baixar o script em segundo plano enquanto ele continua o parsing do HTML. O script é executado assim que termina de baixar, seja onde for que o parser (analisador) estiver naquele momento. O parsing pausa apenas durante a execução.
<!DOCTYPE html> <html> <head> <title>Exemplo de JavaScript Async</title> <script src="script1.js" async></script> <script src="script2.js" async></script> </head> <body> <!-- Conteúdo da página aqui --> </body> </html>
Scripts Async não garantem a ordem de execução. Qualquer script que termine de baixar primeiro é executado primeiro. Se o script2.js depende do script1.js, async vai quebrar as coisas de forma imprevisível. Use async apenas para scripts que são completamente independentes uns dos outros e do DOM.
Uma coisa a se estar ciente: no Chrome, scripts async recebem prioridade de rede baixa (Low network priority) por padrão. Isso significa que o navegador pode começar a baixá-los mais tarde do que você espera. Se você precisa que um script async carregue rapidamente (sem bloquear o parsing), adicione fetchpriority="high".
3. JavaScript Deferred (defer)
O atributo defer também baixa o script em segundo plano, mas a execução é adiada até que o documento HTML seja totalmente analisado (parsed). Scripts deferred executam na ordem do documento, logo antes do evento DOMContentLoaded disparar.
<!DOCTYPE html> <html> <head> <title>Exemplo de JavaScript Defer</title> <script src="script1.js" defer></script> <script src="script2.js" defer></script> </head> <body> <!-- Conteúdo da página aqui --> </body> </html>
Defer é a escolha mais segura para a maioria dos scripts. O DOM está totalmente disponível quando o script executa, a ordem de execução é preservada e a primeira pintura (first paint) não é bloqueada. O The Telegraph aplicou defer em todos os seus scripts e melhorou o tempo de carregamento de anúncios em 4 segundos.
4. Module scripts
Se você usa ES modules (<script type="module">), você obtém o comportamento de defer automaticamente. Module scripts baixam em segundo plano, executam após o parsing e mantêm a ordem. Adicionar defer explicitamente não tem efeito porque já é o padrão.
Você pode adicionar async a um module script se quiser que ele seja executado assim que seu gráfico de dependências for resolvido, em vez de esperar a conclusão do parsing.
Tabela de comparação
| Atributo | Downloads | Executa | Bloqueia o parsing? | Ordem preservada? |
|---|---|---|---|---|
nenhum (sync) |
Bloqueia o parsing durante o download | Imediatamente após o download | Sim (download + execução) | Sim |
async |
Em segundo plano | Assim que o download for concluído | Apenas durante a execução | Não |
defer |
Em segundo plano | Após o parsing do HTML, antes de DOMContentLoaded | Não | Sim |
type="module" |
Em segundo plano | Após o parsing do HTML (mesmo que defer) | Não | Sim |
Perguntas comuns
E se eu usar async e defer na mesma tag? O async ganha. O atributo defer é totalmente ignorado. Esse padrão costumava existir como um fallback para o IE9, mas em 2026 não há motivo para usar ambos.
Async e defer funcionam em scripts inline? Não. Ambos os atributos são ignorados em scripts inline clássicos (sem src). Eles só funcionam em scripts externos. A exceção é o <script type="module">, que recebe defer por padrão, mesmo quando inline.
O defer é melhor do que colocar scripts no final do body? Sim. Um script com defer no <head> começa a baixar imediatamente (em paralelo com o parsing do HTML). Um script no final do body não pode começar a ser baixado até que o parser o alcance. O defer oferece uma descoberta mais precoce e uma execução mais tardia, o que é o melhor dos dois mundos.
Como async e defer afetam os Core Web Vitals
Scripts síncronos prejudicam diretamente o FCP porque nada é pintado até que eles terminem. Eles também prejudicam o LCP se o elemento LCP não puder ser renderizado até que os scripts sejam concluídos.
Scripts async melhoram o FCP (a primeira pintura não é bloqueada pelo download), mas ainda podem causar problemas de INP se executarem durante a interação do usuário e bloquearem a thread principal (main thread).
Scripts com defer fornecem as melhores métricas de pintura (paint metrics) porque eles não interferem em nada com a renderização inicial. O contraponto: se sua página depende de JavaScript para exibir o conteúdo (single-page apps), o defer pode, na verdade, atrasar o LCP porque o conteúdo não aparece até que o script seja executado após o parsing.
Nos dados de monitoramento do CoreDash, sites que moveram todos os scripts não críticos de sync para defer viram o FCP melhorar em [CD:placeholder] ms, em média.
Dando um passo além: carregue scripts sob demanda
Async e defer podem acelerar uma página por não bloquearem o parser, mas é importante notar que adiar scripts não resolverá todos os seus problemas. Por exemplo, o elemento de Largest Contentful Paint é vulnerável à competição de rede e CPU causada por scripts com defer e async. A Interaction to Next Paint também é afetada por scripts que são executados cedo durante o carregamento da página. É por isso que, sempre que possível, você deve carregar scripts sob demanda para ter mais controle sobre o impacto deles no desempenho da página. Leia como carregamos scripts sob demanda.
Para uma visão geral completa de todas as estratégias de carregamento de JavaScript, veja 16 métodos para aplicar defer em JavaScript. Se você está lidando com o aviso de recursos de bloqueio de renderização do Lighthouse, esse guia cobre a correção. Você também pode ajustar o carregamento com níveis de prioridade de JavaScript e escolher a localização ideal de script no head vs footer.
Ask AI why your INP spiked.
CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.
See How It Works
