Guías

Recursos que bloquean el renderizado: qué bloquea de verdad y por qué async no es la solución

vuetelemetry
Guías
8 min de lectura

Lighthouse nombra la auditoría y lista los ficheros. No explica que un script sin atributo detiene en seco el analizador, que async sigue bloqueando el renderizado al ejecutarse, ni que el CSS bloquea por una razón completamente distinta.

«Eliminar los recursos que bloquean el renderizado» es la auditoría más frecuente de un informe de Lighthouse, y la menos explicada. Nombra los ficheros y ahí se queda. Detrás de esa única línea se esconden dos mecanismos distintos, y necesitan arreglos distintos.

Los scripts: qué hace realmente cada atributo

Personas haciendo cola junto a un bordillo, vistas desde arriba, con marcas viales en el asfalto al lado. Un script que bloquea hace lo mismo con el analizador: todo lo que va detrás espera, por orden, a que termine el de delante.

**Un script clásico sin atributo detiene el analizador.** MDN lo dice sin rodeos: los scripts sin `async`, `defer` ni `type="module"` se *«obtienen y ejecutan inmediatamente, antes de que el navegador continúe analizando la página»*. El navegador está construyendo tu documento, encuentra la etiqueta y se detiene: descargar, ejecutar, y luego seguir. Todo lo que hay debajo espera.

**`defer` es la respuesta la mayoría de las veces.** El atributo indica que el script *«debe ejecutarse después de analizar el documento, pero antes de disparar DOMContentLoaded»*. El análisis continúa sin interrupción, y los scripts diferidos *«se ejecutan en el orden en que aparecen en el documento»*: un script que depende de otro sigue obteniéndolo.

**`async` es el que se usa mal.** Se obtiene *«en paralelo al análisis y se evalúa en cuanto está disponible»*, lo que suena estrictamente mejor. Lo que se omite es la frase siguiente: *«una vez completada la descarga, el script se ejecuta, lo que impide que la página se renderice»*.

Así que async elimina el bloqueo durante la **descarga**, no durante la **ejecución**. Un script grande cargado con async llega cuando llega, en mitad del análisis, y bloquea el renderizado en ese momento. Y como el orden de ejecución sigue al de llegada, MDN advierte de que no hay *«ninguna garantía de que los scripts se ejecuten en un orden concreto»*, lo que rompe cualquier cosa con dependencias.

La regla corta: **defer para tus propios scripts, async solo para terceros realmente independientes**, como una baliza de analítica que no habla con nadie.

El CSS bloquea por otra razón

**El CSS bloquea por otra razón, y el arreglo no es un atributo.** Una hoja de estilos no detiene el analizador de HTML, pero el navegador no pintará hasta tener el CSS que necesita, porque pintar primero y reestilizar después mostraría un destello de contenido sin estilo. Es un bloqueo del renderizado, no del análisis.

Sin atributo: se obtiene y ejecuta de inmediato, el análisis se detiene
defer: se ejecuta tras el análisis, en orden de documento, antes de DOMContentLoaded
async: sin bloqueo en la descarga, pero la ejecución sí bloquea el renderizado, y el orden no está garantizado
CSS: no bloquea el análisis, bloquea la pintura - acota su alcance con media
Las etiquetas de terceros suelen ser la mayor parte de la auditoría

Aquí la palanca es el alcance, no el momento. Una hoja que solo aplica a un contexto puede llevar un atributo `media`, y el navegador la obtendrá sin dejar que bloquee la primera pintura - `media="print"` es el caso conocido. Queda el CSS que la primera pantalla necesita de verdad, y es ese el que conviene mantener pequeño.

- vuetelemetry

Dónde está el peso, y cómo confirmarlo

**Las etiquetas de terceros suelen ser el peso real.** Tu propio bundle está a la vista y acaba optimizado; el gestor de etiquetas, el widget de chat y el banner de consentimiento llegan como scripts que no escribiste, cargando a menudo otros scripts propios. Auditar lo que cuestan de verdad - y si cada uno se lo gana - mueve la cifra mucho más que raspar kilobytes de tu código.

**Y luego mide en campo, no en el informe.** Lighthouse te dice que un recurso bloqueaba el renderizado; no te dice si quitarlo cambió algo para tus visitantes. Esa diferencia entre una auditoría de laboratorio y usuarios reales es [un tema en sí mismo](/es/articles/datos-de-campo-vs-datos-de-laboratorio), y es la que decide si el trabajo mereció la pena.

FAQ

¿Qué significa «eliminar los recursos que bloquean el renderizado»?

Es una auditoría de Lighthouse que lista scripts y hojas de estilo que retrasan la primera pintura. Detrás hay dos mecanismos distintos: un script clásico sin atributo detiene por completo el analizador de HTML, mientras que una hoja de estilos deja continuar el análisis pero impide pintar hasta cargarse. Necesitan arreglos distintos, por eso la auditoría por sí sola no basta para actuar.

¿Debo usar async o defer?

defer para tus propios scripts, async solo para terceros realmente independientes. defer se ejecuta tras el análisis, en orden de documento, así que las dependencias siguen funcionando. async se ejecuta en cuanto termina la descarga, lo que bloquea el renderizado en ese instante, y MDN advierte de que no hay garantía sobre el orden de ejecución.

¿async hace que un script no bloquee?

No del todo, y es la lectura errónea habitual. async elimina el bloqueo durante la descarga: el script se obtiene en paralelo al análisis. Pero MDN indica que, una vez completada la descarga, el script se ejecuta y esa ejecución impide que la página se renderice. Un script async grande simplemente bloquea en un momento impredecible en lugar de uno predecible.

¿Por qué bloquea el CSS el renderizado?

Porque pintar antes de que llegue la hoja de estilos mostraría contenido sin estilo y habría que rehacerlo. Así que el navegador espera. A diferencia de un script, el CSS no detiene el analizador de HTML: detiene la pintura. El arreglo no es un atributo sino el alcance - una hoja limitada por un atributo media se obtiene sin retener la primera pintura.

¿Cómo sé si el arreglo sirvió?

No por el informe de Lighthouse, que solo te dice que un recurso bloqueaba el renderizado. Si el cambio llegó a tus visitantes se ve en los datos de campo, en el percentil 75 sobre 28 días. Una auditoría de laboratorio identifica al candidato; solo el campo confirma el resultado.