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

Nem todos os scripts são criados iguais

Uma coisa sempre esteve clara: nem todo JavaScript é criado da mesma forma. Alguns scripts lidam com interações críticas, como 'interação de 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 visitantes que estão prestes a deixar o seu site a preencher um questionário. Tenho certeza de que todos poderíamos viver sem estes últimos, mas seria muito difícil navegar em um site sem os primeiros.

Ainda assim, no 'seu site médio', em um nível técnico, essa distinção quase nunca é feita. Todos os JavaScripts são 'apenas adicionados' à página e o navegador é deixado para se virar. Agora, isso é um problema porque o seu navegador não faz ideia do que é importante e do que não é. Nós, como desenvolvedores, sabemos. 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 solicitações, de acordo com o Web Almanac de 2025. Cerca de 44% desse JavaScript nunca chega a ser executado. Apenas 13% das páginas passam na auditoria de recursos de bloqueio de 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 as Core Web Vitals

Apenas adicionar scripts à página sem a devida consideração pode impactar todas as 3 Core Web Vitals. A Largest Contentful Paint, a Interaction to Next Paint e a Cumulative Layout Shift.

Exemplo: o recurso de rede da LCP é atrasado por JavaScripts de bloqueio de renderização

A Largest Contentful Paint é propensa à competição por largura de banda e CPU. Quando muitos scripts lutam pelos primeiros recursos de rede, isso atrasará o recurso de rede da Largest Contentful Paint e o trabalho inicial da CPU atrasará a LCP ao bloquear a thread principal.

A Interaction to Next Paint pode ser afetada por scripts 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 uma Cumulative Layout Shift se eles 'mudarem a aparência da página'. Scripts de anúncios que injetam banners na página e sliders são famosos por fazer isso.

5 tipos de prioridades de JavaScript

Eu gosto de distinguir entre 5 tipos de prioridades de JavaScript.

• Render Critical: esses scripts estão entre os piores para se ter. Eles mudam 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.
• Critical Scripts: Esses scripts lidam com funcionalidades críticas da página e, sem eles, tarefas críticas como adicionar um produto a um carrinho, pesquisa no site ou navegação não são possíveis.
• Important Scripts: Esses scripts lidam com a lógica de negócios importante e o seu site depende deles. Por exemplo: Analytics.
• Nice to Have Scripts: Esses scripts são bons de se ter, mas se a situação apertar, 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.
• Future Scripts: Esses scripts podem ser críticos ou bons de se ter, mas não precisamos deles agora porque 'outras etapas' precisam ser concluídas 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, aqui está 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 Críticos de Renderização (Render-Critical Scripts)

Esses scripts mudam 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 teste 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 ou atrasados. Qualquer atraso fará com que o layout do site mude causando uma péssima UX e falhas nas 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 críticos de renderização sempre que possível. Reescreva seu código para remover a dependência desses tipos de scripts.
• Se for inevitável, coloque 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 head para acionar um download 'o mais cedo possível'.

2. Scripts Críticos (Critical Scripts)

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

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

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

Melhores Práticas:

• Mantenha scripts como esses no mínimo e não combine essa funcionalidade com outras funcionalidades menos críticas.
• Carregue esses scripts cedo usando async ou defer, dependendo de suas dependências.
• Use Real User Monitoring para identificar gargalos na execução e certifique-se de que o desempenho deles esteja alinhado com as necessidades dos usuários.

3. Scripts Importantes (Important Scripts)

Esses scripts apoiam o seu negócio, mas não são necessários para a página funcionar. Scripts de Analytics, por exemplo, fornecem dados essenciais, mas não precisam carregar antes de elementos visuais mais importantes. A distinção entre scripts críticos e importantes pode ser motivo de debate, portanto, certifique-se de conversar com todos os envolvidos 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 o DOMContentLoaded

Ao injetar o script após o evento DOMContentLoaded, você garante que o script comece a ser baixado diretamente após o HTML ter sido totalmente analisado. 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 recursos iniciais 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 até depois que o navegador tenha processado todo o documento e atinge aproximadamente o mesmo resultado que a técnica 1. A única diferença é que a técnica 1 ignora o scanner de pré-carregamento 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 rapidamente e colocar na fila recursos críticos. Ignorar o scanner de pré-carregamento pode ser uma boa ideia se houver a possibilidade de imagens com carregamento lento na viewport, enquanto o uso do scanner de pré-carregamento acelerará o carregamento deste script.

Uma nota sobre fetchpriority: você pode esperar que fetchpriority="low" em um script adiado reduza a sua prioridade. Isso não acontece. Scripts deferred e async já carregam com prioridade Low no Chrome. Adicionar fetchpriority="low" a eles é inócuo. O atributo fetchpriority só faz diferença em scripts bloqueantes, onde ele pode derrubar a prioridade de Highest para High. Para mais maneiras de adiar o JavaScript, veja o nosso guia completo.

4. Scripts Agradáveis de se Ter (Nice-to-Have Scripts)

Esses scripts melhoram a user experience, mas não são necessários para o site funcionar. Exemplos incluem widgets de chat, popups de feedback do cliente ou animações opcionais.

Esses scripts são um candidato ideal para um padrão chamado 'lazy on load' (carregamento lento ao carregar a página). Isso significa: espere pelo evento load da página e então, durante o tempo ocioso, injete o script. Esperar pelo evento load garante que o script não concorra por largura de banda e CPU com recursos iniciais mais importantes. Esperar por um momento ocioso garante que o navegador não esteja lidando com tarefas mais importantes, como a entrada do usuário.

Aqui está um exemplo prático:

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 suporta requestIdleCallback. Para scripts que também precisam dividir sua execução em partes menores, considere o uso de scheduler.yield() para manter a thread principal responsiva e proteger a sua pontuação de INP.

Melhores Práticas:

• Carregue esses scripts sob demanda após o carregamento da página e espere por um momento ocioso.
• Entenda que os scripts carregados com esse padrão não têm garantia de carregar rápido.

Em sites monitorados pela CoreDash, páginas que adiam (defer) scripts não críticos para depois do evento load têm uma pontuação de 84% 'boa' no INP, em comparação com 61% para páginas que carregam todos os scripts antecipadamente.

5. Scripts Futuros (Future Scripts)

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 depois que um usuário adicionou itens ao seu carrinho. Esses scripts podem esperar até muito mais tarde na jornada do usuário.

Dê uma olhada neste exemplo. Ele usa o IntersectionObserver para carregar a lógica JS apenas quando for necessária: quando o formulário estiver na 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 pelas ações do usuário.
• Use técnicas de divisão de código (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 a página para uma seção específica.

A maioria dos sites só precisa de dois padrões: defer para qualquer coisa funcional e o padrão load+idle para todo o resto. Se você está gastando tempo ajustando fetchpriority em scripts, provavelmente está complicando demais. Obtenha as grandes vitórias primeiro: adie (defer) o que puder, atrase o que puder e exclua o que você não precisa.