Cuándo tiene (y cuándo no) sentido precargar hojas de estilo

Por qué precargar tu CSS normalmente no ayuda, y el único caso donde sí lo hace

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

Cuándo tiene (y cuándo no) sentido precargar hojas de estilo

Con frecuencia encuentro hojas de estilo precargadas y mucha desinformación a su alrededor. Precargar un recurso cambia cuándo se programa para su descarga. Pero la mayor parte del tiempo, precargar hojas de estilo no ayuda. En cinco casos te mostraré cuándo funciona y cuándo no.

Última revisión por Arjen Karel en marzo de 2026

La idea de precargar hojas de estilo

Las hojas de estilo bloquean el renderizado. Mientras se descargan las hojas de estilo, la página no será renderizada por el navegador y todo lo que verá el visitante es una pantalla en blanco.

Para minimizar el tiempo que tarda en descargar las hojas de estilo, los desarrolladores a veces recurren a precargarlas. La precarga le dice al navegador que recupere un recurso antes de que lo descubra en el HTML, para que esté listo antes. Esto se hace usando la etiqueta <link> con el atributo rel="preload".

De acuerdo con el Web Almanac de 2025, solo el 13% de las páginas de escritorio aprueban la auditoría de recursos que bloquean el renderizado. Precargar no es la solución. Eliminar recursos innecesarios que bloquean el renderizado y diferir hojas de estilo no críticas sí lo es.

Caso 1: precargar la hoja de estilo justo antes de declararla

A veces los desarrolladores, con todo su entusiasmo, intentan minimizar el impacto del CSS precargándolo en el HTML justo antes de la declaración real del CSS. Esto se verá algo así:

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

Esto no tiene sentido en absoluto y en el mejor de los casos no ralentizarás la página. Los navegadores tienen un escáner de precarga integrado que escanea el HTML en busca de recursos para descargar antes de que el analizador principal los alcance. Si tu <link> de hoja de estilo ya está en el <head>, el escáner de precarga lo encuentra inmediatamente. Añadir una indicación rel="preload" para la misma URL le da al navegador información que ya tiene. Solo añadiste una línea extra, eso es todo.

3 hojas de estilo precargadas

3 hojas de estilo normales

Caso 2: precargar la hoja de estilo con un encabezado link

Esta idea es interesante. Podemos usar el encabezado de servidor Link para precargar una hoja de estilo. Se vería algo así:

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

La idea es hacer que el navegador ponga en cola la hoja de estilo antes de que empiece a analizar el HTML. ¡Me gusta cómo funciona la mente de un desarrollador que pensó en esto! Pero en la vida real obtendrás muy poco beneficio. Estamos hablando de unos pocos microsegundos. Resultados bastante decepcionantes, pero esta idea nos lleva a algo que realmente funciona.

Caso 3: 103 Early Hints para hojas de estilo

Esta es la única idea que realmente te dará resultados de Core Web Vitals. Enviar early hints para hojas de estilo mejorará métricas como el First Contentful Paint y el Largest Contentful Paint.

Los encabezados 103 Early Hint se envían antes de la respuesta HTML real. Eso significa que mientras descargas el HTML, el navegador también puede empezar a descargar hojas de estilo en paralelo. El mejor de los casos es que para cuando el HTML haya terminado de descargarse, las hojas de estilo también se hayan descargado. Cero tiempo de bloqueo de renderizado de esas hojas de estilo. Esto puede suceder y sucede en redes más lentas. En redes más rápidas el efecto es menos obvio, pero usar 103 Early Hints sigue siendo más rápido en casi todos los casos.

Una respuesta 103 Early Hint se ve muy similar a un encabezado link de precarga. Para usar 103 Early Hints necesitarás configurar tu servidor web o tu CDN.

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

Algunas CDNs como Cloudflare te permitirán activar un 103 Early Hint simplemente configurando un encabezado link de precarga (como se describe en el Caso 2). Para una guía completa sobre la implementación y compatibilidad con navegadores, consulta 103 Early Hints: Precargar recursos críticos durante el tiempo de procesamiento del servidor.

