Como eliminar jQuery del frontend y usar vanilla JS sin romper en WordPress

Contents

Introducción y enfoque general

Eliminar jQuery del frontend de WordPress y mover todo a vanilla JavaScript puede mejorar el rendimiento, reducir la carga de recursos y modernizar la base de código. Pero hacerlo sin romper el tema y los plugins requiere un plan: auditar dependencias, crear sustitutos cuando haga falta, probar progresivamente y mantener una vía de retorno.

Resumen de la estrategia segura

  • Auditar dónde se usa jQuery (tema, plugins, scripts personalizados).
  • No quitar jQuery de golpe: usar enfoque progresivo y condicional.
  • Reemplazar funcionalidades por código vanilla o por pequeños shims sólo cuando sea seguro.
  • Probar en entornos de desarrollo y staging con monitorización de errores (console, Query Monitor).
  • Tener plan de rollback (re-enqueue de jQuery si algo falla).

1. Auditoría: saber quién usa jQuery

Antes de tocar nada, identifica los consumidores de jQuery. Técnicas:

  • Buscar en el código: grep/rg/IDE por (, jQuery(, .on(, .ajax(.
  • Usar Query Monitor (plugin) para ver qué scripts se cargan y dependencias.
  • Revisar consola del navegador para errores relacionados con jQuery tras cambios.
  • Revisar en el frontend: abrir Network → Scripts y ver si jquery o jquery-migrate están cargados y quién los solicita.

2. Enfoques posibles (pros y contras)

  • Dequeue completo: más limpio, pero riesgo alto si plugins dependen de jQuery.
  • Shim mínimo: registrar una librería ligera que provea lo básico (, jQuery) — útil si sólo se usan funciones simples.
  • Solo theme en vanilla: dejar jQuery para plugins y reemplazar scripts del tema por vanilla menor riesgo.
  • Eliminar jQuery-migrate: baja fricción, mejora rendimiento y seguridad sin romper dependencias directas.

3. Cómo eliminar jQuery del frontend (código)

Ejemplo seguro que elimina jQuery sólo en frontend y solo si ningún script registrado requiere explícitamente esa dependencia (comprobación adicional recomendable). Inserta en functions.php de tu tema hijo o plugin de funcionalidad: 

// php
add_action(wp_default_scripts, function(scripts) {
    if (!is_admin()) {
        // Evitar quitar jquery en admin
        if (isset(scripts->registered[jquery])) {
            // Opcional: eliminar migrate también si no es necesario
            if (isset(scripts->registered[jquery-migrate])) {
                scripts->remove(jquery-migrate)
            }
            // Remover jquery del frontend
            scripts->remove(jquery)
        }
    }
})

Nota: wp_default_scripts permite manipular registros antes de que se impriman. Este ejemplo remueve jquery y jquery-migrate en frontend. Sin embargo, si un plugin está registrado con dependencia jquery, WordPress puede registrar la dependencia y lanzar errores si no está disponible. Por eso conviene:

  • Detectar dependencias con wp_scripts()->registered y wp_script_is.
  • O bien registrar un stub (script vacío o shim) para satisfacer dependencias sin cargar la librería completa.

Registrar un shim mínimo (satisfacer dependencias sin jQuery real)

Un shim puede definir window.jQuery y window. con características mínimas si confías en que los consumidores solo usan selectores simples y add/removeClass. A continuación un ejemplo de la estrategia: registrar un archivo jquery-shim.js que define /jQuery como envoltorio alrededor de querySelectorAll y algunos métodos básicos. 

// php
add_action(wp_enqueue_scripts, function() {
    if (is_admin()) return

    // Si decides usar shim en vez de la librería completa:
    wp_register_script(jquery-shim, get_stylesheet_directory_uri() . /assets/js/jquery-shim.js, array(), 1.0, true)

    // Remover jQuery real y encolar shim en su lugar
    wp_deregister_script(jquery)
    wp_enqueue_script(jquery-shim)
})

Contenido de ejemplo para assets/js/jquery-shim.js (muy básico, adaptarlo según lo que realmente necesites): 

// javascript
(function(window, document) {
  use strict

  function (selector, context) {
    context = context  document
    var nodes = context.querySelectorAll(selector)
    // devolver un objeto con métodos comunes
    return new Dollar(nodes)
  }

  function Dollar(nodes) {
    this.nodes = nodes
  }

  Dollar.prototype.each = function(cb) {
    Array.prototype.forEach.call(this.nodes, function(el, idx) {
      cb.call(el, idx, el)
    })
    return this
  }

  Dollar.prototype.addClass = function(name) {
    this.each(function() { this.classList.add(name) })
    return this
  }

  Dollar.prototype.removeClass = function(name) {
    this.each(function() { this.classList.remove(name) })
    return this
  }

  Dollar.prototype.on = function(evt, handler) {
    this.each(function() { this.addEventListener(evt, handler) })
    return this
  }

  Dollar.prototype.off = function(evt, handler) {
    this.each(function() { this.removeEventListener(evt, handler) })
    return this
  }

  // Exponer mínimamente
  window. = window.jQuery = 

})(window, document)

Advertencia: este shim es únicamente para casos muy simples. Muchas librerías y plugins usan API avanzadas de jQuery (promises, .ajax, deferreds, manipulación compleja del DOM, etc.). Un shim insuficiente puede causar fallos silenciosos.

4. Reemplazar funcionalidades comunes: equivalencias jQuery → vanilla

Lista de conversiones frecuentes con ejemplos prácticos.

Document ready

// javascript
// jQuery:
// jQuery(function(){ / ... / })

// Vanilla:
document.addEventListener(DOMContentLoaded, function() {
  // ...
})

Selección y recorrido

// javascript
// jQuery: (.items).each(function(i, el){ ... })
// Vanilla:
document.querySelectorAll(.items).forEach(function(el, i) {
  // ...
})

Agregar/ quitar clases

// javascript
// jQuery: el.classList vs (el).addClass(x)
element.classList.add(mi-clase)
element.classList.remove(mi-clase)
element.classList.toggle(mi-clase)

Manejo de eventos y delegación

// javascript
// jQuery: (parent).on(click, .btn, handler)
// Vanilla:
document.querySelector(#parent).addEventListener(click, function(e) {
  if (e.target.matches(.btn)) {
    handler.call(e.target, e)
  }
})

AJAX con fetch (reemplazando .ajax / .post)

// javascript
// jQuery:
// .post(ajaxurl, data, function(res){ ... }, json)

// Vanilla con fetch:
fetch(ajaxurl, {
  method: POST,
  headers: {
    Content-Type: application/x-www-form-urlencoded charset=UTF-8
  },
  body: new URLSearchParams(data)
})
.then(function(resp){ return resp.json() })
.then(function(json){ / ... / })
.catch(function(err){ console.error(err) })

Serializar formularios

// javascript
// jQuery: (form).serialize()
// Vanilla:
function serializeForm(form) {
  return new URLSearchParams(new FormData(form)).toString()
}

Animaciones simples

Reemplazar fadeIn/fadeOut por transiciones CSS y toggles con classList para mantener rendimiento y accesibilidad. 

/ css /
.fade {
  transition: opacity .25s ease
  opacity: 0
  pointer-events: none
}
.fade.is-visible {
  opacity: 1
  pointer-events: auto
}

5. Localización de scripts (wp_localize_script) y datos desde PHP

wp_localize_script funciona igual con scripts en vanilla conserva su uso para inyectar variables desde PHP. Ejemplo: 

// php
add_action(wp_enqueue_scripts, function() {
    wp_enqueue_script(theme-main, get_stylesheet_directory_uri()./assets/js/main.js, array(), 1.0, true)
    wp_localize_script(theme-main, themeData, array(
        ajaxUrl => admin_url(admin-ajax.php),
        nonce => wp_create_nonce(theme_nonce)
    ))
})

// javascript
// acceder desde vanilla:
fetch(themeData.ajaxUrl, {
  method: POST,
  headers: {Content-Type: application/x-www-form-urlencoded charset=UTF-8},
  body: new URLSearchParams({ action: mi_accion, _ajax_nonce: themeData.nonce })
})

6. Caso práctico: pasar un script del tema a vanilla

Ejemplo: tema que usa jQuery para un toggle de menú. Código jQuery original y su versión en vanilla. 

// javascript
// jQuery original:
// jQuery(function() {
//   (.btn-menu).on(click, function(e) {
//     e.preventDefault()
//     (.nav).toggleClass(is-open)
//   })
// })

// Vanilla:
document.addEventListener(DOMContentLoaded, function() {
  document.querySelectorAll(.btn-menu).forEach(function(btn) {
    btn.addEventListener(click, function(e) {
      e.preventDefault()
      var nav = document.querySelector(.nav)
      if (nav) nav.classList.toggle(is-open)
    })
  })
})

7. Políticas de compatibilidad y polyfills

Antes de eliminar jQuery, evalúa la compatibilidad de navegadores objetivo. Algunas APIs modernas pueden requerir polyfills:

  • Element.prototype.closest y matches
  • classList (antiguos IE)
  • fetch (usar polyfill o fallback a XMLHttpRequest)
  • Promise (para código que use promesas)

Incluir polyfills sólo si realmente necesitas soporte para navegadores antiguos. Para sitios actuales, la mayoría de features funcionan en navegadores modernos.

8. Pruebas y checklist antes de producción

  1. Realizar cambios en entorno de desarrollo y staging.
  2. Activar Query Monitor y revisar warnings/errores JS en consola.
  3. Probar flujos críticos: formularios, carrito (e-commerce), login, widgets dinámicos.
  4. Verificar plugins clave: sliders, galerías, constructores, formularios (Contact Form, WooCommerce etc.).
  5. Probar en varios navegadores y dispositivos móviles.
  6. Medir impacto en carga con Lighthouse, WebPageTest o GTmetrix.
  7. Tener un backup y plan de rollback (re-enqueue de jQuery) listo si algo falla.

9. Errores comunes y cómo solucionarlos

  • Plugins que lanzan Uncaught ReferenceError: jQuery is not defined: registrar shim o no quitar jQuery hasta que el plugin se actualice o tenga alternativa.
  • Funciones avanzadas no disponibles: revisar si usan .Deferred, .when, animate, plugins de terceros en esos casos la migración a vanilla es más compleja o inviable a corto plazo.
  • Problemas con dependencias registradas: algunos scripts están registrados con dependencia jquery. Puedes forzar su re-registro sin dependencia solo si entiendes su comportamiento.

10. Buenas prácticas finales

  • Prioriza eliminar jQuery solo en el tema, mantén jQuery si plugins lo necesitan.
  • Extrae y modulariza tu JavaScript usa ES6 y un bundler (esbuild, webpack, Rollup) si conviene.
  • Usa defer y async en scripts donde sea seguro para mejorar performance.
  • Evita crear shims que imiten toda la API de jQuery mejor migrar funciones concretas a vanilla y mantener jQuery donde su coste de migración sea alto.
  • Documenta los cambios: qué scripts se migraron y por qué, para futuras referencias.

Recursos útiles

Conclusión

Eliminar jQuery del frontend de WordPress es perfectamente viable y beneficioso si se hace de forma planificada: auditar dependencias, migrar gradualmente, usar shims solo cuando sea necesario y probar exhaustivamente. En la mayoría de proyectos modernos, mantener jQuery únicamente para plugins legacy mientras migras el código del tema a vanilla es la estrategia menos arriesgada y más eficiente.


Acepto donaciones de BAT's mediante el navegador Brave 🙂

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *