Render-blocking requests en WordPress: cómo eliminar los recursos que bloquean el renderizado

Has abierto PageSpeed Insights para comprobar la velocidad de tu WordPress y entre los diagnósticos aparece un aviso relacionado con Render-blocking requests o recursos que bloquean el renderizado.

Puede que además PageSpeed acompañe el aviso con una estimación bastante tentadora:

Est savings of 300 ms.

O 500 ms. O incluso más.

La primera reacción suele ser pensar: perfecto, solo tengo que eliminar esos archivos y mi web cargará más rápido.

Pero no es exactamente así.

Esos archivos CSS y JavaScript probablemente están ahí porque WordPress, tu theme o alguno de tus plugins los necesita. El objetivo no suele ser eliminarlos sin más, sino conseguir que no retrasen innecesariamente la aparición del contenido principal de la página.

Y aquí conviene ir con cuidado.

Una mala optimización de CSS o JavaScript puede conseguir una puntuación más alta en PageSpeed y, al mismo tiempo, dejarte un menú que no funciona, un diseño que aparece sin estilos durante unas décimas de segundo o un formulario que ha dejado de responder.

Vamos a ver qué significa realmente este aviso, cómo localizar los recursos responsables y qué podemos hacer en WordPress.

¿Qué significa Render-blocking requests?

Cuando alguien entra en una página, el navegador descarga primero el documento HTML.

A partir de ese HTML descubre otros recursos necesarios para construir la página:

archivos CSS;
JavaScript;
fuentes;
imágenes;
recursos cargados por plugins;
recursos externos.

El navegador no puede mostrar inmediatamente todo lo que recibe.

Necesita interpretar el HTML, conocer los estilos que debe aplicar y ejecutar determinados recursos.

Algunos archivos pueden hacer que el navegador tenga que esperar antes de poder representar correctamente el contenido visible de la página.

Esos recursos están bloqueando el renderizado.

Simplificando mucho, puede ocurrir algo parecido a esto:

Usuario solicita la página → llega el HTML → navegador descubre CSS → descarga CSS → procesa CSS → empieza a mostrar la página

Si ese CSS tarda demasiado en llegar o tenemos varios archivos bloqueando el proceso, el visitante puede tardar más en ver el contenido.

Eso es precisamente lo que PageSpeed intenta detectar.

¿Por qué ocurre tanto en WordPress?

Porque una página WordPress rara vez está formada únicamente por el HTML y un pequeño archivo CSS.

Tenemos:

WordPress + theme + plugins + fuentes + scripts + estilos + recursos externos.

Un theme puede cargar sus propios estilos.

WooCommerce puede añadir los suyos.

Un formulario puede necesitar CSS y JavaScript.

Un plugin de cookies puede añadir más código.

Un constructor visual puede cargar numerosos recursos.

Y otro plugin puede necesitar todavía más.

Individualmente, cada elemento puede tener sentido.

El problema aparece cuando acumulamos recursos que el navegador necesita procesar antes de poder representar la parte importante de la página.

Por eso instalar simplemente un plugin de caché no garantiza que desaparezca el aviso.

¿Render-blocking significa que tengo que borrar esos archivos?

No.

Y este punto es importante.

No elimines un archivo CSS o JavaScript simplemente porque PageSpeed lo muestra dentro de Render-blocking requests.

Primero necesitamos saber:

Qué archivo es.
Quién lo está cargando.
Para qué sirve.
Si realmente es necesario en esa página.
Si podemos cambiar cuándo o cómo se carga.

Un archivo puede bloquear el renderizado y ser completamente necesario.

Por ejemplo, el CSS principal de tu theme contiene buena parte del aspecto visual de la página.

Eliminarlo podría hacer que PageSpeed dejase de señalar ese recurso.

También podría hacer que tu web pareciese de 1998.

Nuestro objetivo no es engañar a PageSpeed.

Nuestro objetivo es conseguir que el navegador pueda mostrar antes el contenido importante sin romper la página.

Cómo saber qué recursos están bloqueando el renderizado

Vamos a empezar por PageSpeed Insights.

Introduce la URL que quieres analizar y ejecuta la prueba.

Es importante analizar una URL concreta, no pensar en WordPress como un bloque único.

La home puede cargar unos recursos y un artículo otros completamente diferentes.

Dentro del informe busca el diagnóstico relacionado con:

