Jetpack Boost rompe Revolution Slider y cómo arreglarlo

El síntoma era incómodo porque parecía aleatorio. A veces la página cargaba bien y el slider se veía, y otras veces el slider desaparecía o se quedaba en blanco. El resto del sitio funcionaba con normalidad, lo que hacía pensar en un “capricho del navegador”, cuando en realidad había un patrón técnico bastante claro detrás.

El punto clave fue identificar que el fallo se concentraba en una única zona del sitio donde se usa Revolution Slider, mientras que el resto de optimizaciones de Jetpack Boost estaban dando buen resultado. El objetivo, por tanto, no era “quitar Jetpack”, sino dejar Jetpack tal cual y evitar que interfiera con Revolution Slider en esa página concreta.

Jetpack Boost y Revolution Slider en Avada

En una web montada con Avada, Revolution Slider suele depender de una carga ordenada de JavaScript, y en particular de que jQuery esté disponible cuando el slider inicializa. Cuando un optimizador cambia el orden, difiere la carga o retrasa scripts “no esenciales”, puede ocurrir lo que vimos en consola, un error de tipo jQuery is not defined. En ese escenario el slider intenta ejecutarse antes de que exista la librería que necesita y la inicialización se rompe.

Esto explica un detalle que despista mucho. El fallo parece “intermitente” porque depende del timing de carga, de cachés, de cómo el navegador prioriza recursos y de pequeñas variaciones en cada visita. La página no está rota en el servidor, lo que se rompe es el orden de ejecución en el cliente.

Cómo confirmamos el origen del problema

La comprobación fue directa. Al desactivar Jetpack Boost, el slider funcionaba de forma consistente. Al activarlo, el fallo reaparecía en esa URL. Ese comportamiento aisló el conflicto a Jetpack Boost, sin necesidad de tocar Avada ni Revolution Slider.

Luego vino la prueba determinante. En la consola del navegador aparecían errores señalando archivos típicos de Revolution Slider, como rbtools y rs6, fallando por falta de jQuery. El mensaje exacto puede variar según versión, pero la lógica se mantiene, hay un script que se ejecuta antes de tiempo.

Por qué la exclusión de caché no lo arregla

Jetpack Boost tiene varios módulos. Uno de ellos es la caché de página, otro es la optimización de CSS, y otro es el aplazado de JavaScript. Cuando se hace una exclusión por URL dentro de “Cache Site Pages”, solo se está diciendo “no caches esta URL”, pero el aplazado de JavaScript puede seguir actuando igual.

Esto es importante porque es un error típico. Se excluye la URL de la caché, se limpia caché, y el fallo continúa. No es un problema de HTML cacheado, es un problema de orden de ejecución de scripts en el navegador.

El detalle que marca la diferencia

La opción que suele romper sliders no es la caché, sino el módulo de aplazado de JavaScript. En Jetpack Boost, ese aplazado no ofrece una excepción por URL desde la interfaz. Se puede activar o desactivar, pero no hay un campo “no aplaces JS en esta página”.

La única forma de mantenerlo activo en todo el sitio y neutralizarlo solo para Revolution Slider consiste en excluir los scripts del slider del aplazado, es decir, marcar esos scripts para que Boost no los toque.

Solución aplicada con exclusión selectiva por script

Jetpack Boost soporta una forma de exclusión mediante un atributo HTML en la etiqueta <script>. La idea es sencilla. Cuando Boost ve un script marcado como “ignorar”, no lo difiere ni altera su carga, y eso evita que el slider se ejecute sin su dependencia.

El reto práctico es que WordPress no te deja editar a mano las etiquetas <script> que se imprimen automáticamente. Por eso la solución correcta es añadir un filtro de WordPress que modifique el HTML de salida de esos scripts y les añada el atributo de exclusión únicamente en la página donde está el slider.

Por qué usamos un mu-plugin y no el functions.php del tema

Se puede pegar este tipo de código en el functions.php del tema, pero en un tema padre como Avada tiene un problema evidente. En cuanto actualices Avada, pierdes el cambio. Además, editar el tema desde el panel siempre tiene el riesgo de meter un error de sintaxis y provocar una pantalla blanca hasta que lo arregles por FTP.

Un mu-plugin resuelve eso sin instalar nada desde el panel. Es un archivo PHP suelto que WordPress carga siempre, se queda fuera de las actualizaciones del tema y es perfecto para “parches” técnicos de este tipo.

Implementación exacta paso a paso

La implementación se hizo para que afectara solo a la URL del slider, dejando Jetpack Boost intacto en el resto del sitio. En tu caso el slider está en la página de cursos, así que la condición se limitó a /cursos-formacion/. La página donde se detectaba el problema es página de cursos y formación.

El flujo fue este. Crear la carpeta de mu-plugins si no existe, crear el archivo PHP y pegar un filtro script_loader_tag que añade el atributo de exclusión a jQuery y a los scripts de Revolution Slider solo cuando la URL coincide.

Ruta y archivo

Crea la carpeta mu-plugins dentro de wp-content si no existe. La ruta final debe quedar así.

wp-content/mu-plugins/boost-ignore-revslider.php

Código definitivo

Pega este contenido tal cual. Está pensado para ser selectivo y no tocar el resto del sitio.

El código hace dos cosas. Primero limita el comportamiento a la URL concreta para que el resto de páginas siga beneficiándose de Boost. Después detecta los scripts críticos por dos vías, el “handle” de jQuery y coincidencias en la URL del script para Revolution Slider. Si coincide, añade el atributo de exclusión.

Si en el futuro cambias el slug de la página, solo tienes que cambiar la cadena /cursos-formacion/ en el filtro. Todo lo demás puede quedarse igual.

Qué tocar en Jetpack Boost

Una vez el mu-plugin está en su sitio, Jetpack Boost se puede dejar exactamente como lo tenías. No hace falta desactivar el aplazado de JavaScript, ni la caché, ni otras optimizaciones que te interesan para el rendimiento global del sitio.

Lo único que conviene hacer es limpiar caché para que no estés midiendo resultados con recursos antiguos. Si tienes caché en Jetpack Boost, purga ahí. Si tu hosting tiene caché adicional, purga también. Luego prueba en incógnito para no contaminar la prueba con extensiones ni recursos cacheados localmente.

Cómo comprobar que la exclusión se está aplicando

La comprobación es simple y no requiere suposiciones. Abre el código fuente de la página (ver código fuente) o inspecciona en el panel de “Elements” y busca los scripts que cargan rbtools y rs6. En esas etiquetas <script> debe aparecer el atributo data-jetpack-boost="ignore".

Si el atributo aparece y el error de consola desaparece, has atacado la causa real, la interferencia del aplazado sobre scripts que necesitan un orden estricto. Si el atributo no aparece, entonces el mu-plugin no está cargando o el archivo no está en la ruta correcta.

Notas prácticas y mantenimiento

Esta solución es deliberadamente conservadora. No desactiva Boost en toda la web, no desactiva módulos, y no penaliza el rendimiento global. Solo dice “en esta URL, deja en paz a estos scripts”. Es lo que querías, rendimiento en el resto del sitio y estabilidad del slider donde realmente se usa.

En cuanto a mantenimiento, el riesgo principal es que en una actualización futura cambien los nombres de los scripts de RevSlider. En la práctica, los patrones rbtools y rs6 llevan tiempo siendo estándar. Aun así, si en algún momento reaparece el error, la primera comprobación es revisar si las URLs de los scripts cambiaron y ajustar los stripos del filtro.

Si quieres afinar aún más

El filtro está preparado para ignorar también jQuery en esa página, porque el error original era precisamente que jQuery no estaba disponible cuando RevSlider lo necesitaba. En entornos donde el aplazado altera el orden, ignorar solo RevSlider a veces no basta si jQuery sigue siendo diferido y llega tarde.

Si en tu caso puntual vieras que no hace falta ignorar jQuery, se podría dejar únicamente la parte de RevSlider. A nivel práctico, ignorar jQuery solo en esa URL no te rompe nada y normalmente no merece la pena complicarlo más.

La opinión de Javier Carmona Benítez

Cuando un plugin de optimización funciona bien en el 95% del sitio, lo lógico no es tirarlo. Lo lógico es entender qué parte está tocando algo sensible y encapsular el problema. Un slider es un caso clásico, porque depende de un orden de carga estricto y de inicializaciones que no toleran bien el aplazado.

El resultado final fue el que interesaba. Jetpack Boost se queda haciendo su trabajo en todo el sitio, y Revolution Slider se queda estable en la página donde aporta valor. El rendimiento global no se sacrifica y el componente que era crítico para esa zona deja de fallar por un detalle tan simple como el orden de ejecución.

Documentación de Jetpack Boost

Mi sitio en Google Maps