Te presento a tus amienemigos: solicitudes que bloquean el renderizado en WordPress

Un problema común que herramientas como Google PageSpeed ​​Insights detectan en webs hechas con WordPress son las solicitudes que bloquean el renderizado. Estas solicitudes pueden retrasar significativamente el tiempo que tarda tu página en ser visible para los visitantes. Obviamente, ¡no queremos esto!

En este artículo, exploraremos qué son las solicitudes que bloquean el renderizado, por qué son malas (o no), por qué aparecen con frecuencia en entornos WordPress y estrategias prácticas para gestionar y reducir su impacto sin comprometer la funcionalidad de tu sitio.

Qué son realmente las solicitudes que bloquean el renderizado

Cuando un navegador carga una página, analiza el HTML para construir el DOM, luego hace lo mismo con el CSS y su equivalente CSSOM, y estos dos se combinan para crear el árbol de renderizado, que el navegador utiliza para realizar cálculos de diseño y posición antes de comenzar a generar la página y pintarla en pantalla. No te preocupes, los tecnicismos del DOM, CSSOM y el árbol de renderizado no son tema para este artículo (uf…).

Ese proceso de análisis inicial es la clave. Cuando el navegador analiza el HTML de arriba a abajo, debe pausar el proceso para descargar y procesar cada bloque CSS integrado o archivo CSS que encuentre durante el análisis, que luego se utilizará para construir el CSSOM. Esto lo hace para asegurarse de que el diseño y el estilo de la página se muestren y funcionen correctamente. Y esta es también la razón por la que, por defecto, todo el CSS del código fuente bloquea el renderizado de la página, y por qué esto es algo positivo: a nadie le gusta ver páginas sin diseñar, ni siquiera durante una fracción de segundo.

Lo mismo puede ocurrir con JavaScript. Un enlace a un archivo JavaScript bloquea el renderizado por defecto, pero los desarrolladores pueden cambiar fácilmente este comportamiento añadiendo ciertos atributos a la etiqueta de script (lo veremos más adelante).

En resumen, los recursos que bloquean el renderizado son archivos que el navegador debe cargar y procesar antes de poder mostrar las partes visibles de una página web.

Por qué los recursos que bloquean el renderizado son comunes en WordPress

Una vez que entendemos que todo el CSS por defecto bloquea el renderizado, queda claro por qué las solicitudes bloqueantes son comunes en WordPress. Las webs suelen depender de múltiples temas y plugins, cada uno con sus propios archivos CSS y JavaScript. Los temas están estructurados para cargar diversos estilos y scripts en cada página, incluso sin ser necesarios en cada una de ellas. Los plugins, especialmente aquellos que añaden funcionalidad o elementos visuales, añaden aún más archivos adicionales que pueden bloquear el renderizado.

No solo eso, los maquetadores de páginas y los temas multipropósito añaden todavía más CSS y JS para cubrir todo tipo de necesidades de los clientes que buscan diferentes funciones. Este es, de hecho, uno de los problemas cuando los desarrolladores priorizan la cantidad sobre la calidad: el producto crece continuamente y llega a convertirse en un monstruo de CSS/JS. Por ejemplo, Enfold, un tema muy popular pero bastante pesado, en una instalación limpia de WordPress carga casi medio megabyte de CSS y JS distribuidos en 40 archivos.

Cómo afectan las solicitudes que bloquean el renderizado al rendimiento

Desde la perspectiva del visitante, las solicitudes que bloquean el renderizado retrasan el momento en el que cualquier parte de la página se vuelve visible (el First Paint). Considerando que cuanto más tarda una página en cargarse, mayor es la probabilidad de que el usuario se vaya, los recursos que bloquean el renderizado pueden afectar directamente a las conversiones y las ventas. Esto es especialmente importante en dispositivos móviles o conexiones lentas donde el ancho de banda y la potencia de procesamiento son limitados, ya que los visitantes percibirán la página como lenta.

Desde una perspectiva técnica, el efecto de las solicitudes que bloquean el renderizado se entiende mejor a través de las Web Vitals: tanto el First Contentful Paint (FCP) como el Largest Contentful Paint (LCP; una de las Core Web Vitals) se ven afectadas. El FCP mide el tiempo desde que una página comienza a cargarse hasta que aparece el contenido por primera vez en pantalla, mientras que el LCP mide el tiempo hasta que acaba de cargarse el elemento más grande. Por lo tanto, cuanto más CSS o JS que bloquea el renderizado deba analizar el navegador, más tardará en aparecer el contenido.

Indirectamente, los recursos que bloquean el renderizado también pueden afectar al Total Blocking Time (TBT) y al Interaction to Next Paint (INP), no porque bloqueen el renderizado directamente, sino debido a todos los estilos y funcionalidades adicionales que añaden. Pero ese es un tema para otra entrada del blog.

Identificando las solicitudes que bloquean el renderizado en WordPress

Lo más probable es que ya sepas cómo identificar los recursos que bloquean el renderizado, ya que probablemente hayas llegado a este artículo después de ver una advertencia en PageSpeed ​​Insights. En realidad, este es el método más sencillo: simplemente haz un test en PageSpeed ​​Insights o usa Lighthouse. En la sección de estadísticas, verás la lista de solicitudes que bloquean el renderizado, mostrando los archivos CSS y JavaScript que buscas.

También puedes utilizar las herramientas de desarrollo de tu navegador. Abre la pestaña de rendimiento y graba una nueva carga de la página. Una vez detengas la grabación, el navegador te dirá literalmente qué está bloqueando el procesamiento. Aquí tienes una captura de pantalla que muestra los dos lugares donde esto sucede: en la barra lateral en la sección de Insights, y en la línea de tiempo al pasar el ratón sobre cada fichero.

Cómo eliminar las solicitudes que bloquean de renderizado en WordPress

Basta de charla, vayamos a la parte interesante. Existen varias técnicas para eliminar las solicitudes que bloquean el renderizado. El problema con WordPress es que casi nunca tenemos control sobre el código de los plugins o temas, por lo que debemos utilizar plugins de optimización o añadir manualmente algunos fragmentos de código para alterar su funcionalidad. La verdad, usar un plugin de optimización te ahorrará muchos dolores de cabeza.

Diferir JavaScript

HTML te permite utilizar dos atributos en las etiquetas de script: async y defer. Estos atributos te permiten controlar cómo el navegador carga los scripts sin bloquear el renderizado. Te invito a hacer clic aquí para una explicación detallada de cómo funcionan estos atributos y cómo usarlos de manera correcta.

Retrasar JavaScript

Si vamos un paso más allá, lo que podemos hacer es retrasar la carga y ejecución de JavaScript hasta que un usuario interactúe con la página. Esto es especialmente útil para scripts de terceros (Google Tag Manager, Facebook Pixel, YouTube, etc.), sobre los cuales tenemos poco control ya que no están alojados en nuestro servidor. Al retrasar su carga hasta que realmente se necesiten, evitamos que el navegador bloquee el renderizado de la página debido a estos scripts. Después de todo, JavaScript se encarga principalmente de la interacción, que a menudo puede esperar hasta que la página sea visible.

Mi recomendación es retrasar tantos archivos JavaScript como sea posible, así como diferirlos también. Ambas técnicas se pueden utilizar al mismo tiempo.

Haz clic aquí para leer más sobre cómo retrasar JavaScript de forma correcta.

Integrar CSS crítico y retrasar CSS no crítico

El CSS crítico incluye los estilos necesarios para pintar el contenido visible antes de desplazarse en la página, también llamado above-the-fold. Extraer e integrar estos estilos críticos mientras se retrasa el resto es una técnica muy útil para deshacerse de las solicitudes CSS que bloquean el renderizado. El CSS integrado vive directamente dentro del HTML que se está analizando (a través de la etiqueta <style> o el atributo style), por lo que evitamos solicitudes de red y dejamos al navegador que empiece el pintado y diseño antes. Para más información acerca del CSS crítico, consulta este artículo.

Reducir CSS que no se use

Los plugins y temas están diseñados para satisfacer una amplia gama de necesidades y usuarios. No están diseñados a medida para una sola web. Es por eso que a menudo incluyen mucho CSS que resulta ser innecesario para muchas webs. Eliminar el contenido CSS que no se use significa, por tanto, eliminar estos estilos inútiles.

En el contexto de WordPress, reducir el contenido CSS que no se usa implica dos pasos:

1. Detectar el CSS que no es necesario y eliminarlo.
2. Obtener el CSS que sí se usa y guardarlo en un lugar que esté disponible para el navegador lo antes posible. Esto se puede hacer colocándolo en una etiqueta <style> al principio del documento (similar a lo que es el CSS crítico) o en un archivo CSS precargado (preloaded).

Dale un vistazo a mi guía sobre cómo eliminar el contenido CSS que no se use en WordPress y recuerda: si eliminas el CSS sin usar con un plugin de optimización, no necesitarás utilizar la técnica de CSS crítico.

Minimizar CSS y JS

El objetivo aquí es básicamente reducir el tamaño de CSS y JS tanto como sea posible. Cuanto más pequeños sean los archivos, más rápido se descargarán y el navegador podrá empezar a analizarlos antes.

Hoy en día, casi todos los plugins de optimización manejan fácilmente este tema. Aquí tienes más información sobre las herramientas que puedes utilizar para minimizar los archivos CSS y JavaScript.

Evita maquetadores de páginas, plugins o temas pesados

Sí, ya sé que es muy fácil decirlo pero no tanto hacerlo, pero te recomiendo encarecidamente que intentes reconstruir tu web sin un maquetador o utilizando un tema más ligero. Realmente vale la pena. ¿No me crees? Solo tienes que ver el resultado al probar una página de muestra con el tema Blocksy:

Y ahora compáralo con la misma página convertida a Elementor usando su configuración por defecto:

También tienes aquí una comparación similar entre Gutenberg y Elementor, o mi lista recomendada de temas rápidos y ligeros.

El mismo principio se aplica a los plugins: utiliza la menor cantidad posible de plugins y evita los que añadan demasiados recursos.

¿Por qué es tan importante esto? Porque elegir los plugins más ligeros posibles nos hará utilizar menos archivos CSS y JS, lo que nos ayudará a reducir el número de solicitudes que bloquean el renderizado.

Carga scripts de forma modular y solo en las páginas donde sean necesarios

Otra técnica que puede ser extremadamente útil, dependiendo del plugin o tema, es forzar que los archivos CSS/JS del tema o plugins se carguen solo donde tú especifiques. Por ejemplo, ¿por qué un plugin de formulario de contacto debería cargar todos sus archivos CSS y JS en la página de inicio cuando ni siquiera hay un formulario de contacto allí?

Hay varias formas de hacer esto. El método más sencillo es utilizar el fantástico Script Manager de Perfmatters. Puede ser un poco confuso la primera vez que lo usas, pero también lo puede ser cualquier plugin que te permita desactivar scripts por entrada o por página (como Asset CleanUp): ¡esta función no debe usarse a la ligera! Aquí tienes un enlace a la documentación oficial de Perfmatters de su Script Manager si quieres saber cómo se usa.

Además, puedes incluso ir un paso más allá y desactivar la ejecución completa de plugins. Es decir, que WordPress ni siquiera ejecute sus archivos PHP al solicitar la página, cosa que sucede incluso si el CSS/JS del complemento está desactivado. Esta técnica no afecta directamente a la advertencia de «Solicitudes que bloquean el renderizado», pero ayuda en muchos otros aspectos, incluido el tiempo de carga general, TTFB, LCP y FCP, porque básicamente estás haciendo que tu sitio sea más ligero sobre la marcha.

Para desactivar la ejecución completa de plugins, puede usar el modo MU del Script Manager de Perfmatters, o puedes hacerlo manualmente usando esta guía.

Cuándo no deberías eliminar las solicitudes que bloquean el renderizado

Algunos recursos que bloquean el renderizado son necesarios para garantizar que el diseño y la funcionalidad de tu sitio funcionen correctamente. Los pases de diapositivas son un ejemplo típico: sus scripts y estilos suelen ser muy grandes y bloquean el renderizado, pero tienen que serlo, porque casi siempre se colocan en las secciones principales de las páginas, antes de desplazarse. Evitar que bloqueen el renderizado podría causar cambios en el diseño, funcionalidad rota o problemas visuales, lo cual no vale la pena solo para ganar unos pocos puntos más en PageSpeed ​​Insights.

En resumen, no debes eliminar nada necesario para mostrar e interactuar correctamente con la sección que se ve nada más cargar la página, en la parte superior. ¿Recuerdas esas páginas que alguna vez has visitado y que por un instante aparecen sin diseñar? Pues esas son las webs que lo están haciendo mal.