Render-blocking requests

PageSpeed puede mostrar debajo una lista de recursos.

Podrías encontrarte URLs similares a:

/wp-content/themes/mi-theme/style.css
/wp-content/plugins/mi-plugin/assets/css/frontend.css
/wp-content/plugins/otro-plugin/assets/js/script.js

No te preocupes si parecen complicadas.

En realidad, esas rutas nos están dando una pista enorme.

Por ejemplo:

/wp-content/plugins/mi-plugin/

nos está diciendo que probablemente ese recurso procede de un plugin.

Mientras que:

/wp-content/themes/mi-theme/

apunta hacia el theme.

Ya hemos pasado de:

“PageSpeed dice que mi web tiene Render-blocking requests”

a algo mucho más útil:

“Este archivo concreto está participando en el bloqueo y sé aproximadamente de dónde procede”.

Eso es diagnosticar.

No todos los recursos bloqueantes tienen la misma importancia

Imagina que PageSpeed encuentra cuatro archivos:

theme/style.css
plugin-a/frontend.css
plugin-b/icons.css
plugin-c/script.js

La peor estrategia sería intentar retrasar los cuatro de golpe.

Yo empezaría preguntándome:

¿Qué hace cada uno?

Puede que style.css sea fundamental para mostrar correctamente la página.

Pero quizá plugin-b/icons.css pertenece a un plugin que únicamente muestra un pequeño elemento al final de la página.

En ese caso tenemos una pregunta interesante:

¿Necesitamos cargar ese recurso tan pronto?

Esta forma de pensar es mucho más útil que aplicar una optimización global sin saber qué estamos modificando.

CSS que bloquea el renderizado en WordPress

El CSS merece especial atención porque el navegador necesita conocer los estilos para representar correctamente la página.

Imagina que el HTML dice:

<h1>Mi página</h1>

El navegador sabe que existe un H1.

Pero el CSS puede decirle:

qué tamaño tiene;
qué tipografía utiliza;
cuánto espacio ocupa;
dónde debe colocarse;
cómo se comporta en móvil.

Por eso no podemos simplemente decir:

“Todo el CSS bloquea, así que vamos a retrasarlo todo”.

Parte de esos estilos puede ser necesaria para representar correctamente el contenido inicial.

¿Qué es el CSS crítico?

Aquí aparece un concepto muy utilizado en WPO:

Critical CSS o CSS crítico.

La idea simplificada es cargar primero los estilos imprescindibles para representar la parte visible inicialmente y dejar para después estilos que todavía no necesitamos.

Imagina una página enorme con:

cabecera;
hero;
contenido;
tablas;
formulario;
FAQ;
footer.

Cuando el usuario entra, probablemente solo ve inicialmente la cabecera y una parte del hero.

No necesariamente necesita en ese mismo instante todos los estilos del formulario situado 2.000 píxeles más abajo.

El CSS crítico intenta priorizar lo necesario para mostrar correctamente esa primera zona visible.

Bien implementado puede ayudar.

Mal implementado puede provocar problemas visuales, saltos o pequeños momentos en los que la página aparece sin sus estilos definitivos.

Por eso siempre hay que comprobar el resultado.

¿Y qué ocurre con JavaScript?

JavaScript introduce otro problema.

Un script puede necesitar descargarse, analizarse y ejecutarse.

Pero no todos los scripts son igual de importantes.

Piensa en un menú móvil.

Necesitamos que funcione cuando el usuario quiera utilizarlo.

Ahora piensa en una funcionalidad que solamente se utiliza cuando alguien llega al final de un artículo.

¿Necesitamos necesariamente procesarla con la misma prioridad?

Aquí aparecen dos conceptos que encontrarás continuamente al optimizar WordPress:

defer y delay.

No son exactamente lo mismo.

Qué significa defer JavaScript

De forma simplificada, defer permite descargar un script sin detener de la misma manera el procesamiento del documento y ejecutarlo cuando el HTML ya ha sido procesado.

Por ejemplo:

<script src="script.js" defer></script>

Puede ser una buena solución para determinados scripts.

Pero atención:

añadir defer indiscriminadamente a todos los JavaScript no es una estrategia de optimización.

Algunos scripts dependen de otros.

Otros necesitan ejecutarse en un momento determinado.

Cambiar el orden puede provocar errores.

¿Qué significa retrasar o Delay JavaScript?

