JavaScript Defer vs Async e como isso afeta os Core Web Vitals
Aprenda quando usar async e quando usar defer no JavaScript para obter os melhores resultados nos 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 analisador (sync), assíncrono ou adiado (deferred). Isso é uma pena porque diferentes scripts têm diferentes tempos ideais.
Revisado pela última vez por Arjen Karel em março de 2026
Table of Contents!
- JavaScript Defer vs Async e como isso afeta os Core Web Vitals
- Resumindo
- 1. JavaScript Síncrono (sync)
- 2. JavaScript Assíncrono (async)
- 3. JavaScript Adiado (defer)
- 4. Scripts de módulo
- Tabela de comparação
- Perguntas comuns
- Como async e defer afetam os Core Web Vitals
- Indo um passo além: carregue scripts sob demanda
De acordo com o Web Almanac 2025, apenas 15% das páginas mobile passam na auditoria de recursos de bloqueio de renderização. A página mediana carrega 22 scripts totalizando mais de 630 KB, com 251 KB desse JavaScript totalmente não utilizado. A maioria dos sites está carregando JavaScript em excesso, e no momento errado.
Resumindo
O JavaScript 'normal' no head da página bloqueia o navegador de analisar o HTML até que ele seja baixado e executado. Scripts async são baixados em segundo plano, mas são executados assim que estão prontos, o que ainda pode interromper a análise. Scripts deferred são baixados em segundo plano e esperam até que a análise seja concluída antes de serem executados, 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 (sync) apenas se o script precisar ser executado antes da página renderizar. Em caso de dúvida, use defer.
1. JavaScript Síncrono (sync)
Por padrão, os scripts no head da página são síncronos. Quando o navegador encontra um script síncrono, ele para de analisar o HTML, baixa o script e o executa antes de continuar. Isso significa que nenhum pixel é pintado até que todos os scripts sync sejam concluídos. Para scripts grandes ou lentos, isso cria um atraso visível no First Contentful Paint.
<!DOCTYPE html> <html> <head> <title>Sync JavaScript Example</title> <script src="script1.js"></script> <script src="script2.js"></script> </head> <body> <!-- Page content here --> </body> </html>
O navegador deve baixar e executar script1.js antes mesmo de iniciar o script2.js. Enquanto isso, nada renderiza. A página mobile 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 continua analisando o HTML. O script é executado assim que termina de baixar, onde quer que o analisador esteja naquele momento. A análise pausa apenas durante a execução.
<!DOCTYPE html> <html> <head> <title>Async JavaScript Example</title> <script src="script1.js" async></script> <script src="script2.js" async></script> </head> <body> <!-- Page content here --> </body> </html>
Scripts async não garantem a ordem de execução. O script que terminar de baixar primeiro, executa primeiro. Se script2.js depende de script1.js, async 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 ter em mente: no Chrome, scripts async recebem baixa prioridade de rede 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 a análise), adicione fetchpriority="high".
3. JavaScript Adiado (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. Scripts deferred são executados na ordem do documento, logo antes que o evento DOMContentLoaded seja disparado.
<!DOCTYPE html> <html> <head> <title>Defer JavaScript Example</title> <script src="script1.js" defer></script> <script src="script2.js" defer></script> </head> <body> <!-- Page content here --> </body> </html>
Defer é a escolha mais segura para a maioria dos scripts. O DOM está totalmente disponível quando o script é executado, a ordem de execução é preservada e a primeira pintura não é bloqueada. The Telegraph adiou todos os seus scripts e melhorou o tempo de carregamento de anúncios em 4 segundos.
4. Scripts de módulo
Se você usa módulos ES (<script type="module">), você obtém o comportamento defer automaticamente. Scripts de módulo são baixados em segundo plano, executam após a análise e mantêm a ordem. Adicionar defer explicitamente não tem efeito porque já é o padrão.
Você pode adicionar async a um script de módulo se quiser que ele seja executado assim que seu gráfico de dependências for resolvido, em vez de esperar a conclusão da análise.
Tabela de comparação
| Atributo | Downloads | Executa | Bloqueia a análise? | Ordem preservada? |
|---|---|---|---|---|
none (sync) |
Bloqueia a análise 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 a análise do HTML, antes do DOMContentLoaded | Não | Sim |
type="module" |
Em segundo plano | Após a análise do HTML (mesmo que defer) | Não | Sim |
Perguntas comuns
E se eu usar tanto async quanto defer na mesma tag? Async vence. 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 funcionam apenas em scripts externos. A exceção é <script type="module">, que é deferred por padrão, mesmo quando inline.
Defer é melhor do que colocar scripts no final do body? Sim. Um script deferred no <head> começa a baixar imediatamente (em paralelo com a análise do HTML). Um script no final do body não pode começar a ser baixado até que o analisador chegue até ele. Defer oferece descoberta mais cedo e execução mais tarde, 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 pinta até que eles terminem. Eles também prejudicam o LCP se o elemento LCP não puder renderizar 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.
Scripts defer oferecem as melhores métricas de pintura porque eles não interferem em nada na renderização inicial. O trade-off: se a sua página depende de JavaScript para exibir conteúdo (single-page apps), defer pode na verdade atrasar o LCP porque o conteúdo não aparece até que o script seja executado após a análise.
Nos dados de monitoramento do CoreDash, sites que moveram todos os scripts não críticos de sync para defer viram seu FCP melhorar em 340 ms em média.
Indo um passo além: carregue scripts sob demanda
Async e defer podem acelerar uma página por não bloquearem o analisador, mas é importante notar que adiar scripts não resolverá todos os seus problemas. Por exemplo, o elemento do Largest Contentful Paint é vulnerável à competição de rede e CPU causada por scripts deferred e async. O Interaction to Next Paint também é afetado por scripts que executam 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 na performance da página. Leia como nós carregamos scripts sob demanda.
Para uma visão geral completa de todas as estratégias de carregamento de JavaScript, veja 16 métodos para adiar JavaScript. Se você estiver lidando com o aviso de recursos de bloqueio de renderização do Lighthouse, esse guia aborda a correção. Você também pode ajustar o carregamento com níveis de prioridade de JavaScript e escolher o posicionamento ideal de script no head vs footer.
Seu score do Lighthouse não conta a história toda.
Seus usuários reais estão em Android com 4G. Analiso o que eles vivem de fato.
Analisar dados de campo