En los sitios monitorizados por CoreDash, las páginas que usan 103 Early Hints para su hoja de estilo principal muestran un FCP 120 ms más rápido en el percentil 75 en comparación con las páginas sin Early Hints. La mejora es más visible en conexiones móviles donde el tiempo de procesamiento del servidor y la latencia de la red se superponen más.

Caso 4: precargar hojas de estilo para lograr CSS asíncrono

Un truco bien conocido para hacer que el CSS no bloquee el renderizado es precargar la hoja de estilo y una vez que esté cargada añadirla a la página. La idea es simple y se ve así:

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

Se basa en el código de precarga normal <link rel="preload" as="style" href="style.css"> y añade un detector de eventos onload onload="this.onload=null;this.rel='stylesheet'" que cambia el enlace a su forma final <link rel="stylesheet" href="style.css">

Esta es otra idea que simplemente tiene sentido. Si una hoja de estilo no bloquea el renderizado, el navegador puede continuar analizando y renderizando la página sin esperar a la hoja de estilo. Sin embargo, ¡ten cuidado!

  • No cargues de forma asíncrona el CSS en el viewport visible. Esto probablemente causará un Cumulative Layout Shift y eso conducirá a una mala user experience.
  • Considera la contrapartida. El CSS asíncrono probablemente causará un re-renderizado de diferentes partes de la página. Esto impactará métricas como el Interaction to Next Paint.

Una alternativa moderna más simple es usar fetchpriority="low" en un enlace de hoja de estilo regular: <link rel="stylesheet" href="style.css" fetchpriority="low">. Esto le dice al navegador que le quite prioridad a la descarga sin el truco de JavaScript. Recomiendo esto en lugar del truco de onload para la mayoría de los casos de uso.

Caso 5: pre-cachear hojas de estilo

En raras ocasiones veo soluciones ingeniosas que intentan precalentar archivos de caché para páginas vistas posteriores. Y aunque aplaudo el entusiasmo con el que se hacen esas soluciones: por favor NO hagas esto.

La idea es simple: en la página de inicio podrías, si quisieras, pre-cachear ya los estilos para otra página. Digamos la página de producto. En algún momento después de la carga de la página, precargarías hojas de estilo para añadirlas a la caché del 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');
});

A primera vista esto no se ve nada mal. En cualquier página de producto, cart.css y shop.css ahora están disponibles y ya no bloquearán el renderizado. Hay algunas razones para no hacer esto:

  1. Hay mejores formas, por ejemplo el pre-renderizado especulativo con Speculation Rules o usando un service worker.
  2. Probablemente desperdiciarás recursos y la contrapartida no valdrá la pena. Si precargar recursos fuera fácil, los navegadores habrían sido mejores en ello.
  3. Soluciones como esta son difíciles de mantener y probablemente causarán problemas en algún momento en el futuro.
  4. Necesitarás precargar todas las hojas de estilo, no solo unas pocas. Debido a que todas las hojas de estilo bloquean el renderizado y se descargan en paralelo, una sola hoja de estilo puede tener el mismo efecto que múltiples hojas de estilo.

Lo que realmente funciona para el rendimiento del CSS

En lugar de recurrir a sugerencias de precarga, concéntrate en estos fundamentos de priorización de recursos:

En nuestros datos de Real User Monitoring, los sitios que eliminan CSS redundante y usan 103 Early Hints consistentemente aprueban el LCP en el percentil 75. Los sitios que solo precargan sus hojas de estilo sin abordar la causa raíz (demasiado CSS, cargado demasiado tarde) rara vez ven una mejora significativa.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Find out what is actually slow.

I map your critical rendering path using real field data. You get a clear answer on what blocks LCP, what causes INP spikes, and where layout shifts originate.

Book a Deep Dive
Cuándo tiene (y cuándo no) sentido precargar hojas de estiloCore Web Vitals Cuándo tiene (y cuándo no) sentido precargar hojas de estilo