Algunos plugins de rendimiento permiten retrasar determinados scripts hasta que exista interacción del usuario o hasta otro momento posterior.

Esto puede producir mejoras importantes en determinadas métricas.

Pero también es una de esas opciones que puede parecer maravillosa en PageSpeed y provocar sorpresas en la web real.

Después de activarla comprueba, como mínimo:

menú;
buscador;
formularios;
sliders;
botones;
popups;
consentimiento de cookies;
carrito si utilizas WooCommerce;
cualquier elemento interactivo importante.

No des por hecho que todo funciona porque la home “se ve bien”.

Cómo identificar el plugin que carga un recurso bloqueante

Supongamos que PageSpeed muestra:

/wp-content/plugins/example-plugin/assets/css/frontend.css

Tenemos una pista bastante clara.

El recurso pertenece probablemente a example-plugin.

Ahora debemos preguntarnos:

¿Necesito ese plugin en esta página?

Esta pregunta puede descubrir optimizaciones mucho más interesantes que minificar el archivo.

Imagina un plugin utilizado para mostrar un formulario únicamente en /contacto/.

Si sus archivos CSS y JavaScript se están cargando también en todos tus artículos, quizá exista margen para evitar esas cargas donde no son necesarias.

En ese caso el problema no sería:

“¿Cómo hago más pequeño este CSS?”

sino:

“¿Por qué estoy cargando este CSS en una página que no utiliza el plugin?”

Ese tipo de preguntas son las que realmente pueden limpiar WordPress.

Antes de instalar otro plugin de optimización

Es tentador buscar:

mejor plugin para eliminar render blocking WordPress

instalar uno, activar:

Minify CSS
Optimize CSS delivery
Defer JavaScript
Delay JavaScript
Remove unused CSS

y comprobar PageSpeed.

A veces funciona sorprendentemente bien.

Otras veces empiezan los problemas.

Por eso, antes de añadir otro plugin, revisaría qué herramientas de rendimiento ya tienes instaladas.

Es relativamente fácil terminar con:

plugin de caché + plugin de optimización CSS + plugin de JavaScript + CDN con optimizaciones propias

y que varias herramientas intenten modificar los mismos recursos.

Más optimización no significa necesariamente más rendimiento.

Minificar CSS no es lo mismo que eliminar recursos bloqueantes

Esta confusión es bastante habitual.

Minificar un archivo significa reducir su tamaño eliminando elementos innecesarios para su interpretación, como determinados espacios o caracteres.

Eso puede hacer que pese menos.

Pero el archivo puede seguir siendo necesario antes del renderizado.

Por tanto:

CSS más pequeño ≠ CSS que deja automáticamente de bloquear el renderizado.

Lo mismo ocurre con JavaScript.

La minificación puede formar parte de la optimización, pero no resuelve por sí sola todos los problemas de prioridad de carga.

Combinar archivos tampoco siempre es la solución

Durante años fue habitual recomendar combinar muchos CSS o JavaScript en un único archivo.

La lógica parecía evidente:

menos archivos = menos peticiones.

Pero las tecnologías web han evolucionado y esa regla ya no debería aplicarse automáticamente a cualquier web.

En algunos casos combinar puede ayudar.

En otros puede crear archivos enormes o hacer que una página descargue código que ni siquiera necesita.

Una vez más:

medir antes de decidir.

Cómo comprobar estos recursos con Chrome DevTools

PageSpeed nos dice que existe un problema.

Chrome DevTools nos permite investigarlo más de cerca.

En Chrome:

Abre la página.
Pulsa F12.
Entra en Network.
Recarga la página.

Verás todos los recursos solicitados.

Puedes utilizar los filtros para centrarte en:

CSS

Observa:

qué archivo se carga;
desde qué dominio;
cuánto pesa;
cuánto tarda;
cuándo empieza a descargarse;
quién parece estar generándolo.

No hace falta ser desarrollador para empezar a sacar conclusiones.

Una ruta como:

/wp-content/plugins/nombre-plugin/

ya te proporciona información valiosa.

Cuidado con los recursos externos

No todos los recursos proceden de tu WordPress.

Puedes encontrar peticiones hacia servicios externos:

fuentes;
analítica;
publicidad;
widgets;
vídeos;
chat;
redes sociales;
scripts de terceros.

En esos casos tu plugin de caché no siempre tiene control completo sobre lo que ocurre.

