Otimizando a Prioridade do JavaScript para Carregamentos de Página Mais Rápidos
Aprenda a priorizar scripts de forma eficaz para melhorar os Core Web Vitals.
Gerenciando Prioridades de JavaScript para Melhor Desempenho Web
Uma coisa sempre ficou clara: nem todo JavaScript é igual. 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. Peguemos o seu script de popup de 'exit intent' que convida 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, em 'um site comum', a nível técnico, essa distinção raramente é feita. Todos os JavaScripts são 'simplesmente adicionados' à página e o navegador fica encarregado de resolver. Isso é um problema porque o seu navegador não tem ideia do que é importante e do que não é. Nós, como desenvolvedores, sabemos. Então vamos corrigir isso!
Como a prioridade do JavaScript pode impactar os 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 é suscetível à competição de largura de banda e CPU. Quando muitos scripts competem pelos recursos de rede iniciais, isso atrasa o recurso de rede do Largest Contentful Paint e o trabalho inicial de CPU atrasa o LCP ao bloquear a thread principal.
O Interaction to Next Paint pode ser afetado por scripts executando logo antes de uma interação. Quando scripts são executados, eles bloqueiam a thread principal e atrasam qualquer interação durante esse tempo de execução.
Scripts também podem causar um Cumulative Layout Shift se os scripts 'mudam a aparência da página'. Scripts de anúncios que injetam banners na página e sliders são notórios por fazer isso.
5 Tipos de prioridade de JavaScript
Gosto de distinguir entre 5 tipos de prioridades de JavaScript. Vamos discuti-los rapidamente antes de aprofundar.
- Render Critical: esses scripts estão entre os piores de se ter. Eles alteram o layout da página e sem carregar esses scripts o layout será completamente diferente. Exemplo: alguns scripts de slider ou testes A/B.
- Critical Scripts: Esses 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.
- Important scripts. Esses scripts lidam com lógica importante (de negócios) e seu site depende deles. Por exemplo: Analytics
- Nice to have scripts. Esses scripts são desejáveis, mas em último caso não precisamos realmente deles para a página funcionar. Por exemplo, um widget de chat ou um exit intent
- Future Scripts. Esses scripts podem ser críticos ou desejáveis, mas não precisamos deles agora porque 'outros passos' precisam ser dados antes de podermos usar esses scripts. Por exemplo, um script de checkout em múltiplas etapas.
1. Scripts Críticos para Renderização
Esses são os scripts mais disruptivos, pois impactam diretamente como a página é exibida. Sem eles, o layout pode quebrar ou parecer drasticamente diferente do design pretendido. Exemplos incluem scripts para sliders ou frameworks de testes A/B que alteram o layout no início do processo de carregamento.
O problema com esses tipos de script é que eles não podem ser adiados ou atrasados. Qualquer atraso fará o layout do site mudar, causando uma UX ruim e fazendo os Core Web Vitals falharem.
<!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 para renderização como estes sempre que possível. Reescreva seu código para evitar dependência desses tipos de scripts.
- Se não houver como evitar, 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 do head para acionar um download 'o mais cedo possível'.
2. Scripts Críticos
Esses scripts permitem interações fundamentais. Sem eles, tarefas críticas como navegação do site, adicionar itens ao carrinho, aviso de cookies ou realizar uma busca tornam-se impossíveis. Eles são indispensáveis para a funcionalidade principal do site.
Esses scripts devem ser colocados no head da página com o atributo async ou defer.
<script defer src="critical.js"></script>
<script async src="critical.js"></script>
Best Practices:
- Mantenha scripts como esses ao mínimo e não combine essa funcionalidade com outras funcionalidades menos críticas.
- Carregue esses scripts cedo usando
asyncoudefer, dependendo de suas dependências. - Use ferramentas de Real User Monitoring (RUM), como o CoreDash, para identificar gargalos na execução e garantir que o desempenho esteja alinhado com as necessidades do usuário.
3. Scripts Importantes
Embora não estejam diretamente ligados à usabilidade do site, scripts importantes suportam funções-chave de negócios. Scripts de analytics, por exemplo, fornecem dados essenciais, mas não precisam carregar antes de elementos visuais mais importantes. Obviamente, a distinção entre scripts críticos e importantes pode ser discutível, então certifique-se de consultar todas as partes interessadas antes de definir essa prioridade!
Existem 3 maneiras de diminuir a prioridade do script para esses tipos de scripts.
<html>
<head>
<!-- method 1: low fetchpriority -->
<script fetchpriority="low" defer src="important.js"></script>
<!-- method 2: 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 3: place at the bottom of the page -->
<script defer src="important.js"></script>
</body>
</html> 1. Low fetchpriority.
Definir o fetchpriority reduzirá a prioridade relativa do script. Outros scripts com defer ou async provavelmente serão enfileirados com alta prioridade, enquanto scripts com fetchprioriy="low" serão enfileirados com baixa prioridade. Dependendo da sua página (ou do seu caminho de renderização), isso pode ser suficiente para priorizar outros recursos como sua imagem de Largest Contentful Paint e fontes importantes.
2: Injetar após DOMContentLoaded
By injecting the script after the DOMContentLoaded event, you ensure the script starts downloading directly after the HTML has been fully parsed. This allows discoverable resources, such as images and fonts, to take precedence. This method provides a balance: the script begins loading early enough to avoid delays in functionality but doesn’t compete with early resources that are crucial to initial page rendering.
3: colocar no final da página
Esta técnica clássica adia o carregamento do script até que o navegador tenha processado todo o documento e alcança praticamente o mesmo resultado que a técnica anterior. A única diferença é que a técnica 2 pula o preload scanner do seu navegador enquanto esta técnica não. O preload scanner é um scanner leve e rápido que seu navegador usa para identificar e enfileirar rapidamente recursos críticos. Pular o preload scanner pode ser uma boa ideia se houver possibilidade de imagens lazy loaded no viewport, enquanto usar o preload scanner acelerará o carregamento deste script.
4. Scripts Desejáveis
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. Embora benéficos, não devem interferir na user experience principal.
Esses scripts são um candidato ideal para carregar com um padrão chamado 'lazy on load'. Isso significa esperar pelo evento de load da página e então, durante o tempo ocioso, injetar o script. Esperar pelo evento de load garante que o script não compita 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 entrada do usuário.
Aqui está um exemplo funcional:
window.addEventListener("load", () => {
window.requestIdleCallback(() => {
const script = document.createElement("script");
script.src = "/path/to/script.js";
document.head.appendChild(script);
});
});Best Practices:
- Faça lazy-load desses scripts após a página ter carregado e espere por um momento ocioso.
- Entenda que scripts carregados com esse padrão não têm garantia de carregar rapidamente
5. Scripts Futuros
Future scripts are those that won’t be needed until specific conditions are met. For example, a multi-stage checkout script becomes relevant only after a user has added items to their cart. These scripts can often wait until much later in the user’s journey.
Veja este exemplo. Ele usa o intersection observer para carregar a lógica JS necessária para o script de cadastro somente 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>
Best Practices:
- 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 até uma seção específica.
Urgent Fix Required?
Google Search Console failing? I offer rapid-response auditing to identify the failure point within 48 hours.
- 48hr Turnaround
- Rapid Response
- Failure Identification
