Los recursos que bloquean el renderizado son archivos CSS o JavaScript que el navegador debe descargar y procesar antes de poder mostrar cualquier contenido en pantalla. Mientras esos archivos no terminen de cargarse, el usuario ve una página en blanco — incluso si el servidor respondió rápido.
A continuación encontrarás qué son exactamente, por qué sucede y las técnicas paso a paso para eliminar o minimizar su impacto.
Cómo funciona el renderizado del navegador
Para entender el problema, conviene tener claro el proceso de construcción de la página:
- El navegador descarga el HTML y lo parsea para construir el DOM (Document Object Model).
- Cuando encuentra una hoja de estilos (
<link rel="stylesheet">), descarga el CSS y construye el CSSOM. - Combina DOM + CSSOM para crear el Render Tree.
- Solo con el Render Tree completo puede calcular posiciones (layout) y pintar píxeles en pantalla.
Si en el paso 2 el navegador encuentra también un <script> sin atributos especiales, detiene el parseo del HTML hasta que ese script se descargue y ejecute. Resultado: pantalla en blanco y usuario esperando.
Qué tipos de recursos pueden bloquear el renderizado
CSS en el <head>
Cualquier hoja de estilos enlazada en el <head> bloquea el renderizado por definición: el navegador la necesita antes de pintar nada para evitar el "destello" de contenido sin estilo (FOUC). El problema no es la etiqueta en sí — es cargar CSS no crítico de esta forma.
JavaScript sin async ni defer
Un <script src="..."> colocado en el <head> o en el <body> sin los atributos async o defer detiene el parseo del HTML hasta que el archivo se descarga, parsea y ejecuta. Es el caso más común y el más fácil de corregir.
Fonts externas con preload inadecuado
Google Fonts y otras fuentes web referenciadas con @import dentro del CSS añaden una solicitud extra en la cadena crítica, retrasando el momento en que el navegador puede renderizar texto.
Cómo detectar recursos bloqueantes
Hay tres formas rápidas de identificarlos:
- Google PageSpeed Insights: en el apartado "Oportunidades" aparece "Eliminar recursos que bloquean el renderizado" con la lista exacta de archivos y el tiempo estimado de ahorro.
- Chrome DevTools → Performance: graba la carga de la página y observa el hilo principal. Los bloques en rojo/naranja al inicio indican tareas que pausan el renderizado.
- GTmetrix → Waterfall: los recursos marcados en el tramo previo al First Contentful Paint que tienen una barra de color bloqueante son los culpables.
Revisar los resultados de auditorías de rendimiento web con estas herramientas es el primer paso antes de cualquier optimización.
Cómo evitar o reducir el bloqueo del renderizado
1. Usa defer o async en los scripts
Estos dos atributos le indican al navegador que no detenga el parseo del HTML mientras descarga el script:
defer: descarga el script en paralelo y lo ejecuta después de que el HTML haya sido completamente parseado. Respeta el orden entre scripts. Recomendado para la mayoría de los casos.async: descarga en paralelo y ejecuta en cuanto termina, sin esperar al HTML ni a otros scripts. Ideal para scripts independientes como analítica.
<!-- En lugar de esto: -->
<script src="main.js"></script>
<!-- Usa esto: -->
<script src="main.js" defer></script>
2. Inline del CSS crítico
El CSS crítico es el mínimo de estilos necesario para renderizar lo que el usuario ve sin hacer scroll (above the fold). Si lo incluyes en el propio HTML con una etiqueta <style>, el navegador puede pintar esa zona sin esperar a que cargue la hoja de estilos completa.
El resto del CSS se carga de forma diferida:
<!-- CSS crítico inline -->
<style>
/* estilos mínimos del header, hero, fuentes base */
</style>
<!-- CSS completo cargado de forma no bloqueante -->
<link rel="preload" href="styles.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>
3. Carga diferida de fuentes web
Evita @import url() para Google Fonts dentro del CSS. En su lugar, usa la etiqueta <link> con rel="preconnect" para establecer la conexión anticipada y display=swap para que el texto se muestre con una fuente local mientras llega la fuente web:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter&display=swap"
rel="stylesheet">
4. Divide y carga solo lo necesario
Si tu sitio carga un archivo CSS con miles de líneas de estilos para todas las páginas, la mayor parte bloquea para nada. Opciones:
- Divide el CSS por secciones y carga el específico de cada página.
- Elimina CSS muerto con herramientas como PurgeCSS o UnCSS.
- Divide el JS en chunks con code splitting (webpack, Vite) y carga solo lo que necesita cada vista.
5. Mueve los scripts al final del <body>
Si no puedes agregar defer o async (por ejemplo, scripts de terceros embebidos con una etiqueta que no controlas), moverlos justo antes de </body> reduce el impacto: el HTML ya estará parseado cuando se encuentren.
Impacto real: qué métricas mejoran
Eliminar recursos bloqueantes afecta directamente:
| Métrica | Por qué mejora |
|---|---|
| FCP (First Contentful Paint) | El navegador puede pintar el primer contenido sin esperar scripts ni CSS no crítico. |
| LCP (Largest Contentful Paint) | Al arrancar el renderizado antes, el elemento visual principal aparece antes. |
| TBT (Total Blocking Time) | Menos scripts ejecutándose en el hilo principal durante la carga = menos tareas largas. |
| Puntuación PageSpeed | Esta oportunidad suele estar entre las de mayor ahorro en tiempo en sitios sin optimizar. |
Un equipo con experiencia en rendimiento como el de elenlace.com puede identificar todos los recursos bloqueantes de tu sitio y aplicar las correcciones correctas sin romper la funcionalidad.
Conclusiones clave
- Los recursos que bloquean el renderizado son CSS y JS que impiden al navegador mostrar contenido hasta que terminan de procesarse.
- El problema más común: scripts en el
<head>sindeferniasync. - La solución para JS es simple: añadir
defera casi todos los scripts que no sean críticos para el primer render. - Para CSS: extraer el CSS crítico como inline y diferir el resto.
- Las métricas que mejoran directamente son FCP, LCP y TBT — todas visibles en PageSpeed Insights.
Si PageSpeed Insights te señala esta oportunidad, no la ignores: suele ser uno de los cambios con mayor retorno de inversión en optimización web. Habla con nuestro equipo en elenlace.com para una revisión técnica completa de tu sitio.
Preguntas frecuentes
¿Debo poner defer en todos los scripts?
En la gran mayoría sí. La excepción son scripts que deben ejecutarse antes de que el DOM esté disponible (muy raros) o scripts de los que depende otro script inline en el <head>. Si un script no tiene esa dependencia, defer es seguro y recomendable.
¿El CSS siempre bloquea el renderizado?
El CSS enlazado en el <head> sí bloquea, porque el navegador lo necesita para construir el Render Tree. La forma de mitigarlo es extraer el CSS crítico (lo que se ve sin scroll) como inline y diferir el resto, no eliminar el CSS por completo.
¿Plugins de WordPress como WP Rocket o W3 Total Cache solucionan esto automáticamente?
Parcialmente. Plugins de optimización pueden agregar defer automáticamente y generar CSS crítico, pero a veces rompen scripts que necesitan un orden específico. Siempre prueba en staging antes de activar estas opciones en producción.
¿Cuánto tiempo tarda en notarse la mejora en PageSpeed?
Los datos de laboratorio (Lighthouse) cambian de inmediato tras aplicar las correcciones. Los datos de campo (CrUX) en Search Console tardan 28 días en reflejar el cambio, ya que son un promedio rodante del último mes.
Compara proveedores
Otros proveedores y guías que vale la pena comparar:
