Soluciona la advertencia de Lighthouse 'Eliminar recursos que bloquean el renderizado'
Deshazte de los recursos que bloquean el renderizado y mejora las Core Web Vitals
'Eliminar recursos que bloquean el renderizado' en resumen
Cuando un navegador encuentra CSS o JavaScript que bloquea el renderizado en el <head>, detiene todo. No se pintan píxeles hasta que esos recursos terminan de descargarse y ejecutarse. Eso es lo que te dice la advertencia 'Eliminate render-blocking resources' de Lighthouse: algo en tu <head> está retrasando la primera pintura.
Soluciona esta advertencia de Lighthouse eliminando o difiriendo estos recursos que bloquean el renderizado. Según el Web Almanac de 2025, solo el 15% de las páginas móviles superan esta auditoría. Eso es el 85% de la web con retrasos de renderizado innecesarios.
¿Qué es la advertencia de Lighthouse 'Eliminar recursos que bloquean el renderizado'?
Última revisión por Arjen Karel en marzo de 2026
¿Qué causa la advertencia Eliminate render-blocking resources en Lighthouse? Lighthouse marca las páginas que tienen:
- Una etiqueta de script en el head que no está diferida.
Los scripts en el head de la página bloquean el renderizado por defecto si no tienen el atributo defer o async. - Una hoja de estilos vinculada que coincide con el medio del dispositivo.
Un <link rel="stylesheet"> bloqueará el renderizado de la página si no está deshabilitado y coincide con el medio del navegador. Por ejemplo, <link rel="stylesheet" media="print"> no bloqueará el renderizado en dispositivos de pantalla.
Demasiados recursos que bloquean el renderizado muy probablemente afectarán directamente al First Contentful Paint (FCP) y al Largest Contentful Paint (LCP). Vodafone redujo el JavaScript que bloqueaba el renderizado y vio una mejora del 31% en LCP, lo que se tradujo en un aumento del 8% en las ventas.
Según el Web Performance Calendar, el 67.7% de los sitios web cargan al menos un recurso de terceros que bloquea el renderizado. Solo Google Fonts es responsable de solicitudes que bloquean el renderizado en más de 5.8 millones de sitios.
¿Qué causa los 'recursos que bloquean el renderizado'?
Los recursos que bloquean el renderizado siempre son hojas de estilos y JavaScripts en el head de la página. Esto significa que solo pueden ser agregados por tu CMS, por tu desarrollador web o por un plugin. Al intentar encontrar el origen de un recurso que bloquea el renderizado, intenta buscar en estos lugares:
- La plantilla. La plantilla de tu sitio web es el primer lugar donde buscar. Encuentra el lugar donde se encuentra el código del <head> y busca estilos y scripts codificados de forma rígida (hardcoded).
- El CMS. A veces el propio CMS requiere algunos scripts (por ejemplo, jQuery) para funcionar correctamente.
- Plugins. Los plugins son notorios por inyectar estilos y scripts en la página. Incluso cuando un plugin solo se usa en una página, a menudo carga sus recursos en todas las páginas.
El capítulo sobre JavaScript del Web Almanac de 2024 (la edición más reciente con datos a nivel de script) encontró que, aunque el 87% de las páginas usan async en al menos un script, solo el 49% de las etiquetas de script individuales realmente lo tienen. Y solo el 13% de los scripts usan defer. La mayoría de los scripts en la web todavía se cargan sin ninguno de los atributos, lo que significa que bloquean el renderizado.
Cómo solucionar 'Eliminar recursos que bloquean el renderizado'
Para solucionar los recursos que bloquean el renderizado, debes asegurarte de que ya no bloqueen el renderizado. La mejor solución es eliminar el recurso por completo. Los scripts y las hojas de estilos antiguos y sin usar que todavía están en el <head> son más comunes de lo que crees. Si no puedes eliminarlos, difiérelos.
Diferir JavaScript
El JavaScript se puede diferir agregando el atributo defer o async a la etiqueta del script.
<!-- deferred: se descarga en paralelo, se ejecuta después del análisis HTML, en orden --> <script defer src="script.js"></script> <!-- async: se descarga en paralelo, se ejecuta inmediatamente cuando está listo (en cualquier orden) --> <script async src="script.js"></script>
Para la mayoría de los scripts, defer es la opción más segura porque preserva el orden de ejecución. Usa async para scripts que son completamente independientes, como la analítica. Si usas módulos ES (<script type="module">), obtienes el comportamiento defer automáticamente. Los scripts de módulo nunca bloquean el renderizado.
Para obtener una guía completa sobre todas las formas de controlar el tiempo del JavaScript, consulta 16 métodos para diferir JavaScript. Si quieres entender cómo async y defer afectan a las Core Web Vitals de manera diferente, también tenemos un artículo dedicado a eso.
Diferir hojas de estilos
Diferir las hojas de estilos es más complicado que diferir los scripts. Cuando se difiere una hoja de estilos, la página se renderiza sin esos estilos primero, y luego el navegador los aplica una vez cargados. Esto causa parpadeos y cambios de diseño. Es por eso que necesitas combinar hojas de estilos diferidas con CSS crítico en línea.
Paso 1: Pon en línea tu CSS crítico. El CSS crítico es el conjunto mínimo de estilos necesarios para renderizar la parte visible de la página. Ponlo en línea directamente en una etiqueta <style> dentro del <head>. Esto le da al navegador todo lo que necesita para pintar el contenido above-the-fold sin esperar un archivo externo. Extraer el CSS crítico a mano es tedioso. Puedes usar nuestro Generador de CSS Crítico para automatizar esto.
<style>/* CSS crítico aquí */</style>
Paso 2: Carga el resto con baja prioridad. Para la hoja de estilos no crítica, añade fetchpriority="low" para decirle al navegador que este recurso no debe competir con el contenido crítico:
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
Es posible que veas artículos más antiguos que recomiendan un hack con media="print" que cambia a media="all" al cargar. No recomiendo esto. Abusa del atributo media para algo para lo que no fue diseñado, depende de un manejador onload frágil, y si ese manejador falla, tus estilos nunca se aplicarán. Usar fetchpriority="low" es el enfoque correcto y semántico: le dice al navegador exactamente lo que quieres decir sin trucos.
Para las hojas de estilos que no necesitas en absoluto en la página actual (por ejemplo, estilos que solo se usan en un tipo de página específico), la solución más limpia es eliminar el CSS no utilizado de esa página por completo.
Reduce el impacto de los recursos que bloquean el renderizado
A veces no puedes eliminar los recursos que bloquean el renderizado. Es posible que no tengas acceso a la plantilla o que tu CMS requiera ciertos scripts. Hay algunas formas de reducir el impacto:
- Minifica y comprime tus estilos y scripts.
Los recursos más pequeños tienen un menor impacto en el rendimiento de carga que los recursos más grandes. Asegúrate de que la compresión gzip o brotli esté habilitada en tu servidor. - Evita encadenar solicitudes críticas.
Si una hoja de estilos que bloquea el renderizado carga otra hoja de estilos a través de@import, has creado una cadena de solicitudes. El segundo archivo no puede empezar a descargarse hasta que el primero esté completamente cargado y analizado. En su lugar, usa etiquetas<link>separadas para que ambas se descarguen en paralelo. - Descarga recursos por página.
Cuando un recurso no se puede eliminar de una página, eso no significa que sea necesario en todas las páginas. Los plugins de WordPress tienden a agregar scripts y estilos a todas las páginas, incluso cuando el plugin solo está activo en algunas. - Prioriza lo que importa.
Usa la priorización de recursos para asegurarte de que los recursos críticos se carguen primero y los recursos no críticos no compitan por el ancho de banda.
En los datos de monitoreo de CoreDash, los sitios que eliminaron todos los recursos que bloquean el renderizado vieron que su FCP mejoró en 420 ms en promedio.
Search Console flagged your site?
I deliver a prioritized fix list backed by field data. Not a 50 page PDF.
Request audit
