Los widgets que cargaban JavaScript innecesario · WordPin 005

El portal de reservas llevaba meses en producción. Reservas de actividades al aire libre: rutas, talleres, excursiones. Todo funcionaba. Los formularios respondían, el buscador filtraba bien, las pasarelas de pago procesaban sin errores. No había quejas del equipo ni tickets de usuarios. Y sin embargo, algo estaba fuera de sitio. Las páginas más simples —aviso legal, política de privacidad, una landing informativa sin formularios— tardaban más de lo razonable en pintar. No era un fallo visible. Era un peso que no correspondía.

Lo noté al cargar la página de condiciones de uso desde una conexión media. El navegador tiraba de recursos como si aquella página tuviera la misma complejidad que la home. La barra de progreso se detenía más de lo esperado antes del primer renderizado. Revisé otras páginas estáticas y el patrón se repetía: los widgets registrados en el tema aparecían vinculados a recursos que no tenían sentido en esas URLs. El contenido era texto plano con un par de encabezados, pero la carga decía otra cosa.

Algo estaba inyectando peso donde no hacía falta. Y la primera sospecha apuntaba lejos del lugar real.

Lo que los widgets arrastraban en cada petición

Empecé por lo más directo: abrir DevTools y revisar la pestaña Network en una página sin contenido dinámico. La de política de privacidad, por ejemplo. Texto, un par de enlaces internos y nada más. El resultado fue este:

// Red - política de privacidad
Requests: 34
JS files: 14
CSS files: 7
Transferred: 812 KB
DOMContentLoaded: 2.4s

Catorce archivos JavaScript en una página que no necesitaba ni uno para funcionar. Siete hojas de estilo. Más de 800 KB transferidos para pintar un texto legal. Eso no era normal. Comparé con la home, que sí tenía slider, mapa, buscador y calendario de disponibilidad:

// Red - home
Requests: 41
JS files: 18
CSS files: 9
Transferred: 1.1 MB
DOMContentLoaded: 2.9s

La diferencia entre ambas páginas era mínima en número de peticiones. Un portal que muestra calendario, mapa interactivo y carrusel en portada debería pesar bastante más que una página de texto. Pero la brecha era ridícula. Aquí había algo que se estaba cargando en todas partes sin distinción.

Primera pista: el plugin de reservas

El sistema de reservas era el componente más pesado del sitio. Gestionaba disponibilidad, calendarios, pagos y confirmaciones. Era lógico sospechar que sus scripts se cargaban globalmente. Activé Query Monitor y filtré por la pestaña de Scripts & Styles en la página de política de privacidad. Busqué cualquier archivo vinculado al plugin de reservas.

Aparecían dos archivos CSS del plugin, pero ningún JavaScript suyo. Los estilos eran residuales: los cargaba para un bloque de disponibilidad que ni siquiera se renderizaba en esa página. Peso menor, unos 18 KB combinados. No era lo que estaba disparando las 14 peticiones JS. Desactivé el plugin en staging para confirmar y el número de scripts apenas bajó de 14 a 13. La reserva no era la culpable principal.

La caché como segundo sospechoso

La segunda hipótesis fue la capa de caché. El sitio usaba un plugin de caché de página con minificación y combinación de archivos activada. Si la caché estaba sirviendo una versión empaquetada con todos los recursos, podía explicar que páginas simples arrastraran el peso de páginas complejas. Purgué la caché completa, desactivé la minificación y cargué la página de privacidad con bypass de caché añadiendo un parámetro aleatorio en la URL.

https://ejemplo.com/politica-de-privacidad/?nocache=82741

El resultado fue prácticamente idéntico: 14 archivos JS, mismo peso, mismo tiempo de carga. La caché no estaba inflando nada. Simplemente conservaba lo que WordPress ya generaba de base. Esto no encajaba. El problema existía antes de que la caché interviniera, así que venía de más atrás en la cadena de encolado.

Un sitio puede responder rápido desde la caché y aun así estar entregando una respuesta innecesariamente pesada.

Con las dos pistas descartadas, volví a Query Monitor. Esta vez no filtré por plugin. Miré la lista completa de scripts encolados en la página de privacidad y empecé a anotar los handles y su origen. Y ahí cambió todo.

El origen estaba en el propio tema

La lista de scripts que Query Monitor mostraba en la página de privacidad incluía archivos que no pertenecían a ningún plugin instalado. Sus handles empezaban con prefijos propios del tema activo: theme-maps, theme-calendar-init, theme-slider, theme-reviews-carousel. Cada uno correspondía a una funcionalidad visual concreta que solo tenía sentido en determinadas secciones del sitio.

Lo que los widgets estaban encolando sin condición

Revisé el archivo functions.php del tema y encontré el bloque que lo explicaba todo. Los widgets del tema —mapa, calendario, carrusel de opiniones, slider de actividades— registraban y encolaban sus scripts y estilos de forma global, sin ninguna condición. El hook wp_enqueue_scripts los cargaba en todas las páginas del sitio, independientemente de si esos widgets estaban activos o visibles en la URL solicitada.

// functions.php del tema (simplificado)
function theme_load_widget_assets() {
    wp_enqueue_script('theme-maps', get_template_directory_uri() . '/js/maps-widget.js', array('jquery'), '1.0', true);
    wp_enqueue_script('theme-calendar-init', get_template_directory_uri() . '/js/calendar-init.js', array('jquery'), '1.0', true);
    wp_enqueue_script('theme-slider', get_template_directory_uri() . '/js/slider.js', array(), '1.0', true);
    wp_enqueue_script('theme-reviews-carousel', get_template_directory_uri() . '/js/reviews-carousel.js', array('jquery'), '1.0', true);
    wp_enqueue_style('theme-maps-css', get_template_directory_uri() . '/css/maps-widget.css');
    wp_enqueue_style('theme-calendar-css', get_template_directory_uri() . '/css/calendar.css');
    wp_enqueue_style('theme-slider-css', get_template_directory_uri() . '/css/slider.css');
}
add_action('wp_enqueue_scripts', 'theme_load_widget_assets');

