Los recursos bloqueantes del render son archivos CSS o JavaScript que el navegador debe descargar, analizar y ejecutar antes de poder pintar cualquier contenido en pantalla. Mientras esos archivos se procesan, el visitante ve una pantalla en blanco, lo que dispara el tiempo de First Contentful Paint (FCP) y del LCP.
A continuación verás cómo identificarlos y tres técnicas concretas para eliminarlos o reducirlos.
¿Qué hace que un recurso bloquee el render?
El navegador construye el DOM (HTML) y el CSSOM (CSS) antes de poder renderizar nada. Cualquier recurso que interrumpa ese proceso es bloqueante:
- CSS en el
<head>: por defecto, todas las hojas de estilo bloquean el render. El navegador no puede construir el árbol de renderizado sin saber el estilo final de cada elemento. - JavaScript sin
deferniasync: un<script>convencional detiene el parseo del HTML, descarga el archivo y lo ejecuta antes de seguir. - Web fonts con
font-display: block: el texto queda invisible hasta que la fuente llega, aunque esto se considera separado del render-blocking clásico.
Cómo detectar recursos bloqueantes
Con Google Lighthouse / PageSpeed Insights
Abre PageSpeed Insights, pega la URL y busca el apartado "Eliminar los recursos que bloquean el procesamiento". Lighthouse lista cada archivo bloqueante junto con el tiempo estimado de ahorro si se elimina. Es el punto de partida más rápido.
Con Chrome DevTools
Abre DevTools → pestaña Performance → graba una carga. En la sección "Network" de la línea de tiempo, los archivos de color rojo o naranja antes del primer paint son los candidatos a revisar. La pestaña Coverage muestra qué porcentaje de cada CSS o JS no se usa en la carga inicial.
Técnicas para eliminar o reducir el bloqueo
1. Añadir defer o async a los scripts
defer descarga el script en paralelo y lo ejecuta después de que el HTML se ha analizado completamente. async lo descarga en paralelo y lo ejecuta en cuanto llega, sin esperar al HTML.
| Atributo | Descarga | Ejecución | Orden garantizado |
|---|---|---|---|
| ninguno | Bloquea parseo | Inmediata | Sí |
defer |
Paralela | Tras DOMContentLoaded | Sí |
async |
Paralela | En cuanto llega | No |
Para la mayoría de scripts de terceros (analytics, chat, mapas), defer es la opción correcta. Usa async solo para scripts sin dependencias de orden.
2. CSS crítico inline + cargar el resto de forma asíncrona
El CSS crítico es el subconjunto de reglas necesario para renderizar el contenido visible al cargar (above the fold). Si lo insertas inline en el <head>, el navegador puede pintar sin descargar un archivo externo.
El CSS restante se carga de forma no bloqueante con este patrón:
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>Herramientas como Critical (Node) o el plugin de WordPress WP Rocket extraen el CSS crítico automáticamente. Los profesionales de elenlace.com implementan esta técnica como parte de las auditorías de rendimiento para sitios PHP y WordPress.
3. Mover scripts al final del <body>
Si no puedes añadir defer (por ejemplo, scripts heredados que deben ejecutarse en orden), mueverlos justo antes del cierre del </body>. Así el HTML se analiza por completo antes de que los scripts se descarguen y ejecuten.
Puntos clave y verificación posterior
Después de aplicar los cambios, vuelve a correr Lighthouse. El apartado "Eliminar recursos bloqueantes" debe desaparecer o mostrar un ahorro residual mínimo. Comprueba también que:
- El FCP (First Contentful Paint) bajó al menos un 20 %.
- No se rompió ninguna funcionalidad del sitio (formularios, sliders, menús).
- Las fuentes web se cargan con
font-display: swappara evitar texto invisible.
Puedes encontrar más guías sobre optimización en la sección de rendimiento web de nuestro blog.
Conclusiones clave
- Los recursos bloqueantes del render — CSS y JS sin atributos correctos — son una de las causas más frecuentes de FCP y LCP lentos.
- PageSpeed Insights lista los archivos bloqueantes y el ahorro potencial de eliminarlos; úsalo como punto de partida.
- Añade
defera la mayoría de scripts de terceros yasyncsolo a scripts independientes. - Extrae el CSS crítico (above-the-fold) e insértalo inline; carga el resto de forma asíncrona.
- Como último recurso, mueve scripts al final del
<body>. - Verifica siempre tras los cambios: mide FCP/LCP y prueba funcionalidades.
¿Necesitas ayuda para eliminar los recursos bloqueantes de tu sitio? El equipo de elenlace.com audita tu rendimiento y aplica las correcciones de forma profesional.
Preguntas frecuentes
¿Cuál es la diferencia entre defer y async?
Ambos descargan el script en paralelo sin bloquear el parseo del HTML. La diferencia está en la ejecución: defer espera a que todo el HTML se haya analizado y respeta el orden de los scripts; async ejecuta cada script en cuanto llega, sin orden garantizado.
¿Todo el CSS bloquea el render?
Por defecto, sí: cualquier <link rel="stylesheet"> en el <head> bloquea el render. La solución es extraer el CSS crítico e incrustarlo inline, y cargar el CSS no crítico de forma asíncrona con rel="preload".
¿Los recursos bloqueantes afectan el SEO?
Sí. Google mide los Core Web Vitals, especialmente LCP y FCP, para posicionar páginas. Los recursos bloqueantes retrasan ambas métricas directamente. Eliminarlos mejora el rendimiento medido y, con él, el posicionamiento orgánico.
¿Qué pasa si muevo un script y el sitio se rompe?
Significa que ese script tiene una dependencia de orden (por ejemplo, depende de jQuery que se carga antes). En ese caso, usa defer en todos los scripts dependientes en lugar de moverlos; defer preserva el orden de ejecución sin bloquear el render.
Para saber más
Otros proveedores y guías que vale la pena comparar:
