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 era mantener Jetpack Boost activo en todo el sitio y evitar que interfiriera con Revolution Slider solo en esa página concreta.
TOC
En una web montada con Avada, Revolution Slider depende 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 aparecer el error clásico 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 por qué el fallo parece “intermitente”. Depende del momento exacto en que se ejecutan los scripts, de cachés, de prioridades de descarga y de pequeñas variaciones de cada visita. La página no está rota en el servidor. Lo que falla es el orden de ejecución en el navegador.
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.
Después, la consola del navegador daba el indicio definitivo. Los errores apuntaban a ficheros habituales 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 intenta ejecutarse antes de tiempo.
Jetpack Boost no es una única cosa. Tiene módulos distintos, entre ellos caché de páginas y optimizaciones de carga. Excluir una URL en “Cache Site Pages” solo significa que esa página no se cachea como HTML, 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.
La opción que suele romper sliders no es la caché, sino el módulo que aplaza JavaScript. Ese aplazado no tiene una excepción por URL desde la interfaz. Se puede activar o desactivar, pero no hay un “no aplaces JavaScript en esta página”.
La única forma de mantenerlo activo en todo el sitio y neutralizarlo para Revolution Slider consiste en excluir los scripts del slider del aplazado, marcándolos para que Boost no los toque.
Jetpack Boost soporta una exclusión mediante un atributo HTML en la etiqueta <script>. La idea es sencilla. Si Boost detecta ese atributo, no difiere ni altera ese script, y eso evita que Revolution Slider se ejecute sin su dependencia.
El problema 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, solo en la página donde está el slider.
Se puede poner este tipo de lógica en el functions.php del tema, pero en un tema padre como Avada tiene un inconveniente evidente. En cuanto actualices el tema, pierdes el cambio. Un mu-plugin evita eso sin instalar nada desde el panel. Es un archivo PHP suelto que WordPress carga siempre y que no depende de las actualizaciones del tema.
La implementación se hizo para que afectara solo a la URL del slider, dejando Jetpack Boost intacto en el resto del sitio. En este caso, la condición se limitó a /cursos-formacion/, que es donde se detectaba el problema.
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 la exclusión a jQuery y a los scripts de Revolution Slider solo cuando la URL coincide.
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
Este bloque está preparado para publicarse sin romper el HTML, incluyendo versiones AMP, porque no contiene la cadena <script literal y muestra el código como texto plano.
<?php
/**
* Excluye jQuery + Revolution Slider del defer de Jetpack Boost SOLO en /cursos-formacion/
*/
add_filter('script_loader_tag', function ($tag, $handle, $src) {
if ( is_admin() ) {
return $tag;
}
$uri = $_SERVER['REQUEST_URI'] ?? '';
if ( strpos($uri, '/cursos-formacion/') !== 0 ) {
return $tag;
}
$is_jquery = in_array($handle, ['jquery', 'jquery-core', 'jquery-migrate'], true);
$is_revslider = (
stripos($src, 'rbtools') !== false ||
stripos($src, 'rs6') !== false ||
stripos($src, '/revslider/') !== false ||
stripos($src, 'revslider') !== false
);
if ( ($is_jquery || $is_revslider) && strpos($tag, 'data-jetpack-boost="ignore"') === false ) {
$tag = str_replace('<scr' . 'ipt ', '<scr' . 'ipt data-jetpack-boost="ignore" ', $tag);
}
return $tag;
}, 10, 3);
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.
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.
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.
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.
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.
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
Leave a Comment