Durante años, una recomendación clásica de WPO fue minificar el JavaScript del sitio.

La lógica era simple: si quitas espacios, comentarios y saltos de línea, el archivo pesa menos y, en teoría, la web carga más rápido.

Pero el contexto ha cambiado. Con HTTP/2/3, compresión moderna y mejores prácticas de carga, minificar JS ya no mueve la aguja como antes.

Analiza tu web WordPress gratis en 1 minuto y recibe un informe con los fallos de rendimiento.

¿Qué significa minificar JavaScript?

Minificar JS es eliminar caracteres innecesarios del código: espacios, tabulaciones, comentarios y, a veces, acortar nombres locales.

El objetivo: reducir el tamaño de transferencia del/los archivo(s).

Ojo: no es lo mismo que combinar el JavaScript de WordPress en uno.

¿Por qué antes era tan buena idea?

En la era de conexiones lentas y sin Brotli/GZIP bien extendidos, cada KB contaba.

Minificar JS solía dar mejoras visibles, sobre todo cuando se cargaban muchos ficheros pequeños.

¿Qué ha cambiado ahora?

Con las tecnologías actuales, el impacto de la minificación pura se reduce:

• La compresión del servidor/CDN ya elimina gran parte del “aire” del archivo.
• HTTP/2/3 maneja mejor múltiples recursos en paralelo.
• Muchas veces el cuello de botella es cómo y cuándo se ejecuta el JS, no si pesa 5 KB menos.
• El riesgo de romper funcionalidades con minificaciones agresivas sigue existiendo (especialmente si hay doble minificación: plugin + CDN).

En resumen: minificar ayuda, pero rara vez es la palanca principal.

Problemas habituales al minificar JS en WordPress

• Retorno decreciente: el ahorro real de peso suele ser pequeño frente a Brotli/GZIP.
• Conflictos y roturas: ciertos temas/plugins fallan si se reordena o se “uglifica” demasiado.
• Doble trabajo: minificar en el plugin y otra vez en el CDN genera errores difíciles de rastrear.
• Falsa sensación de optimización: un JS minificado no arregla INP/LCP si el script se ejecuta antes de tiempo o bloquea el hilo principal.

Alternativas modernas (que suelen rendir más)

En vez de obsesionarte con la minificación, prioriza el cuándo y el cuánto JavaScript cargas:

• defer / async en scripts no críticos para no bloquear el render.
• Eliminar JS no usado (plugins que no aportan o módulos que no se utilizan).
• Retrasar JS no esencial (analytics, chat, widgets sociales) hasta interacción o después de la pintura principal.
• Split/carga condicional: cargar solo el JS necesario por plantilla o tipo de página.
• Reducir dependencias: menos librerías, menos peso y menos ejecución.
• CDN con Brotli y buen TTFB para servir rápido lo que sí sea imprescindible.
• Usar herramientas tipo Perfmatters / WP Rocket para orquestar diferidos, retrasos y exclusiones con cabeza.

Entonces… ¿minificar o no minificar?

Depende.

• En sitios antiguos, con JS pesado y sin compresión activa, sí puede aportar.
• En instalaciones actuales y bien configuradas, minificar pasa a segundo plano frente a diferir/retrasar, podar JS y mejorar el TTFB.

Conclusión

Minificar JavaScript ya no es la “bala de plata” que era hace años.

Sigue siendo una buena práctica para optimizar el JavaScript de WordPress, pero los saltos grandes de rendimiento llegan al cargar menos JS, más tarde y de forma inteligente.

Primero optimiza qué ejecutas y cuándo; luego, si todo está estable, minifica como ajuste final.