Recursos que bloquean el renderizado: qué es y cómo funciona

Los recursos que bloquean el renderizado son archivos que el navegador tiene que descargar y procesar antes de poder pintar nada en pantalla. Mientras cargan, el visitante mira una página en blanco, aunque el HTML ya haya llegado.

Qué recursos bloquean el renderizado

• Las hojas de estilo enlazadas en el head. Por defecto, el navegador no pinta hasta tener el CSS, para evitar mostrar contenido sin estilo.
• Los scripts clásicos sin async, defer ni type="module". Estos bloquean el propio analizador de HTML: el navegador deja de construir la página, descarga el script, lo ejecuta y después continúa.
• Las fuentes web, de forma indirecta. El texto con una fuente que no ha cargado puede permanecer invisible hasta tres segundos en la mayoría de los navegadores.

Cada archivo bloqueante añade al menos un viaje de ida y vuelta por la red antes del primer pintado, y en las redes móviles esos viajes son caros. Ese retraso repercute directamente en el Largest Contentful Paint.

Antes y después

<!-- Antes: todo bloquea -->
<link rel="stylesheet" href="/css/all.css">
<script src="/js/slider.js"></script>
<script src="https://tags.example/analytics.js"></script>

<!-- Después -->
<style>/* CSS crítico de la parte visible, unos pocos KB */</style>
<link rel="stylesheet" href="/css/all.css" media="print" onload="this.media='all'">
<script src="/js/slider.js" defer></script>
<script src="https://tags.example/analytics.js" async></script>

Qué ha cambiado:

• defer descarga el script en paralelo y lo ejecuta después del análisis, en el orden del documento: la opción segura por defecto para tus propios scripts (MDN: el elemento script).
• async ejecuta un script en cuanto llega, sin ningún orden concreto: adecuado para etiquetas de terceros independientes.
• Incrustar el CSS crítico permite pintar de inmediato la primera pantalla. Una hoja de estilo cuyo media no coincide, como print, se descarga sin bloquear; el cambio con onload la aplica después a la pantalla.

Errores frecuentes

• Aplazar una biblioteca de la que depende código en línea, lo que provoca errores como «jQuery is not defined».
• Usar async en scripts que dependen entre sí. El orden de ejecución no está garantizado.
• Aplazar todo el CSS, lo que causa un destello de contenido sin estilo y desplazamientos del diseño. Algo tiene que dar estilo a la primera pantalla.
• Fuentes de terceros sin preconnect, que añaden tiempo de DNS y TLS a la ruta crítica.
• Pulir tus propios archivos mientras un banner de consentimiento o un script de pruebas A/B en el head lo bloquea todo. Algunas herramientas de pruebas bloquean a propósito para evitar el parpadeo; sopesa ese coste con honestidad.

Cómo priorizar

Empieza por lo que esté en el <head> y no sea necesario para la primera pantalla. Las etiquetas de terceros suelen ser las victorias más fáciles: muchas no necesitan ejecutarse antes de que el visitante vea algo. Después reduce el CSS que siga bloqueando —las reglas sin usar de un tema o un framework son habituales— para que la ruta crítica lleve solo lo que necesita la primera vista.

Encuéntralos en tu página

La prueba de velocidad de página lista los scripts y las hojas de estilo que bloquean el renderizado en tu página, junto con el número y el peso de scripts y estilos, para que sepas exactamente qué etiquetas aplazar, incrustar o eliminar. Para ver el panorama general, consulta la velocidad de página.

Preguntas frecuentes