Solucionar la advertencia eliminate render-blocking resources en Lighthouse
Deshazte de los recursos que bloquean el renderizado y mejora los Core Web Vitals
'Eliminate render-blocking resources' en resumen
Cuando un navegador encuentra CSS o JavaScript que bloquea el renderizado (render-blocking) en el <head>, detiene todo. Ningún píxel se pinta hasta que esos recursos terminen de descargarse y ejecutarse. Eso es lo que te dice la advertencia 'Eliminate render-blocking resources' en Lighthouse: algo en tu <head> está retrasando el primer pintado (first paint).
Soluciona esta advertencia de Lighthouse eliminando o difiriendo (deferring) estos recursos que bloquean el renderizado. De acuerdo con el Web Almanac de 2025, solo el 15% de las páginas móviles pasan esta auditoría. Ese es el 85% de la web con retrasos de renderizado innecesarios.
¿Qué es la advertencia de Lighthouse 'Eliminate render-blocking resources'?
Última revisión por Arjen Karel en marzo de 2026
¿Qué causa la advertencia Eliminate render-blocking resources en Lighthouse? Lighthouse señala las páginas que tienen:
- Una etiqueta de script en el head que no está diferida (deferred).
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 los medios del dispositivo (device media).
Un <link rel="stylesheet"> bloqueará el renderizado de la página si no está deshabilitado y coincide con los medios del navegador. Por ejemplo, <link rel="stylesheet" media="print"> no bloqueará el renderizado en dispositivos con pantalla.
Demasiados recursos que bloquean el renderizado probablemente afectarán el First Contentful Paint (FCP) y el Largest Contentful Paint (LCP) directamente. Vodafone redujo el JavaScript que bloquea 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 tercero (third party) que bloquea el renderizado. Solo Google Fonts es responsable de solicitudes de bloqueo de renderizado en más de 5.8 millones de sitios.
¿Qué causa los 'render-blocking resources'?
Los recursos que bloquean el renderizado siempre son hojas de estilo 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 tratar de encontrar el origen de un recurso que bloquea el renderizado, intenta buscar en estos lugares:
- La plantilla (The template). La plantilla de tu sitio web es el primer lugar para buscar. Encuentra el lugar donde se encuentra el código <head> y busca estilos y scripts codificados (hardcoded).
- El CMS. A veces, el propio CMS requiere algunos scripts (por ejemplo, jQuery) para funcionar correctamente.
- Plugins. Los plugins son conocidos 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 de JavaScript del Web Almanac de 2024 (la edición más reciente con datos a nivel de script) descubrió que si bien 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 'Eliminate render-blocking resources'
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 hojas de estilo 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 (defer).
Diferir JavaScript
JavaScript se puede diferir agregando el atributo defer o async a la etiqueta del script.
<!-- deferred: descarga en paralelo, se ejecuta después del análisis (parsing) del HTML, en orden --> <script defer src="script.js"></script> <!-- async: 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 conserva el orden de ejecución. Usa async para scripts que sean completamente independientes, como analíticas (analytics). 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 de JavaScript, consulta 16 métodos para diferir JavaScript. Si quieres entender cómo async y defer afectan a los Core Web Vitals de forma diferente, también tenemos un artículo dedicado a ello.
Diferir hojas de estilo
Diferir las hojas de estilo es más complicado que diferir los scripts. Cuando se difiere una hoja de estilo, la página se renderiza primero sin esos estilos, luego el navegador los aplica una vez cargados. Esto causa parpadeo (flickering) y cambios de diseño (layout shifts). Es por eso que necesitas emparejar hojas de estilo diferidas con CSS crítico en línea (inline).
Paso 1: Pon en línea tu CSS crítico. El CSS crítico es el conjunto mínimo de estilos necesario para renderizar la parte visible de la página. Ponlo en línea directamente en una etiqueta <style> en el <head>. Esto le da al navegador todo lo que necesita para pintar el contenido above-the-fold sin tener que esperar por un archivo externo. Extraer 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 estilo no crítica, agrega 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 antiguos recomendar un truco (hack) con media="print" que cambia a media="all" al cargar (on load). No recomiendo esto. Abusa del atributo media para algo para lo que no fue diseñado, depende de un manejador (handler) onload frágil, y si ese manejador falla, tus estilos nunca se aplicarán. Usar fetchpriority="low" es el enfoque semántico y correcto: le dice al navegador exactamente lo que quieres decir sin trucos.
Para las hojas de estilo que no necesitas en la página actual en absoluto (por ejemplo, estilos usados solo 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 tu CMS podría requerir ciertos scripts. Hay algunas formas de reducir el impacto:
- Minifica y comprime tus estilos y scripts.
Los recursos más pequeños tienen un impacto menor 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 (chaining critical requests).
Si una hoja de estilo que bloquea el renderizado carga otra hoja de estilo mediante@import, has creado una cadena de solicitudes (request chain). El segundo archivo no puede comenzar a descargarse hasta que el primero esté completamente cargado y analizado. Usa etiquetas<link>separadas en su lugar para que ambos se descarguen en paralelo. - Descarga (Unload) recursos por página.
Cuando un recurso no se puede eliminar de una página, eso no significa que sea obligatorio 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 (resource prioritization) 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 mejorar su FCP en [CD:placeholder] ms en promedio.
I have done this before at your scale.
Complex platforms, large dev teams, legacy code. I join your team as a specialist, run the performance track, and hand it back in a state you can maintain.
Discuss Your Situation
