Que son los recursos que bloquean el renderizado y por que importan
Cuando el navegador carga tu página, lee el código HTML linea por linea. Cuando encuentra una etiqueta <script src="archivo-pesado.js"> o <link rel="stylesheet">, detiene todo lo demas, descarga ese archivo y lo ejecuta. Solo entonces continua renderizando el resto de la página. Esto es lo que se conoce como “render-blocking” o bloqueo de renderizado.
Descubre nuestros servicios de optimización de velocidad WordPress en WPPoland.
En 2026, con las metricas de Core Web Vitals como factor de posicionamiento en Google, especialmente LCP (Largest Contentful Paint) e INP (Interaction to Next Paint), resolver los problemas de recursos que bloquean el renderizado es una de las optimizaciones técnicas de mayor impacto que puedes implementar.
El aviso de PageSpeed Insights que dice “Eliminar los recursos que bloquean el renderizado” es uno de los más frecuentes y, al mismo tiempo, uno de los que más confunden a los propietarios de sitios WordPress. Este artículo explica exactamente que significa, por que ocurre y como resolverlo paso a paso.
Como funciona el renderizado en el navegador
Para entender por que ciertos recursos bloquean el renderizado, necesitas comprender como el navegador construye una página web:
El proceso de construccion del DOM
- Descarga del HTML. El navegador descarga el documento HTML del servidor.
- Parsing del HTML. El parser recorre el HTML linea por linea, construyendo el DOM (Document Object Model), que es la estructura en arbol de la página.
- Encuentro con CSS. Cuando el parser encuentra una etiqueta
<link rel="stylesheet">, necesita descargar y procesar ese archivo CSS para construir el CSSOM (CSS Object Model). Mientras tanto, el renderizado se detiene porque el navegador necesita los estilos para saber como pintar los elementos. - Encuentro con JS. Cuando el parser encuentra una etiqueta
<script src="...">, se detiene completamente. Descarga el archivo JavaScript, lo parsea y lo ejecuta. Solo despues continua con el HTML restante. Esto ocurre porque el JavaScript podria modificar el DOM que se esta construyendo. - Render Tree. Solo cuando el DOM y el CSSOM estan listos, el navegador puede combinarlos en el Render Tree y pintar la página.
Cada archivo CSS o JavaScript en el <head> de tu página que no tenga atributos especiales bloquea este proceso. Si tienes 5 archivos CSS y 8 archivos JavaScript en el head, el navegador tiene que descargar, parsear y ejecutar los 13 antes de mostrar un solo pixel al usuario.
Impacto en Core Web Vitals
El bloqueo de renderizado afecta directamente a dos metricas criticas:
FCP (First Contentful Paint): El momento en que el navegador pinta el primer contenido (texto, imagen, SVG). Cuantos más recursos bloqueen el renderizado, más tarda en ocurrir el primer pintado. El objetivo es un FCP inferior a 1.8 segundos.
LCP (Largest Contentful Paint): El momento en que se renderiza el elemento más grande visible en la pantalla. Si un archivo CSS pesado impide que el navegador pinte la imagen hero o el bloque de texto principal, el LCP se dispara. El objetivo es un LCP inferior a 2.5 segundos.
Un sitio WordPress tipico con un tema de page builder, 20 plugins y sin optimizar puede tener entre 15 y 30 archivos CSS y JavaScript cargados en el head. Esto significa que el visitante ve una pantalla en blanco durante 3 a 8 segundos mientras el navegador procesa todos estos recursos. En móvil, con conexiónes más lentas, este tiempo puede duplicarse fácilmente.
JavaScript: async y defer explicados en profundidad
La vieja escuela decia “pon los scripts en el footer (wp_footer)”. La nueva escuela dice “usa atributos”. Ambas estrategias buscan lo mismo: evitar que los scripts bloqueen el parsing del HTML. Pero los atributos ofrecen un control más fino.
Script normal (sin atributos)
<script src="archivo.js"></script>El parser HTML se detiene. Descarga el archivo. Lo ejecuta. Solo entonces continua con el HTML. Esto es el maximo bloqueo posible.
Script con async
<script async src="archivo.js"></script>El archivo se descarga en segundo plano mientras el parser continua con el HTML. Sin embargo, en cuanto la descarga termina, el parser se detiene para ejecutar el script. Esto significa que el momento de la ejecucion es impredecible y depende de la velocidad de descarga.
Cuando usar async:
- Scripts de analítica (Google Analytics, Matomo).
- Pixels de seguimiento (Facebook Pixel, Google Ads).
- Scripts que no dependen de otros scripts ni del DOM.
Cuando NO usar async:
- Scripts que dependen de jQuery u otra libreria.
- Scripts que manipulan elementos del DOM que aun no se han cargado.
- Scripts que tienen dependencias de orden de ejecucion entre si.
Script con defer
<script defer src="archivo.js"></script>El archivo se descarga en segundo plano mientras el parser continua con el HTML. Pero a diferencia de async, la ejecucion se pospone hasta que el HTML esta completamente parseado. Además, los scripts con defer se ejecutan en el orden en que aparecen en el HTML.
Cuando usar defer:
- La mayoria de scripts de WordPress (es la opción segura por defecto).
- Scripts que dependen del DOM.
- Scripts con dependencias entre si (ya que se ejecutan en orden).
- Plugins de WordPress que cargan su JS en el head.
Como anadir defer en WordPress
La forma más directa es usar un plugin de cache/optimización. WP Rocket, Autoptimize y LiteSpeed Cache tienen una opción “Defer JS” que aplica el atributo automáticamente a todos los scripts. Activarla resuelve el 90% de los problemas de JavaScript bloqueante.
Si prefieres una solución manual sin plugins adicionales, puedes usar un filtro en functions.php:
function add_defer_to_scripts($tag, $handle, $src) {
// No aplicar a scripts criticos que necesiten ejecutarse inmediatamente
$exclude = array('jquery-core', 'wp-polyfill');
if (in_array($handle, $exclude)) {
return $tag;
}
// Anadir defer si el script no tiene ya async o defer
if (strpos($tag, 'defer') === false && strpos($tag, 'async') === false) {
$tag = str_replace(' src=', ' defer src=', $tag);
}
return $tag;
}
add_filter('script_loader_tag', 'add_defer_to_scripts', 10, 3);Este filtro anade el atributo defer a todos los scripts excepto jQuery core y otros scripts críticos que necesitan ejecutarse inmediatamente. La lista de exclusiones debe ajustarse según los requisitos de tu sitio.
Mover scripts al footer programaticamente
Además de defer, puedes mover scripts que se cargan en el head al footer usando WordPress:
function move_scripts_to_footer() {
// Mover scripts no criticos al footer
wp_deregister_script('contact-form-7');
wp_register_script('contact-form-7', '/ruta/al/script.js', array(), null, true);
}
add_action('wp_enqueue_scripts', 'move_scripts_to_footer', 100);El parametro true al final de wp_register_script indica a WordPress que cargue el script en el footer en lugar del head.
CSS: Critical CSS, la solución al bloqueo de estilos
El CSS es más complejo que el JavaScript en lo que respecta al bloqueo de renderizado. No puedes simplemente “retrasar” la carga de CSS porque la página se mostraria como texto sin formato durante un momento, creando el efecto FOUC (Flash of Unstyled Content), que es una experiencia de usuario terrible.
Que es Critical CSS
Critical CSS es la técnica de extraer solo los estilos necesarios para renderizar el contenido “above the fold” (lo visible sin hacer scroll) e incrustarlo directamente en el HTML, mientras el resto del CSS se carga de forma asincrona en segundo plano.
El proceso funciona asi:
- Identificar los estilos críticos. Analizar que reglas CSS son necesarias para renderizar correctamente la parte visible de la página sin scroll.
- Incrustar los estilos críticos inline. Pegar esos estilos dentro de una etiqueta
<style>en el<head>del HTML, eliminando la necesidad de descargar un archivo CSS externo antes de pintar. - Cargar el CSS completo de forma asincrona. El resto del CSS (estilos del footer, secciones inferiores, modals, etc.) se carga en segundo plano y se aplica cuando este listo.
Implementación manual de Critical CSS
Para un sitio simple, puedes generar Critical CSS manualmente:
<head>
<!-- Critical CSS inline: solo estilos del above the fold -->
<style>
body { font-family: system-ui, sans-serif; margin: 0; }
.header { background: #1a1a2e; color: white; padding: 1rem; }
.hero { padding: 3rem 1rem; max-width: 1200px; margin: 0 auto; }
.hero h1 { font-size: 2.5rem; line-height: 1.2; }
/* ... solo los estilos necesarios para la parte visible */
</style>
<!-- CSS completo cargado de forma asincrona -->
<link rel="preload" href="/styles/main.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles/main.css"></noscript>
</head>El patron preload con onload es la técnica estándar para cargar CSS de forma asincrona. El <noscript> fallback asegura que la hoja de estilos completa se cargue normalmente si JavaScript esta deshabilitado.
Critical CSS con plugins de WordPress
La mayoria de los plugins de optimización modernos generan Critical CSS automáticamente:
WP Rocket: Genera Critical CSS automáticamente para cada página. Es la solución más completa y requiere minima configuración. Al activar la opción “Optimizar la entrega de CSS”, el plugin analiza cada página, extrae los estilos críticos y los incrusta inline.
Autoptimize + CriticalCSS.com: Autoptimize puede integrarse con el servicio CriticalCSS.com para generar Critical CSS automáticamente. Requiere una API key pero el proceso es completamente automático.
LiteSpeed Cache: Si tu servidor usa LiteSpeed, este plugin genera Critical CSS de forma nativa con excelente rendimiento, ya que se integra directamente con el servidor web.
Perfmatters: Un plugin ligero que permite cargar CSS de forma condicional por página, eliminar CSS no utilizado y generar Critical CSS.
Eliminar CSS no utilizado
Además del Critical CSS, otra optimización importante es eliminar el CSS que no se usa en cada página. Un sitio WordPress tipico carga entre 200 KB y 1 MB de CSS en cada página, pero cada página individual solo necesita entre un 10% y un 30% de esos estilos.
Herramientas como PurgeCSS, UnCSS o las funcionalidades integradas de WP Rocket pueden analizar que selectores CSS se usan realmente en cada página y eliminar el resto. Esto reduce dramaticamente el tamaño de los archivos CSS que el navegador tiene que descargar y parsear.
En WordPress, puedes desencolar las hojas de estilo de plugins que no se usan en determinadas páginas:
function remove_unused_css() {
// No cargar los estilos de WooCommerce en páginas que no son de tienda
if (!is_woocommerce() && !is_cart() && !is_checkout()) {
wp_dequeue_style('woocommerce-general');
wp_dequeue_style('woocommerce-layout');
wp_dequeue_style('woocommerce-smallscreen');
}
// No cargar los estilos de Contact Form 7 excepto en la página de contacto
if (!is_page('contacto')) {
wp_dequeue_style('contact-form-7');
}
}
add_action('wp_enqueue_scripts', 'remove_unused_css', 100);Optimización de fuentes web
Las fuentes web son otro recurso frecuente que bloquea el renderizado. Cuando el navegador encuentra una declaracion @font-face en el CSS, necesita descargar el archivo de fuente antes de poder pintar el texto. Esto crea un retraso visible que afecta tanto al FCP como al LCP.
font-display: swap
La propiedad CSS font-display: swap indica al navegador que muestre el texto inmediatamente con una fuente del sistema (fallback) mientras la fuente web se descarga en segundo plano. Cuando la fuente web esta lista, el navegador la intercambia automáticamente.
@font-face {
font-family: 'MiFuente';
src: url('/fonts/mi-fuente.woff2') format('woff2');
font-display: swap;
}Esto elimina el periodo de texto invisible (FOIT, Flash of Invisible Text) y mejora significativamente el FCP.
Precargar fuentes criticas
Para las fuentes que se usan en el above the fold, anade una etiqueta de preload en el head:
<link rel="preload" href="/fonts/mi-fuente.woff2" as="font" type="font/woff2" crossorigin>El atributo crossorigin es necesario incluso cuando las fuentes se sirven desde tu propio dominio, debido a como los navegadores manejan las peticiones de fuentes.
Alojar fuentes localmente en lugar de Google Fonts
Google Fonts es la fuente de fuentes web más popular, pero tiene implicaciones de rendimiento y privacidad:
Rendimiento: Cargar fuentes de Google requiere conexiónes DNS adicionales, handshakes TLS y peticiones HTTP al CDN de Google. Alojar las fuentes localmente elimina toda esta latencia.
Privacidad (RGPD): Google Fonts transmite la dirección IP del visitante a servidores de Google, lo que ha sido declarado ilegal en varios paises de la UE sin consentimiento previo del usuario.
Para alojar Google Fonts localmente:
- Descarga los archivos de fuente desde google-webfonts-helper.herokuapp.com o directamente del repositorio de Google Fonts.
- Sube los archivos WOFF2 a tu servidor (WOFF2 ofrece la mejor compresion).
- Actualiza las declaraciones
@font-faceen tu CSS para apuntar a los archivos locales. - Elimina las referencias a fonts.googleapis.com y fonts.gstatic.com de tu HTML.
En WordPress, el plugin OMGF (Optimize My Google Fonts) automatiza este proceso completamente.
Minificacion y combinación de archivos
Minificacion
La minificacion elimina espacios en blanco, comentarios y caracteres innecesarios de los archivos CSS y JavaScript sin cambiar su funcionalidad. Un archivo CSS de 100 KB puede reducirse a 70 KB despues de la minificacion. Multiplicado por 10 archivos, el ahorro es significativo.
En WordPress, la minificacion se gestiona tipicamente con plugins de cache:
- WP Rocket: Minifica CSS y JS automáticamente con una casilla.
- Autoptimize: Especializado en minificacion y combinación de archivos.
- LiteSpeed Cache: Incluye minificacion integrada.
Combinación de archivos
Combinar multiples archivos CSS en uno (y multiples archivos JS en uno) reduce el número de peticiones HTTP. Sin embargo, en 2026 con HTTP/2 y HTTP/3, la combinación de archivos es menos crítica que antes, ya que estos protocolos permiten multiples descargas simultaneas sobre una sola conexión.
La combinación puede incluso ser contraproducente si invalida la cache con demasiada frecuencia. Si combinas 15 archivos CSS en uno y cambias una sola linea en un plugin, todo el archivo combinado necesita re-descargarse. Con archivos separados, solo el archivo modificado necesita actualizarse.
La recomendación actual es minificar siempre, pero combinar solo cuando el sitio todavia usa HTTP/1.1 o cuando el número de archivos es excesivo (más de 30 peticiones CSS o JS).
Estrategia de priorizacion de recursos
Además de async, defer y Critical CSS, los navegadores modernos soportan directivas de priorizacion que permiten indicar que recursos son críticos y cuales pueden esperar:
Preload
<link rel="preload" href="/critical-script.js" as="script">
<link rel="preload" href="/hero-image.webp" as="image">Preload indica al navegador que descargue un recurso lo antes posible, antes de que lo descubra naturalmente durante el parsing del HTML. Usalo para recursos críticos como la imagen LCP, la fuente principal o un script esencial.
Prefetch
<link rel="prefetch" href="/página-siguiente.html">
<link rel="prefetch" href="/estilos-página2.css">Prefetch indica al navegador que descargue un recurso con baja prioridad durante el tiempo libre, anticipando que el usuario lo necesitara pronto. Es útil para precargar recursos de la siguiente página probable de navegación.
Fetchpriority
<img src="/hero.webp" fetchpriority="high">
<img src="/decorativa.webp" fetchpriority="low">El atributo fetchpriority permite ajustar la prioridad de descarga de recursos individuales. Usalo para aumentar la prioridad de la imagen LCP y reducir la de imágenes decorativas o fuera de pantalla.
Diagnostico: como identificar recursos bloqueantes
Usando PageSpeed Insights
PageSpeed Insights lista los recursos que bloquean el renderizado en la sección “Oportunidades” bajo “Eliminar los recursos que bloquean el renderizado”. Cada recurso listado muestra:
- El URL del archivo.
- El tamaño del archivo.
- El ahorro potencial en milisegundos.
Esto te da una lista clara de los archivos que necesitas optimizar, ordenados por impacto.
Usando Chrome DevTools
- Abre Chrome DevTools (F12).
- Ve a la pestana “Performance”.
- Graba una carga de página.
- Busca barras largas de color amarillo (JavaScript) y morado (CSS) en la sección “Main” del timeline.
- Los bloques que aparecen antes del primer pintado son los recursos que bloquean el renderizado.
La pestana “Network” también es util. Filtra por CSS y JS, ordena por prioridad y busca archivos que se descargan con prioridad “High” o “Highest” antes del primer pintado.
Usando WebPageTest
WebPageTest ofrece un waterfall detallado que muestra visualmente la secuencia de carga de cada recurso. Las barras de color azul claro representan DNS, las verdes la conexión TCP, las moradas el TLS, y las azul oscuro la descarga del archivo. Busca archivos CSS y JS que bloquean el inicio del renderizado, representado por la linea vertical verde.
Estrategia completa de optimización
Para un sitio WordPress, la estrategia optima combina todas estas técnicas:
-
JavaScript: Todo con
deferexcepto scripts absolutamente críticos (analítica básica, scripts de consentimiento de cookies). Nunca usesasyncpara scripts que dependen de jQuery. -
CSS: Critical CSS inline en el head para cada tipo de página (home, artículo, producto, categoría). Resto del CSS cargado de forma asincrona con la técnica preload/onload.
-
Fuentes: Alojadas localmente, formato WOFF2, con
font-display: swapy preload para la fuente principal. -
Imágenes: La imagen LCP con
fetchpriority="high"y preload. Resto de imágenes con lazy loading nativo. -
Terceros: Scripts de terceros (analítica, chat, redes sociales) cargados con defer o, mejor aun, con carga diferida tras la interacción del usuario.
-
Minificacion: Todos los archivos CSS y JS minificados. Combinación solo si es beneficiosa.
Con esta estrategia, el usuario ve contenido inmediatamente mientras los recursos pesados (scripts de galeria, mapas, widgets) se cargan en segundo plano. El resultado tipico es una mejora del FCP de 3-5 segundos a menos de 1.5 segundos y una mejora del LCP por debajo de 2.5 segundos.
Errores comunes al optimizar recursos bloqueantes
Aplicar defer a jQuery cuando plugins lo necesitan sincronamente
Muchos plugins de WordPress dependen de jQuery y esperan que este disponible inmediatamente. Aplicar defer a jQuery puede romper sliders, modals, validación de formularios y otras funcionalidades. La solución es excluir jQuery del defer o migrar a una versión del plugin que no dependa de jQuery.
Eliminar CSS crítico por error
Al purgar CSS no utilizado, herramientas automáticas pueden eliminar estilos que solo se activan con interacción del usuario (hovers, estados activos, modals) o que se aplican a contenido cargado dinamicamente. Siempre verifica el resultado visual despues de purgar CSS, especialmente en dispositivos móviles.
No probar en móvil
Un sitio puede cargar rápido en escritorio con una conexión de fibra y fallar completamente en móvil con 4G. Siempre prueba las optimizaciones en la vista móvil de PageSpeed Insights y en dispositivos reales.
Confiar solo en la puntuacion de PageSpeed
PageSpeed Insights es una herramienta de diagnóstico, no un objetivo en si mismo. Un sitio con puntuacion 100 pero que no convierte es inutil. Optimiza para la experiencia real del usuario, no para un número.
Conclusion
Los recursos que bloquean el renderizado son uno de los problemas de rendimiento más comunes y más soluciónables en sitios WordPress. La combinación de defer para JavaScript, Critical CSS para hojas de estilo y font-display: swap para fuentes web puede transformar un sitio que tarda 5 segundos en mostrar contenido en uno que pinta en menos de 1.5 segundos.
La clave es entender el mecanismo: el navegador no puede pintar hasta que ha procesado los recursos en el head. Reducir, retrasar o eliminar esos recursos acelera directamente el primer pintado y mejora las metricas de Core Web Vitals que Google usa para posicionar.
Comienza por PageSpeed Insights para identificar los recursos problematicos, implementa las soluciones con un plugin de cache como WP Rocket o mediante código personalizado, y verifica los resultados. La mejora suele ser dramatica e inmediata.
