Quando o pré-carregamento de folhas de estilo faz (ou não) sentido

Explorando as considerações sobre o pré-carregamento de folhas de estilo para otimização de desempenho web.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-07

Quando o Pré-carregamento de Folhas de Estilo Faz (ou Não) Sentido

Encontro regularmente folhas de estilo pré-carregadas e muita desinformação em torno delas. Pré-carregar um recurso (geralmente) altera sua prioridade e o momento em que é programado para download. No entanto, como muitas estratégias de otimização que encontro diariamente, o pré-carregamento de folhas de estilo não faz muito sentido na maior parte do tempo. Neste artigo, vou explorar quando o pré-carregamento de folhas de estilo faz sentido e quando pode não ser a melhor escolha.

A ideia de pré-carregar folhas de estilo:

Antes de mergulhar nas considerações, vamos rever brevemente o conceito de pré-carregamento de folhas de estilo. As folhas de estilo bloqueiam a renderização. Isto significa que enquanto as folhas de estilo estão sendo baixadas, a página não será renderizada pelo navegador e tudo o que o visitante verá é uma tela em branco. 

Para minimizar o tempo que leva para baixar uma folha de estilo, os desenvolvedores às vezes recorrem ao pré-carregamento de folhas de estilo. O pré-carregamento envolve buscar recursos críticos antecipadamente, minimizando a latência associada ao carregamento quando eles são realmente necessários. Isso é tipicamente alcançado usando a tag <link> com o atributo rel="preload".

Caso 1: pré-carregar a folha de estilo logo antes de declará-la.

Às vezes, desenvolvedores, com todo seu entusiasmo, tentam minimizar o impacto do CSS pré-carregando-o no HTML logo antes da declaração CSS real. Isso se parecerá com algo assim:

<link rel="preload" as="style" href="style.css">
<link rel="stylesheet" href="style.css">

Agora isso não faz sentido de forma alguma e, na melhor das hipóteses, você não vai desacelerar a página! Um navegador lerá o html e começará a carregar todos os recursos críticos na página, principalmente na ordem em que os encontra. Isso significa que se você removesse a linha de pré-carregamento, o navegador teria encontrado a folha de estilo de qualquer maneira e teria começado a baixar a folha de estilo não importa o quê. Você apenas adicionou uma linha extra, isso é tudo! Mas fica pior. Folhas de estilo pré-carregadas têm uma prioridade mais baixa do que folhas de estilo normais. Então, nas piores circunstâncias, você realmente desaceleraria sua página!

3 folhas de estilo pré-carregadas

3 folhas de estilo normais

Caso 2: pré-carregar a folha de estilo com um cabeçalho link.

Esta ideia é interessante. Podemos usar o [url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link]cabeçalho de servidor link[/url] para pré-carregar uma folha de estilo. Isso se pareceria com algo assim:

Link: <style.css>; rel=preload; as=style

A ideia aqui é fazer com que o navegador enfileire a folha de estilo antes de começar a analisar o HTML. Esta é uma ideia muito boa e gosto de como funciona a mente de um desenvolvedor que pensou nisso! Mas infelizmente, na vida real, você obterá muito pouco benefício disso. Estamos falando de alguns microssegundos. Esses são resultados bastante decepcionantes, mas não se preocupe. Podemos usar este passo para fazer algumas melhorias reais!

Caso 3: 103 early hints para folhas de estilo

Esta é a única ideia que realmente lhe dará alguns resultados de Core Web Vitals! Enviar early hints para folhas de estilo melhorará métricas como o first contentful paint e o largest contentful paint.

Cabeçalhos 103 early hint são enviados antes da resposta html real. Isso significa que enquanto você está baixando o HTML, o navegador também pode começar a baixar folhas de estilo em paralelo.  O melhor cenário possível é que, no momento em que o HTML terminou de baixar, as folhas de estilo também podem ter sido baixadas. Isso significa que há zero tempo de bloqueio de renderização dessas folhas de estilo. E isso pode e acontece em redes mais lentas! Em redes mais rápidas, o efeito é menos óbvio, mas usar 103 early resource hints ainda é mais rápido em quase todos os casos!

Uma resposta 103 early hint parece muito semelhante a um cabeçalho link de pré-carregamento. Para usar 103 early hints, você precisará configurar seu servidor web ou sua CDN.  

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style

Alguns CDNs como CloudFlare permitirão que você acione um 103 early hint simplesmente definindo um cabeçalho link de pré-carregamento (conforme descrito na ideia 2)

Caso 4: pré-carregar folhas de estilo para obter CSS assíncrono

Um truque bem conhecido para tornar o CSS não bloqueante de renderização é pré-carregar a folha de estilo e, uma vez carregada, adicioná-la à página. A ideia é simples e se parece com isto:

<link 
   rel="preload" 
   href="style.css" 
   as="style"
   onload="this.onload=null;this.rel=stylesheet"
>

É baseado no código de pré-carregamento normal <link rel="preload" as="style" href="style.css"> e adiciona um event listener onload onload="this.onload=null;this.rel=stylesheet" que altera o link para sua forma final <link rel="stylesheet" href="style.css">

Esta é outra ideia que simplesmente faz sentido. Se uma folha de estilo não está bloqueando a renderização, o navegador pode continuar a analisar e renderizar a página sem a necessidade de parar e esperar pela folha de estilo. No entanto, tenha cuidado!

  • Não use CSS assíncrono no viewport visível. Isso provavelmente causará um Cumulative Layout Shift e isso levará a uma experiência de usuário ruim
  • Considere o trade-off. CSS assíncrono provavelmente causará uma re-renderização de diferentes partes da página. Isso impactará métricas como o Interaction to Next Paint. 

Caso 5: pré-cachear folhas de estilo

Em raras ocasiões, vejo soluções engenhosas que tentam pré-aquecer arquivos de cache para visualizações de página subsequentes. E embora eu aplauda o entusiasmo com que essas soluções são feitas. Por favor, NÃO faça isso!

A ideia é simples: na página inicial você poderia, se quisesse, já pré-cachear os estilos para outra página. Digamos, a página de produto. Em algum momento após o carregamento da página, você pré-carregaria folhas de estilo para adicioná-las ao cache do navegador.

function preloadStylesheet(url) {
    var link = document.createElement(link);
    link.rel = preload;
    link.href = url;
    link.as = style;
    document.head.appendChild(link);
}

window.addEventListener(load, function () {
    preloadStylesheet(cart.css);
    preloadStylesheet(shop.css);
});

À primeira vista, isso não parece tão ruim. Em qualquer página de produto, cart.css e shop.css agora estão disponíveis e não bloquearão mais a renderização. Existem algumas razões para não fazer isso!

  1.  Existem melhores maneiras, por exemplo [url=https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API]pré-renderização especulativa[/url] ou usando um service worker.
  2. Você provavelmente desperdiçará recursos e o trade-off não valerá a pena! Vamos encarar: se pré-carregar recursos fosse fácil, os navegadores teriam sido melhores nisso. 
  3. Soluções como esta são difíceis de manter e provavelmente causarão problemas em algum momento no futuro
  4. Você precisará pré-carregar todas as folhas de estilo, não apenas algumas. Porque todas as folhas de estilo bloqueiam a renderização e são baixadas em paralelo, apenas 1 folha de estilo pode ter o mesmo efeito que várias folhas de estilo.


Urgent Fix Required?

Google Search Console failing? I offer rapid-response auditing to identify the failure point within 48 hours.

Request Urgent Audit >>

  • 48hr Turnaround
  • Rapid Response
  • Failure Identification
Quando o pré-carregamento de folhas de estilo faz (ou não) sentido Core Web Vitals Quando o pré-carregamento de folhas de estilo faz (ou não) sentido