Pregúntate:

¿Este recurso externo aporta suficiente valor como para justificar su coste?

No significa que debamos eliminar Google Analytics, un vídeo o cualquier servicio externo por sistema.

Significa que debemos ser conscientes de que cada integración puede tener un coste de rendimiento.

Render-blocking y LCP están relacionados

Aquí aparece otra razón por la que este diagnóstico merece atención.

El Largest Contentful Paint (LCP) mide cuánto tarda en mostrarse uno de los elementos principales del contenido visible.

Si antes de poder representar ese elemento el navegador tiene que esperar a determinados recursos, esos recursos pueden contribuir a retrasar el LCP.

Por ejemplo:

HTML → CSS bloqueante → fuente → estilos → elemento LCP

Cuantas más dependencias críticas introduzcamos antes de mostrar el contenido principal, más difícil puede resultar conseguir una carga rápida.

Por eso no debemos ver los diagnósticos de PageSpeed como problemas completamente independientes.

Muchas veces están conectados.

¿Qué puedo hacer para solucionar Render-blocking requests en WordPress?

No existe una única solución.

Dependiendo del recurso podemos considerar distintas posibilidades:

1. Eliminar recursos que realmente no necesitamos

Si un plugin carga CSS o JavaScript en páginas donde no se utiliza, podemos estudiar cómo evitar esa carga.

Esta suele ser una de las soluciones más limpias.

2. Reducir CSS innecesario

Themes y plugins pueden generar estilos que una página concreta no utiliza.

Eliminar o reducir CSS no utilizado puede disminuir la cantidad de código que necesita procesar el navegador.

Pero hay que probar cuidadosamente el resultado en distintas páginas y tamaños de pantalla.

3. Generar CSS crítico

Podemos priorizar los estilos necesarios para representar la parte inicial de la página y cargar otros posteriormente.

4. Diferir JavaScript cuando sea posible

Determinados scripts pueden utilizar defer sin afectar al funcionamiento de la página.

5. Retrasar JavaScript no esencial

Algunos scripts pueden esperar hasta más tarde o hasta que exista interacción.

Pero siempre debemos comprobar las funcionalidades afectadas.

6. Revisar recursos externos

Fuentes, widgets y scripts externos pueden introducir nuevas dependencias en la ruta crítica.

7. Configurar correctamente el plugin de rendimiento

Herramientas de optimización pueden automatizar parte de este trabajo.

La clave no está simplemente en utilizarlas.

Está en configurarlas según las necesidades de la web y comprobar el resultado después de cada cambio importante.

Un ejemplo práctico

Imagina que PageSpeed te muestra tres recursos:

/theme/style.css
/plugin-form/frontend.css
/plugin-slider/slider.js

No activaría tres optimizaciones de golpe.

Primero comprobaría el CSS del formulario.

Supongamos que estamos analizando un artículo donde no existe ningún formulario.

Entonces investigaría:

¿Por qué se carga frontend.css aquí?

Si conseguimos que el plugin cargue ese CSS únicamente donde existe el formulario, habremos eliminado una petición innecesaria sin tener que hacer trucos con su prioridad.

Después analizaríamos slider.js.

Si la página tampoco contiene ningún slider, tenemos una situación similar.

Finalmente llegamos a style.css.

Ese archivo probablemente sí sea fundamental.

Ahí quizá no queramos eliminarlo, sino estudiar su tamaño, contenido y forma de entrega.

Tres archivos. Tres decisiones diferentes.

Eso es mucho más seguro que pulsar “eliminar recursos bloqueantes” y esperar.

Haz los cambios de uno en uno

Esta recomendación parece lenta.

En realidad puede ahorrarte muchísimo tiempo.

Imagina que activas simultáneamente:

minificación;
CSS crítico;
eliminación de CSS no utilizado;
defer;
delay JavaScript;
optimización de fuentes.

PageSpeed mejora.

Pero el menú móvil deja de funcionar.

Ahora tienes seis posibles culpables.

En cambio, si activas una modificación, vacías caché, pruebas la web y vuelves a medir, sabes exactamente qué efecto ha producido.

Mi proceso sería:

cambio → limpiar caché → comprobar web → medir → siguiente cambio

No:

activar todo → rezar → PageSpeed.

Comprueba la web como un usuario, no solo como PageSpeed

Después de cualquier optimización de CSS o JavaScript, navega por tu propia web.

Haz clic.

Abre el menú.

Envía un formulario de prueba.

Mira la página desde el móvil.

Visita artículos, categorías y páginas diferentes.

Si tienes WooCommerce, prueba el carrito y el checkout.

Una optimización que mejora PageSpeed pero rompe una función importante no es una mejora.

¿Tengo que conseguir que desaparezca completamente el aviso?

No necesariamente.

Esta idea es importante para entender PageSpeed.

Un diagnóstico no significa automáticamente:

“Tu web está mal hasta que esto desaparezca”.

Puede existir algún recurso bloqueante cuya presencia tenga sentido.

Lo importante es analizar si está provocando un retraso significativo y si tenemos una alternativa razonable.

No sacrificaría estabilidad, diseño o funcionalidad simplemente para hacer desaparecer una línea del informe.

Diagnóstico rápido de Render-blocking requests en WordPress

Si PageSpeed te muestra este aviso, puedes seguir este orden:

1. Mira qué archivos aparecen.

¿Son CSS, JavaScript o ambos?

↓

2. Observa la URL de cada archivo.

¿Procede del theme, de un plugin o de un servicio externo?

↓

3. Pregúntate si ese recurso es necesario en esa página.

Si no lo es, investiga si puedes evitar su carga.

↓

4. Si es necesario, analiza cuándo necesita cargarse.

No todos los recursos tienen que tener la misma prioridad.

↓

5. Si es CSS, estudia CSS crítico o reducción de CSS innecesario.

Pero comprueba cuidadosamente el diseño.

↓

6. Si es JavaScript, estudia defer o delay.

Comprueba después todos los elementos interactivos.

↓

7. Vacía caché y vuelve a medir.

Nunca compares una versión antigua almacenada en caché con la nueva configuración.

↓

8. Comprueba la web manualmente.

PageSpeed puede mejorar y la web empeorar.

Necesitamos las dos cosas:

buen rendimiento + web funcionando correctamente.

Errores que evitaría

Después de trabajar con optimización WordPress, hay varias decisiones que considero especialmente peligrosas:

Activar todas las opciones de rendimiento a la vez

Hace mucho más difícil descubrir qué optimización ha provocado un problema.

Instalar varios plugins que hacen lo mismo

Dos herramientas modificando CSS o JavaScript pueden terminar generando conflictos difíciles de diagnosticar.

Eliminar archivos porque PageSpeed los señala

PageSpeed te está mostrando un recurso que participa en el proceso, no dándote permiso para borrarlo.

Probar únicamente la home

Una optimización puede funcionar perfectamente en la portada y romper un formulario, una ficha de producto o una página que utiliza otros scripts.

Obsesionarse con llegar a 100

La puntuación es útil.

La web real lo es más.

Entonces, ¿cómo eliminar los recursos que bloquean el renderizado en WordPress?

La respuesta corta sería:

Identifica primero qué CSS y JavaScript están bloqueando el renderizado, descubre qué theme, plugin o servicio los carga y decide individualmente si puedes eliminarlos de esa página, reducirlos, priorizar CSS crítico o diferir/retrasar JavaScript no esencial.

Pero la parte realmente importante es esta:

no empieces por la solución; empieza por el recurso.

PageSpeed te proporciona la pista.

DevTools te ayuda a investigar.

WordPress te permite buscar el origen.

Y solo entonces tiene sentido decidir qué optimización aplicar.

En Resumidas Cuentas

Cuando PageSpeed muestra Render-blocking requests, no está diciendo simplemente que tengas demasiados archivos.

Te está indicando que existen recursos que intervienen antes de que el navegador pueda representar el contenido de la página y que puede haber margen para optimizar esa ruta.

En WordPress esos recursos suelen estar relacionados con el theme, plugins, CSS, JavaScript o servicios externos.

La solución no debería ser instalar herramientas al azar.

Empieza identificando los archivos.

Descubre quién los carga.

Comprueba si son necesarios.

Y después decide si puedes evitar su carga, reducirlos o cambiar el momento en el que se procesan.

Medir → diagnosticar → optimizar → comprobar.

Esa secuencia es mucho más importante que conseguir que PageSpeed deje de mostrar un aviso.

Porque el objetivo final no es tener un informe bonito.

Es tener un WordPress rápido que siga funcionando correctamente.