Cuatro scripts y tres hojas de estilo, cargados en cada página sin excepción. Algunos de ellos dependían de jQuery, lo que arrastraba además esa librería incluso cuando no hacía falta. El peso combinado de estos archivos más sus dependencias rondaba los 340 KB en transferencia. En una página de texto plano, eso representaba casi el 42 % del peso total.

El impacto no era solo de peso. Cada script bloqueaba o retrasaba el renderizado. El navegador tenía que descargar, parsear y ejecutar código JavaScript que no iba a usar. El DOMContentLoaded se disparaba medio segundo más tarde de lo necesario y el Largest Contentful Paint se resentía. En términos de experiencia de usuario, un portal de reservas necesita que la navegación sea rápida, especialmente en móvil. Un visitante que llega desde una búsqueda y tarda más de tres segundos en ver contenido útil tiene muchas probabilidades de abandonar.

WordPress no carga lo que el usuario necesita. Carga lo que alguien le dijo que encolara.

Los widgets no tenían ningún fallo interno. Funcionaban perfectamente en las páginas donde se usaban. El problema era que sus recursos viajaban con cada petición, como si el tema asumiera que cualquier página del sitio podía necesitarlos en cualquier momento. Una decisión de desarrollo cómoda, pero costosa.

Condicionar la carga sin desmontar lo que funcionaba

La solución más directa parecía obvia: desenganchar los scripts con wp_dequeue_script en las páginas que no los necesitaban. Pero hacerlo así, a base de exclusiones, era frágil. Cada vez que se añadiera una página nueva o se moviera un widget, habría que actualizar las condiciones manualmente. Además, el tema podía sobrescribir esos cambios en una actualización futura si se tocaba directamente el functions.php.

Lo que no podía limpiarse de golpe

La primera tentación fue crear un plugin auxiliar que desregistrara todos los scripts del tema y los volviera a encolar solo en la home y en las páginas de actividad. Pero eso asumía que los widgets solo se usaban ahí. Revisé todas las áreas de widgets del tema y encontré que el carrusel de opiniones aparecía también en la página de contacto y el mapa se mostraba en tres landings específicas. Limpiar en bloque habría roto esas secciones.

La solución que apliqué fue un mu-plugin ligero con condicionales combinados: primero comprobaba si el widget estaba activo en el sitio y después limitaba la carga a las páginas donde ese componente podía aparecer. No se trataba de borrar recursos a ciegas, sino de devolver cada script a su territorio lógico.

// mu-plugins/theme-conditional-assets.php
add_action('wp_enqueue_scripts', 'conditional_theme_widget_assets', 20);

function conditional_theme_widget_assets() {
    // Desencolar los scripts globales del tema
    wp_dequeue_script('theme-maps');
    wp_dequeue_style('theme-maps-css');
    wp_dequeue_script('theme-calendar-init');
    wp_dequeue_style('theme-calendar-css');
    wp_dequeue_script('theme-slider');
    wp_dequeue_style('theme-slider-css');
    wp_dequeue_script('theme-reviews-carousel');

    // Reencolar solo donde cada widget puede aparecer
    if ( is_active_widget(false, false, 'theme_maps_widget', true) && ( is_front_page() || is_page(array('contacto', 'como-llegar', 'actividades-norte')) ) ) {
        wp_enqueue_script('theme-maps');
        wp_enqueue_style('theme-maps-css');
    }

    if ( is_active_widget(false, false, 'theme_calendar_widget', true) && ( is_front_page() || is_singular('actividad') ) ) {
        wp_enqueue_script('theme-calendar-init');
        wp_enqueue_style('theme-calendar-css');
    }

    if ( is_front_page() ) {
        wp_enqueue_script('theme-slider');
        wp_enqueue_style('theme-slider-css');
    }

    if ( is_active_widget(false, false, 'theme_reviews_widget', true) && ( is_front_page() || is_page('contacto') ) ) {
        wp_enqueue_script('theme-reviews-carousel');
    }
}

Usé prioridad 20 en el hook para asegurar que el desencole se ejecutara después del encolado original del tema. Coloqué el archivo en mu-plugins para que sobreviviera a actualizaciones del tema sin depender de un child theme que no existía en el proyecto.

Después de aplicar el cambio, volví a la página de privacidad con DevTools:

// Red - política de privacidad (tras el cambio)
Requests: 21
JS files: 6
CSS files: 4
Transferred: 438 KB
DOMContentLoaded: 1.5s

De 14 archivos JavaScript a 6. De 812 KB a 438 KB. El DOMContentLoaded bajó casi un segundo. La página no quedó desnuda: seguían cargando estilos base, fuentes, analítica y recursos comunes del tema. Pero la parte absurda —los widgets que no pintaban nada allí— ya había desaparecido.

Comprobé la home y las páginas de actividad: todo seguía funcionando. El calendario cargaba, el mapa pintaba, el carrusel rotaba. Los widgets hacían exactamente lo mismo que antes, pero solo donde debían hacerlo.

Validé el resultado en tres navegadores, en móvil y con caché desactivada. También revisé con Query Monitor que no quedaran handles huérfanos ni dependencias rotas. Todo limpio. El sitio pesaba lo que tenía que pesar en cada URL.

Los widgets no estaban rotos. Solo habían aprendido a viajar demasiado.