5 Níveis de Prioridade JavaScript e Como Usá-los

Nem todos os scripts são criados iguais

Uma coisa sempre esteve clara: nem todo JavaScript é criado igual. Alguns scripts lidam com interações críticas, como 'interação com menu' ou 'adicionar ao carrinho', enquanto outros scripts são muito menos importantes. Pegue o seu script de popup de 'intenção de saída', que convida os visitantes que estão prestes a sair do seu site a preencher um questionário. Tenho certeza de que todos poderíamos viver sem os últimos, mas seria muito difícil navegar em um site sem o primeiro.

No entanto, no 'seu site médio', em um nível técnico, essa distinção quase nunca é feita. Todos os JavaScripts são 'simplesmente adicionados' à página e o navegador que se vire para descobrir. Isso é um problema, porque seu navegador não tem ideia do que é importante e do que não é. Nós, como desenvolvedores, temos. Então, vamos consertar isso!

Última revisão por Arjen Karel em março de 2026

A página móvel mediana carrega 646 KB de JavaScript em 22 requisições, de acordo com o Web Almanac de 2025. Cerca de 44% desse JavaScript sequer chega a ser executado. Apenas 13% das páginas passam na auditoria de recursos que bloqueiam a renderização do Lighthouse. O problema não é apenas quanto JavaScript você carrega. É quando e em que ordem.

Como a prioridade do JavaScript pode impactar o Core Web Vitals

Simplesmente adicionar scripts à página sem a devida consideração pode impactar todos os 3 Core Web Vitals. O Largest Contentful Paint, o Interaction to Next Paint e o Cumulative Layout Shift.

Exemplo: o recurso de rede do LCP é atrasado por JavaScripts que bloqueiam a renderização

O Largest Contentful Paint é propenso a competição de largura de banda e CPU. Quando muitos scripts disputam os primeiros recursos de rede, isso atrasará o recurso de rede do Largest Contentful Paint, e o trabalho inicial da CPU atrasará o LCP ao bloquear a thread principal.

O Interaction to Next Paint pode ser afetado por scripts sendo executados logo antes de uma interação. Quando os scripts são executados, eles bloqueiam a thread principal e atrasarão qualquer interação durante esse tempo de execução.

Os scripts também podem causar um Cumulative Layout Shift se eles 'alterarem a aparência da página'. Scripts de anúncios que injetam banners na página e sliders são famosos por fazerem isso.

5 tipos de prioridades JavaScript

Gosto de distinguir entre 5 tipos de prioridades JavaScript.

• Renderização Crítica: estes scripts estão entre os piores que se pode ter. Eles alteram o layout da página e, sem carregar esses scripts, o layout será completamente diferente. Exemplo: alguns scripts de slider ou um teste A/B.
• Scripts Críticos: Estes scripts lidam com funcionalidades críticas da página e, sem eles, tarefas críticas como adicionar um produto ao carrinho, busca no site ou navegação não são possíveis.
• Scripts Importantes: Estes scripts lidam com lógica de negócios importante e seu site depende deles. Por exemplo: Analytics.
• Scripts Desejáveis (Nice to Have): Estes scripts são bons de se ter, mas na hora do aperto, nós realmente não precisamos deles para a página funcionar. Por exemplo, um widget de chat ou uma intenção de saída.
• Scripts Futuros: Estes scripts podem ser críticos ou desejáveis, mas não precisamos deles agora porque 'outros passos' precisam ser tomados antes que possamos realmente usá-los. Por exemplo, um script de checkout em várias etapas.

Antes de olharmos para cada nível de prioridade, eis como o Chrome atribui prioridade de rede a diferentes tipos de script:

Entender esses padrões é a chave para a priorização de recursos.

1. Scripts de Renderização Crítica

Esses scripts alteram diretamente o layout da página. Sem eles, a página parece completamente diferente do seu design pretendido. Exemplos incluem scripts para sliders ou frameworks de testes A/B que alteram o layout logo no início do processo de carregamento.

O problema com esses scripts é que eles não podem ser adiados (deferred) ou atrasados. Qualquer atraso fará com que o layout do site sofra mudanças, causando uma UX ruim e reprovação nos Core Web Vitals.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Page Title</title>
    <link href="styles.css" rel="stylesheet" />
    <script src="render-critical.js"></script>
  </head>
  <body></body>
</html>

Melhores Práticas:

• Evite scripts de renderização crítica sempre que possível. Reescreva seu código para remover a dependência desse tipo de script.
• Se for inevitável, coloque em linha (inline) ou carregue apenas as partes absolutamente necessárias desses scripts.
• Não use defer ou async nesses scripts e coloque-os no topo da tag head para acionar um download 'o mais cedo possível'.

2. Scripts Críticos

Esses scripts habilitam interações fundamentais. Sem eles, tarefas críticas como navegação no site, adição de itens a um carrinho, aviso de cookies ou a realização de uma pesquisa se tornam impossíveis. Eles são indispensáveis para a funcionalidade principal do site.

Esses scripts devem ser colocados no head da página com os atributos async ou defer. Para uma comparação completa dessas duas abordagens, veja async vs defer e como eles afetam o Core Web Vitals.

<script defer src="critical.js"></script>
<script async src="critical.js"></script>

Melhores Práticas:

• Mantenha o número de scripts como estes ao mínimo e não combine essa funcionalidade com outras menos críticas.
• Carregue esses scripts precocemente usando async ou defer, dependendo das suas dependências.
• Use o Real User Monitoring para identificar gargalos na execução e certificar-se de que o desempenho deles esteja alinhado às necessidades do usuário.

3. Scripts Importantes

