01Qué es y cómo funciona
Cuando un navegador carga una página, construye un DOM a partir del HTML y un CSSOM a partir de las hojas de estilo. Si una etiqueta ` está en el sin defer o async, el navegador pausa el análisis del HTML para descargarla y ejecutarla. Del mismo modo, un ` bloquea el renderizado porque el navegador necesita el CSSOM para pintar. Cuantos más render-blocking resources tengas, más tiempo pasará el usuario mirando una pantalla en blanco. Lighthouse de Google marca estos recursos y mide su impacto en el First Contentful Paint (FCP) y el Largest Contentful Paint (LCP).
Render-blocking resources son scripts y hojas de estilo que impiden que el navegador muestre el contenido hasta que terminan de cargarse. Eliminarlos o posponer su carga hace que las páginas aparezcan más rápido.
02Qué hacer al respecto
Puedes reducir o eliminar los Render-blocking resources con unos pocos pasos prácticos. Inserta el CSS crítico —los estilos necesarios para el contenido above-the-fold— directamente en el `. Carga el CSS no crítico usando atributos media o preload con onload. Para JavaScript, añade defer o async a las etiquetas , o mueve los scripts al final del `. Divide tus paquetes de JavaScript para que solo se cargue primero el código esencial. Utiliza herramientas como Lighthouse o PageSpeed Insights para identificar qué recursos bloquean el renderizado y luego aplica estas correcciones. Para WordPress, considera un plugin de rendimiento que gestione automáticamente el CSS crítico y el diferimiento de scripts.
03Cómo se mide
Lighthouse y PageSpeed Insights informan sobre una auditoría específica llamada "Eliminate render-blocking resources". Esta enumera cada URL que bloquea y el tiempo estimado que se ahorraría al diferirla o integrarla (inline). La métrica está vinculada al FCP y al LCP en las Core Web Vitals. También puedes usar el panel Performance de Chrome DevTools: graba la carga de una página, observa la pista "Main" y comprueba dónde se detiene el navegador en una hoja de estilo o un script. La pestaña Network muestra qué recursos se solicitan antes del primer evento de pintado (first paint). El informe de Core Web Vitals de Google Search Console marcará las páginas con un LCP deficiente, a menudo causado por scripts que bloquean el renderizado.
04Errores comunes
- Diferir todo el JavaScript, incluidos los scripts que deben ejecutarse antes de que la página sea interactiva; esto retrasa el time-to-interactive.
- Incluir en línea archivos CSS enormes, lo que aumenta el tamaño del HTML y puede afectar el rendimiento en conexiones lentas.
- Usar
asyncpara scripts que dependen de otros scripts, lo que provoca condiciones de carrera y fallos en la funcionalidad. - Olvidar eliminar el CSS o JavaScript que no se utiliza: el código muerto sigue bloqueando el renderizado.
- Precargar todos los recursos en lugar de solo los críticos, lo que desperdicia ancho de banda y retrasa los activos realmente críticos.
05Límites y confusiones
No todos los recursos son render-blocking. Las imágenes, los vídeos y las fuentes cargadas mediante ` o @font-face no bloquean el renderizado (aunque afectan al LCP). Los scripts con async o defer` no bloquean el análisis (parsing). Además, render-blocking no es lo mismo que "render-delaying": una imagen grande puede retrasar el LCP sin bloquear el primer pintado (first paint). Y un recurso puede estar marcado como render-blocking pero tener un impacto mínimo si es pequeño o está en caché. La estimación de tiempo ahorrado de la auditoría es un escenario ideal, no una garantía. Por último, los render-blocking resources son un problema de rendimiento, no un factor de posicionamiento directo: afectan al posicionamiento indirectamente a través de las Core Web Vitals.
06Ejemplo práctico
Supongamos que tu página de inicio tiene un<link rel="stylesheet" href="styles.css">y un<script src="app.js"></script>en el<head>. Lighthouse dice que styles.css ahorra 0.8s y app.js ahorra 0.5s si se carga de forma diferida. Inluyes el CSS crítico (los estilos del encabezado y del hero) en una etiqueta<style>, y luego cargas el resto de styles.css conmedia="print" onload="this.media='all'". Añadesdefera app.js. Tras el cambio, el FCP baja de 2.1s a 1.3s, y tu LCP mejora de 3.4s a 2.2s. La página ahora supera el umbral de Core Web Vitals para móviles.
07Preguntas frecuentes
¿Cuál es la diferencia entre los Render-blocking resources y los recursos que no bloquean el renderizado?
Los Render-blocking resources deben descargarse y analizarse antes de que el navegador pueda renderizar, mientras que los recursos que no bloquean el renderizado, como las imágenes o los scripts asíncronos, no retrasan la primera pintura (initial paint). La diferencia clave es si el navegador pausa el renderizado mientras se carga el recurso. En la práctica, el CSS suele ser render-blocking, mientras que el JavaScript puede hacerse no bloqueante mediante async o defer.
¿Debería eliminar todos los Render-blocking resources?
No, no todos. Debes eliminar o posponer los recursos que no sean críticos para el contenido inicial, como el JavaScript no esencial, pero parte del CSS es necesario para dar estilo a la página. El objetivo es incluir el CSS crítico de forma directa (inline) y posponer el resto, equilibrando la velocidad con la funcionalidad.
¿Cómo puedo incluir de forma directa (inline) JavaScript que sea render-blocking?
No incluyas JavaScript en línea; en su lugar, cárgalo con el atributo defer o usa async cuando sea apropiado. Para CSS, puedes incluir los estilos críticos directamente en el HTML e incluir el resto mediante media="print" o técnicas de preload. Herramientas como Lighthouse proporcionan recomendaciones específicas para cada URL que bloquea el renderizado.
¿Corregir los Render-blocking resources mejora mi posicionamiento en buscadores?
Sí, indirectamente. Los Render-blocking resources retrasan el first contentful paint, que es un Core Web Vital que Google utiliza como factor de posicionamiento. Reducirlos mejora la velocidad de la página y puede impulsar tu posicionamiento, especialmente en dispositivos móviles. Sin embargo, es uno de tantos factores, por lo que el impacto varía.
¿Qué pasa si no corrijo los Render-blocking resources?
Tu página tendrá un first paint más lento, lo que provocará una mayor tasa de rebote y una peor experiencia de usuario. Con el tiempo, esto puede perjudicar tu posicionamiento en buscadores y hacer que tu sitio luzca mal en las auditorías de rendimiento. También verás puntuaciones bajas en Lighthouse, lo que puede ser una preocupación para clientes o stakeholders.
¿Cuánto tiempo se tarda en ver mejoras tras corregir los Render-blocking resources?
Verás mejoras inmediatas en tus puntuaciones de Lighthouse y PageSpeed Insights una vez que implementes los cambios. Para el posicionamiento en buscadores, depende de la frecuencia con la que Google rastree tu sitio, pero podrías notar cambios en pocas semanas. Monitorea tus Core Web Vitals en Google Search Console para seguir el progreso.
08Preguntado en voz alta
El mismo término en las palabras que alguien usa al hablar con un asistente en lugar de escribir en un buscador: escrito desde la situación, y por eso cada pregunta lleva la situación de la que salió.
Probablemente se deba a render-blocking resources. Se trata de archivos como CSS y JavaScript que el navegador debe descargar antes de poder renderizar la página. Puedes solucionarlo haciendo inline del CSS crítico y posponiendo (deferring) los scripts no esenciales.
Se trata de la auditoría de render-blocking resources. Enumera URLs específicas que están ralentizando tu first paint. Puedes solucionarlo posponiendo esos scripts o haciendo inline del CSS crítico; el informe incluso te muestra cuánto tiempo ahorrarás.
Lo primero es buscar render-blocking resources. Son la causa más común de un first paint lento y son fáciles de solucionar. Realiza una prueba de PageSpeed y revisa la auditoría "Eliminate render-blocking resources" para ver exactamente qué está frenando la página.