Quando o preload de stylesheets (não) faz sentido
Por que fazer o preload do seu CSS geralmente não ajuda, e o único caso em que ajuda
Quando o Preload de Stylesheets (Não) Faz Sentido
Encontro regularmente stylesheets com preload e muita desinformação sobre eles. Fazer o preload de um recurso altera quando ele é agendado para download. Mas, na maioria das vezes, o preload de stylesheets não ajuda. Em cinco casos, mostrarei a você quando funciona e quando não funciona.
Revisado pela última vez por Arjen Karel em março de 2026
Table of Contents!
- Quando o Preload de Stylesheets (Não) Faz Sentido
- A ideia do preload de stylesheets
- Caso 1: fazendo o preload do stylesheet logo antes de declará-lo
- Caso 2: fazendo o preload do stylesheet com um cabeçalho link
- Caso 3: 103 Early Hints para stylesheets
- Caso 4: fazer o preload de stylesheets para obter CSS assíncrono
- Caso 5: fazer o pré-cache de stylesheets
- O que realmente funciona para a performance do CSS
A ideia do preload de stylesheets
Stylesheets são bloqueadores de renderização (render blocking). Enquanto os stylesheets estão sendo baixados, a página não será renderizada pelo navegador e tudo o que o visitante verá é uma tela em branco.
Para minimizar o tempo necessário para baixar stylesheets, os desenvolvedores às vezes recorrem ao preload deles. O preload diz ao navegador para buscar um recurso antes de descobri-lo no HTML, para que fique pronto mais cedo. Isso é feito usando a tag <link> com o atributo rel="preload".
De acordo com o Web Almanac de 2025, apenas 13% das páginas para desktop passam na auditoria de recursos bloqueadores de renderização. O preload não é a solução. A solução é eliminar recursos bloqueadores de renderização desnecessários e adiar os stylesheets não críticos.
Caso 1: fazendo o preload do stylesheet logo antes de declará-lo
Às vezes, os desenvolvedores, em todo o seu entusiasmo, tentam minimizar o impacto do CSS fazendo o preload dele no HTML logo antes da declaração real do CSS. Isso ficará mais ou menos assim:
<link rel="preload" as="style" href="style.css">
<link rel="stylesheet" href="style.css">
Isso não faz sentido algum e, na melhor das hipóteses, você não deixará a página mais lenta. Os navegadores possuem um preload scanner integrado que verifica o HTML em busca de recursos para baixar antes que o parser principal chegue até eles. Se o seu <link> de stylesheet já estiver no <head>, o preload scanner o encontrará imediatamente. Adicionar uma dica rel="preload" para a mesma URL fornece ao navegador uma informação que ele já possui. Você apenas adicionou uma linha extra, só isso.
3 stylesheets com preload
3 stylesheets normais
Caso 2: fazendo o preload do stylesheet com um cabeçalho link
Esta ideia é interessante. Podemos usar o cabeçalho de servidor Link para fazer o preload de um stylesheet. Isso ficaria mais ou menos assim:
A ideia é fazer com que o navegador coloque o stylesheet na fila antes de começar a fazer o parsing do HTML. Eu gosto de como funciona a mente de um desenvolvedor que pensou nisso! Mas na vida real você terá muito pouco benefício. Estamos falando de alguns microssegundos. Resultados bem decepcionantes, mas essa ideia nos leva a algo que realmente funciona.
Caso 3: 103 Early Hints para stylesheets
Esta é a única ideia que realmente trará resultados para os Core Web Vitals. Enviar early hints para stylesheets melhorará métricas como o First Contentful Paint e o Largest Contentful Paint.
Os 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 stylesheets em paralelo. O melhor cenário é que, no momento em que o HTML terminar de baixar, os stylesheets também já terão sido baixados. Zero tempo de render blocking vindo desses stylesheets. Isso pode e de fato acontece em redes mais lentas. Em redes mais rápidas, o efeito é menos óbvio, mas usar 103 Early Hints ainda é mais rápido em quase todos os casos.
Uma resposta 103 Early Hint se parece muito com um cabeçalho de link de preload. Para usar 103 Early Hints, você precisará configurar o seu servidor web ou a sua CDN.
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Algumas CDNs como a Cloudflare permitem acionar um 103 Early Hint simplesmente definindo um cabeçalho de preload de link (conforme descrito no Caso 2). Para um guia completo sobre implementação e suporte nos navegadores, consulte 103 Early Hints: Faça o Preload de Recursos Críticos Durante o Server Think Time.
Em sites monitorados pelo CoreDash, as páginas que usam 103 Early Hints para o seu stylesheet principal mostram um FCP 120ms mais rápido no percentil 75, em comparação com páginas sem Early Hints. A melhoria é mais visível em conexões móveis, onde o tempo de processamento do servidor e a latência da rede se sobrepõem mais.
Caso 4: fazer o preload de stylesheets para obter CSS assíncrono
Um truque bem conhecido para tornar o CSS não bloqueador de renderização é fazer o preload do stylesheet e, assim que ele for carregado, adicioná-lo à página. A ideia é simples e se parece com isso:
<link
rel="preload"
href="style.css"
as="style"
onload="this.onload=null;this.rel='stylesheet'"
> Isto é baseado no código normal de preload <link rel="preload" as="style" href="style.css"> e adiciona um ouvinte de evento onload onload="this.onload=null;this.rel='stylesheet'" que altera o link para a sua forma final <link rel="stylesheet" href="style.css">
Esta é outra ideia que simplesmente faz sentido. Se um stylesheet não for bloqueador de renderização, o navegador pode continuar a fazer o parsing e renderizar a página sem esperar pelo stylesheet. No entanto, tenha cuidado!
- Não torne o CSS assíncrono na viewport visível. Isso provavelmente causará um Cumulative Layout Shift e levará a uma experiência ruim para o usuário.
- Considere as desvantagens. O CSS assíncrono provavelmente causará uma nova renderização de diferentes partes da página. Isso impactará métricas como o Interaction to Next Paint.
Uma alternativa moderna e mais simples é usar fetchpriority="low" em um link de stylesheet comum: <link rel="stylesheet" href="style.css" fetchpriority="low">. Isso diz ao navegador para despriorizar o download sem o hack de JavaScript. Eu recomendo isso em vez do truque do onload para a maioria dos casos de uso.
Caso 5: fazer o pré-cache de stylesheets
Em raras ocasiões, vejo soluções criativas que tentam pré-aquecer arquivos em cache para pageviews subsequentes. E, embora eu aplauda o entusiasmo com o qual 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á fazer o pré-cache dos estilos para outra página. Digamos, a página de produto. Em algum momento após o carregamento da página, você faria o preload dos stylesheets para adicioná-los 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 nada mal. 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 alguns motivos para não fazer isso:
- Existem maneiras melhores, por exemplo, renderização especulativa com Speculation Rules ou usando um service worker.
- Você provavelmente vai desperdiçar recursos e a troca não valerá a pena. Se o preload de recursos fosse fácil, os navegadores seriam melhores nisso.
- Soluções como esta são difíceis de manter e provavelmente causarão problemas em algum momento no futuro.
- Você precisará fazer o preload de todos os stylesheets, não apenas de alguns. Como todos os stylesheets são bloqueadores de renderização e baixados em paralelo, apenas um stylesheet pode ter o mesmo efeito que múltiplos stylesheets.
O que realmente funciona para a performance do CSS
Em vez de recorrer a dicas de preload, concentre-se nestes fundamentos de priorização de recursos:
- Remova o CSS não utilizado e redundante. Arquivos menores baixam mais rápido. Esta é a maior vitória individual para a maioria dos sites.
- Use 103 Early Hints para os seus stylesheets críticos se o seu servidor ou CDN suportar.
Em nossos dados de Real User Monitoring, os sites que removem CSS redundante e usam 103 Early Hints passam consistentemente no LCP no percentil 75. Sites que apenas fazem o preload de seus stylesheets sem abordar a causa raiz (muito CSS, carregado muito tarde) raramente veem melhorias significativas.
Dados em tempo real. Nada de média de 28 dias.
CoreDash segmenta cada métrica por rota, aparelho, browser e tipo de conexão.
Dá uma olhada no CoreDash