Estes scripts suportam o seu negócio, mas não são necessários para que a página funcione. Scripts de Analytics, por exemplo, fornecem dados essenciais, mas não precisam ser carregados antes de elementos visuais mais importantes. A distinção entre scripts críticos e importantes pode ser uma questão de debate, portanto, não se esqueça de conversar com todos os stakeholders antes de definir essa prioridade!

Existem 2 maneiras confiáveis de reduzir a prioridade do script para esses tipos de scripts.

<html>
<head>
<!-- method 1: inject after DOMContentLoaded -->
<script>
  document.addEventListener('DOMContentLoaded', function() {
    var script = document.createElement('script');
    script.src = 'important.js';
    document.body.appendChild(script);
  });
</script>
</head>
<body>

<!-- method 2: place at the bottom of the page -->
<script defer src="important.js"></script>
</body>
</html>

1: Injetar após DOMContentLoaded

Ao injetar o script após o evento DOMContentLoaded, você garante que o script comece a ser baixado logo após o HTML ter sido totalmente analisado (parsed). Isso permite que recursos descobríveis, como imagens e fontes, tenham precedência. Este método oferece um equilíbrio: o script começa a carregar cedo o suficiente para evitar atrasos na funcionalidade, mas não compete com os primeiros recursos que são cruciais para a renderização inicial da página.

2: Colocar no final da página

Esta técnica clássica adia o carregamento do script para depois que o navegador tiver processado todo o documento, alcançando basicamente o mesmo resultado da técnica 1. A única diferença é que a técnica 1 ignora o scanner de pré-carregamento (preload scanner) do seu navegador, enquanto esta técnica não. O scanner de pré-carregamento é um scanner rápido e leve que o seu navegador usa para identificar e enfileirar rapidamente recursos críticos. Ignorar o scanner de pré-carregamento pode ser uma boa ideia se houver a possibilidade de imagens com carregamento lento (lazy load) no viewport, enquanto usar o scanner de pré-carregamento acelerará o carregamento para este script.

Uma nota sobre fetchpriority: você pode esperar que fetchpriority="low" em um script com defer abaixaria sua prioridade. Isso não acontece. Scripts deferred e async já carregam com prioridade Baixa no Chrome. Adicionar fetchpriority="low" a eles é uma operação nula (no-op). O atributo fetchpriority só faz diferença em scripts de bloqueio, onde ele pode derrubar a prioridade de Altíssima (Highest) para Alta (High). Para mais maneiras de adiar o JavaScript, confira nosso guia completo.

4. Scripts Desejáveis (Nice-to-Have)

Estes scripts melhoram a UX, mas não são exigidos para o site funcionar. Exemplos incluem widgets de chat, popups de feedback de clientes ou animações opcionais.

Estes scripts são um candidato ideal para um padrão chamado 'lazy on load'. Isso significa: aguarde o evento de carregamento (load) da página e então, durante o tempo ocioso, injete o script. Aguardar o evento de carregamento garante que o script não concorra por largura de banda e CPU com recursos iniciais mais importantes. Aguardar um momento ocioso garante que o navegador não esteja lidando com tarefas mais importantes, como interações do usuário.

Aqui está um exemplo funcional:

window.addEventListener("load", () => {
  const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1));
  idle(() => {
    const script = document.createElement("script");
    script.src = "/path/to/script.js";
    document.head.appendChild(script);
  });
});

O fallback do setTimeout é necessário porque o Safari não oferece suporte a requestIdleCallback. Para scripts que também precisam dividir sua execução em partes menores, considere usar scheduler.yield() para manter a thread principal responsiva e proteger sua pontuação de INP.

Melhores Práticas:

• Faça o carregamento lento (lazy-load) desses scripts após o carregamento da página e aguarde um momento ocioso.
• Entenda que scripts carregados com esse padrão não têm garantia de carregar rápido.

Nos sites monitorados pelo CoreDash, páginas que adiam scripts não críticos para depois do evento de carregamento (load) marcam 84% como 'bom' no INP, comparado a 61% para páginas que carregam todos os scripts precocemente (eagerly).

5. Scripts Futuros

Scripts futuros são aqueles que não serão necessários até que condições específicas sejam atendidas. Por exemplo, um script de checkout em várias etapas se torna relevante apenas após um usuário ter adicionado itens ao seu carrinho. Esses scripts podem aguardar até um momento muito posterior na jornada do usuário.

Dê uma olhada neste exemplo. Ele usa o IntersectionObserver para carregar a lógica JS apenas quando é necessária: quando o formulário está no viewport visível.

<!DOCTYPE html>
<html>
  <head>
    <script>
      document.addEventListener("DOMContentLoaded", function () {
        const form = document.querySelector("form");
        const observer = new IntersectionObserver(function (entries) {
          entries.forEach((entry) => {
            if (entry.isIntersecting) {
              const script = document.createElement("script");
              script.src = "/sign-up.js";
              document.head.appendChild(script);
              observer.unobserve(form);
            }
          });
        });
        observer.observe(form);
      });
    </script>
  </head>
  <body>
    <form action="/sign-up" method="post">
      <label for="email">Email:</label>
      <input type="email" id="email" name="email" required />
      <button type="submit">Sign Up</button>
    </form>
  </body>
</html>

Melhores Práticas:

• Carregue esses scripts sob demanda, acionados por ações do usuário.
• Use técnicas de code-splitting para entregar apenas as partes necessárias em cada etapa.
• Injete-os dinamicamente apenas quando necessário, como quando um usuário rola para uma seção específica.

A maioria dos sites só precisa de dois padrões: defer para tudo o que for funcional e o padrão load+idle (carregamento + ociosidade) para todo o resto. Se você está gastando tempo ajustando a fetchpriority nos scripts, provavelmente está complicando demais. Consiga as grandes vitórias primeiro: use defer no que puder, atrase o que puder e exclua o que você não precisa.