Carga condicional avanzada de plugins y scripts

Introducción

En WordPress, el modelo por defecto de los plugins es muy simple: si un plugin está activo, WordPress lo carga en cada petición. Da igual que sea una página del frontend, una pantalla del admin, una llamada AJAX o una URL concreta donde ese plugin no aporta nada. Esta «carga global» es cómoda para construir sitios rápido, pero en proyectos medianos y grandes se convierte en una fuente muy habitual de problemas de rendimiento.

Piensa en un eCommerce típico: WooCommerce, un plugin de formularios, SEO, seguridad, optimización de imágenes, analítica, quizá multiidioma y alguna integración externa. Es fácil que todos esos plugins ejecuten código en cada carga de página, incluso cuando la URL solo muestra una entrada del blog. Aunque parte de ese código «solo se inicialice» o haga comprobaciones, sigue consumiendo recursos: incluye archivos PHP, registra hooks, lee opciones y, en muchos casos, añade consultas o lógica extra.

¿En qué se traduce esto en el día a día?

• TTFB más alto, porque PHP tarda más en preparar la respuesta.
• Mayor consumo de RAM, al cargar clases, configuraciones y dependencias que no se usan en esa vista.
• Más procesamiento y, a menudo, más consultas (directas o indirectas) a la base de datos.
• Más riesgo de conflictos, porque cuantos más plugins conviven en la misma petición, más posibilidades hay de colisiones de hooks, scripts duplicados o comportamientos inesperados.

1. Introducción
2. ¿Qué significa «carga condicional»?
3. Carga condicional real de plugins (mu-plugin)
4. Carga condicional de scripts y estilos
5. Comparativa y recomendaciones
6. Conclusión

Y no es solo «una cuestión de velocidad». Un backend más pesado afecta a la experiencia de usuario (sobre todo en páginas sin caché, usuarios logueados, carrito/checkout o admin), al SEO de forma indirecta (un TTFB elevado complica métricas como LCP), al coste de infraestructura (necesitas más CPU/RAM para el mismo tráfico) y a la estabilidad del sitio en picos.

Por eso, dominar la carga condicional suele ser una de las mejores inversiones de tiempo para un desarrollador WordPress: te permite convertir un WordPress «monolítico» en un sistema más modular, donde cada pieza se activa solo cuando hace falta.

En este artículo vamos a ver dos niveles de optimización, de menor a mayor impacto:

1. Carga condicional de scripts y estilos (JS y CSS). Es el primer escalón y suele ser el más rápido de aplicar. El objetivo es que el navegador no descargue assets innecesarios: si un formulario solo aparece en una landing, sus scripts y estilos deberían cargar solo ahí.
2. Carga condicional completa de plugins. Este es el nivel avanzado: evitar que determinados plugins formen parte del stack de ejecución en ciertas rutas o contextos. Lo haremos con un mu-plugin (para que la lógica se ejecute siempre) y el filtro option_active_plugins (y equivalentes si aplica), de forma que WordPress ni siquiera intente cargar esos plugins cuando no son necesarios.

Veremos ejemplos prácticos, buenas prácticas para no romper dependencias (admin, REST, AJAX, cron, usuarios logueados, etc.) y una comparación clara entre «solo optimizar assets» y «sacar un plugin completo de la petición». También veremos plugins que ofrecen enfoques similares y cuándo pueden tener sentido.

El objetivo final es que acabes con una implementación real funcionando en tu sitio y con una mejora medible en WPO: menos carga innecesaria, menos trabajo en el servidor y un WordPress más predecible y estable a medida que el proyecto crece.

¿Qué significa «carga condicional»?

La carga condicional es una técnica de optimización en WordPress que consiste en no cargar lo que no se va a usar en una petición concreta. En vez de asumir que todo el sitio necesita siempre las mismas piezas, decides (con reglas) qué recursos y qué funcionalidades deben activarse en cada contexto.

En la práctica, esta lógica se puede aplicar en dos niveles principales:

1. Solo en el frontend, limitando la carga de scripts y estilos (JS/CSS).
2. A nivel del «stack» de WordPress, impidiendo la carga de plugins completos.

Ambos enfoques son complementarios: el primero reduce peso en el navegador, el segundo reduce trabajo en el servidor.

a) Carga condicional de scripts y estilos (JS/CSS)

Es el enfoque más accesible y, normalmente, el primer paso. La idea es simple: muchos plugins encolan (enqueue) JS y CSS «por defecto» en todas las páginas, aunque el contenido que los necesita solo exista en una o dos URL.

Casos típicos:

• Un formulario (por ejemplo, Contact Form 7) que solo se usa en una página tipo /contacto/, pero sus assets se cargan en todo el sitio.
• Sliders o librerías pesadas que solo aparecen en la home o en una landing.
• Mapas, reproductores o embeds que cargan recursos aunque la página actual no tenga ningún bloque multimedia.

El patrón habitual es encolar el plugin «como siempre» y, después, desencolar (dequeue) sus assets en páginas donde no hacen falta.

Notas importantes para que esto sea fiable:

• La prioridad alta (por ejemplo, 100) ayuda a que tu wp_dequeue_*() se ejecute después de que el plugin haya encolado sus assets.
• Los «handles» (identificadores) no siempre coinciden con el nombre del plugin. Si el dequeue no surte efecto, toca confirmar los handles con herramientas como Query Monitor o inspeccionando el HTML.
• En algunos casos te interesará también wp_deregister_script()/wp_deregister_style() si un theme o plugin re-encola el mismo handle más tarde.

Además de is_page(), tienes varias formas de condicionar la carga:

• is_single(), is_front_page(), is_home(), is_archive().
• is_singular( 'product' ) o is_post_type_archive( 'product' ) (en WooCommerce u otros CPT).
• Detectar shortcodes con has_shortcode() para cargar assets solo si el contenido lo requiere.
• Consultar metadatos con get_post_meta() (por ejemplo, solo cargar un slider si un meta flag está activo).
• Condiciones por plantilla (is_page_template()), por idioma, por rol de usuario, etc.

Ventajas principales:

• Es relativamente fácil de implementar y de revertir.
• Suele mejorar métricas del frontend porque reduces JS/CSS y peticiones innecesarias.
• Baja el número de solicitudes HTTP, el peso de la página y el trabajo del navegador.

Limitaciones (muy importantes):

• El plugin sigue activo.
• Su PHP se carga, registra hooks y puede ejecutar lógica/consultas aunque no se carguen sus assets.
• Normalmente no reduce el TTFB de forma significativa, porque el «coste» del backend sigue existiendo.

b) Carga condicional de plugins (nivel avanzado)

Aquí es donde la optimización se vuelve realmente potente: en vez de quitar solo JS/CSS, evitas que WordPress cargue el plugin completo en esa petición.

La técnica se basa en dos piezas:

• Un mu-plugin (Must Use) para garantizar que tu lógica se ejecuta siempre y lo más temprano posible.
• El filtro option_active_plugins (o equivalentes en multisite site_option_active_sitewide_plugins) para modificar dinámicamente el array de plugins activos antes de que se incluyan.

Un detalle crítico: en el momento en que se filtra option_active_plugins, las condicionales de plantilla como is_page() normalmente todavía no están disponibles (porque la query principal no se ha resuelto). Por eso, para decidir si estás en /contacto/ necesitas basarte en el request (por ejemplo, $_SERVER['REQUEST_URI']) o en condiciones de contexto (admin, REST, AJAX, cron).

Ejemplo de mu-plugin (archivo recomendado: /wp-content/mu-plugins/cl-conditional-plugin-loader.php):

<?php
/**
 * Conditional plugin loader (MU).
 *
 * Drop this file into wp-content/mu-plugins/.
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Check if the current request path matches a given slug.
 *
 * @param string $slug Path slug without slashes.
 * @return bool
 */
function cl_request_is_path( $slug ) {
	if ( empty( $_SERVER['REQUEST_URI'] ) ) {
		return false;
	}

	$path = wp_parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );
	$path = is_string( $path ) ? trim( $path, '/' ) : '';

	return $path === trim( $slug, '/' );
}

/**
 * Remove a plugin from the active plugins array.
 *
 * @param array  $plugins Active plugins.
 * @param string $plugin_file Plugin main file (e.g. plugin-dir/plugin.php).
 * @return array
 */
function cl_unset_active_plugin( array $plugins, $plugin_file ) {
	$key = array_search( $plugin_file, $plugins, true );
	if ( false !== $key ) {
		unset( $plugins[ $key ] );
	}

	return $plugins;
}

add_filter(
	'option_active_plugins',
	function( $plugins ) {
		// Never interfere with wp-admin.
		if ( is_admin() ) {
			return $plugins;
		}

		// Never interfere with cron.
		if ( defined( 'DOING_CRON' ) && DOING_CRON ) {
			return $plugins;
		}

		// Never interfere with AJAX.
		if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) {
			return $plugins;
		}

		// Keep Contact Form 7 only on /contacto/.
		if ( ! cl_request_is_path( 'contacto' ) ) {
			$plugins = cl_unset_active_plugin( $plugins, 'contact-form-7/wp-contact-form-7.php' );
		}

		return $plugins;
	},
	1
);

Qué consigue esto:

• En las URLs que no cumplen la condición, WordPress no incluye el plugin.
• No se ejecutan sus hooks, no se cargan sus clases, no añade consultas ni lógica.
• La mejora suele notarse en memoria, CPU y TTFB, especialmente en sitios con muchos plugins.

Ventajas:

• El plugin no se carga ni se ejecuta, así que el ahorro es real.
• Reduce consumo de RAM/CPU y suele mejorar tiempos de backend.
• Permite reglas más avanzadas: por ruta, por cabeceras, por estado de login, por entorno, etc.

Riesgos y precauciones:

• Puedes romper dependencias si un plugin «A» asume que «B» siempre está activo.
• Hay plugins que afectan globalmente (caché, seguridad, roles, SEO, mu-plugins de hosting) y no conviene condicionarlos sin un análisis serio.
• En multiidioma, la ruta puede cambiar (/es/contacto/, /en/contact/), así que la detección por path debe adaptarse.

Comparativa rápida

• Carga condicional de scripts/estilos: evita JS/CSS innecesario, pero el PHP del plugin sigue ejecutándose.
• Carga condicional de plugins: evita tanto JS/CSS como la ejecución PHP (más impacto, más complejidad).

Lo más efectivo suele ser combinar ambas: primero recortas assets en el frontend (impacto rápido y bajo riesgo) y, cuando ya tienes claro qué plugins solo se usan en zonas concretas, das el salto a cargar plugins completos condicionalmente para una optimización más profunda.

Carga condicional real de plugins (mu-plugin)

Aquí es donde la optimización se vuelve realmente potente. WordPress permite modificar dinámicamente el listado de plugins activos antes de que estos se carguen, a través del filtro option_active_plugins. Dicho de otra forma: en vez de «cargar el plugin y luego intentar que haga menos cosas», puedes conseguir que WordPress ni siquiera lo incluya en esa petición.

Este enfoque es especialmente útil con plugins grandes (WooCommerce, suites de marketing, constructores, integraciones, etc.) o plugins que solo se usan en un conjunto pequeño de URLs (formularios, sliders, landing builders…). Bien aplicado, reduce memoria, CPU y suele bajar el coste de backend (y por tanto el TTFB) en páginas donde esos plugins no aportan nada.

Qué es un mu-plugin

Los MU-Plugins (Must Use Plugins) son archivos PHP ubicados en wp-content/mu-plugins/ que WordPress carga automáticamente en todas las peticiones y antes que los plugins «normales».

Características importantes:

• Se cargan siempre y temprano, por eso son ideales para lógica de «carga condicional».
• No se pueden desactivar desde el escritorio.
• No tienen interfaz de configuración (salvo que tú la construyas en otro plugin/tema).
• Si rompes algo aquí, lo rompes «en todo el sitio», así que hay que ser conservador y probar bien.

Cómo crear uno

1. Entra en la carpeta wp-content/ de tu instalación.
2. Si no existe, crea la carpeta mu-plugins/.
3. Dentro, crea un archivo, por ejemplo: cl-conditional-plugin-loader.php.
4. Añade un código base como el siguiente (ajústalo a tu caso).

Nota clave: en el momento en el que corre option_active_plugins, aún no está resuelta la query principal. Por eso, condicionales tipo is_page() / is_singular() normalmente no son usables aquí. En este punto, lo normal es decidir por:

• Ruta ($_SERVER['REQUEST_URI']), o
• Contexto de ejecución (admin, AJAX, REST, cron), o
• Estado de login/capacidades (si necesitas segmentar por usuario).

Ejemplo práctico de mu-plugin

El ejemplo siguiente mantiene:

• Contact Form 7 solo en /contacto/.
• WooCommerce solo en rutas típicas de tienda.

Incluye también «protecciones» para no interferir con admin, cron y AJAX, y una función de matching de ruta más robusta (evita que te falle por query strings o barras finales).

<?php
/**
 * Plugin Name: Conditional plugin loader (MU)
 * Description: Conditionally loads specific plugins based on request context.
 * Author: Carlos Longarela
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Get normalized request path (no query string, trimmed slashes).
 *
 * @return string
 */
function cl_get_request_path() {
	if ( empty( $_SERVER['REQUEST_URI'] ) ) {
		return '';
	}

	$path = wp_parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );
	$path = is_string( $path ) ? $path : '';

	return trim( $path, '/' );
}

/**
 * Check whether current request path matches any of the provided prefixes.
 *
 * Example: prefix "tienda" matches "tienda" and "tienda/categoria".
 *
 * @param string[] $prefixes Prefixes without leading slash.
 * @return bool
 */
function cl_path_has_any_prefix( array $prefixes ) {
	$path = cl_get_request_path();
	if ( '' === $path ) {
		return false;
	}

	foreach ( $prefixes as $prefix ) {
		$prefix = trim( (string) $prefix, '/' );
		if ( '' === $prefix ) {
			continue;
		}

		if ( 0 === strpos( $path, $prefix ) ) {
			return true;
		}
	}

	return false;
}

/**
 * Remove a plugin from the active plugins array.
 *
 * @param array  $plugins Active plugins.
 * @param string $plugin_file Plugin main file (e.g. plugin-dir/plugin.php).
 * @return array
 */
function cl_unset_active_plugin( array $plugins, $plugin_file ) {
	$key = array_search( $plugin_file, $plugins, true );
	if ( false !== $key ) {
		unset( $plugins[ $key ] );
	}

	return $plugins;
}

add_filter(
	'option_active_plugins',
	function( $plugins ) {
		// Safety: do not interfere with wp-admin.
		if ( is_admin() ) {
			return $plugins;
		}

		// Safety: do not interfere with cron.
		if ( defined( 'DOING_CRON' ) && DOING_CRON ) {
			return $plugins;
		}

		// Safety: do not interfere with AJAX.
		if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) {
			return $plugins;
		}

		// If you rely on REST endpoints, consider skipping changes for REST too.
		if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
			return $plugins;
		}

		// Keep Contact Form 7 only on /contacto/.
		$on_contact_page = cl_path_has_any_prefix( array( 'contacto' ) );
		if ( ! $on_contact_page ) {
			$plugins = cl_unset_active_plugin( $plugins, 'contact-form-7/wp-contact-form-7.php' );
		}

		// Keep WooCommerce only on shop-related routes.
		$woo_prefixes = array(
			'tienda',
			'carrito',
			'checkout',
			'finalizar-compra',
			'mi-cuenta',
			'producto',
			'wc-api',
		);

		$is_woo_request = cl_path_has_any_prefix( $woo_prefixes );
		if ( ! $is_woo_request ) {
			$plugins = cl_unset_active_plugin( $plugins, 'woocommerce/woocommerce.php' );
		}

		return $plugins;
	},
	1
);

Detalles a tener en cuenta en el ejemplo:

• El matching por prefijo permite cubrir subrutas (por ejemplo tienda/categoria/...).
• Las rutas de WooCommerce varían según idioma, slugs y configuración. Lo normal es adaptar ese array a tu proyecto.
• Si en tu theme tienes un minicart global, shortcodes de productos en el blog o bloques que dependen de WooCommerce, desactivar WooCommerce fuera de la tienda puede romper esos componentes. En ese caso, o mantienes WooCommerce en más rutas, o aplicas la técnica a plugins menos «transversales».

Lógicas comunes que puedes usar

Una vez montado el mu-plugin, la parte importante es decidir bien las condiciones.

Por ruta:

• $_SERVER['REQUEST_URI'] (recomendado en este punto del ciclo) y parseo con wp_parse_url().
• Listas de prefijos por secciones: /blog/, /contacto/, /tienda/, etc.

Por entorno:

• Basado en $_SERVER['HTTP_HOST'] o constantes propias (WP_ENVIRONMENT_TYPE, constantes personalizadas, etc.).
• Ejemplo típico: cargar un plugin de debugging solo en staging.

Por usuario:

• is_user_logged_in() y current_user_can() (pero ojo: cuanto más temprano decidas, más conservador debes ser, sobre todo si hay cachés intermedias).
• Antes de usar is_user_logged_in() y current_user_can() debemos cargar pluggable.php

require ( ABSPATH . WPINC . '/pluggable.php' );

Por agente de usuario:

• Detección de bots/crawlers o apps internas. Aquí conviene ser prudente para no romper indexación o previsualizaciones.

Cómo ver qué plugins quedan activos (debug)

Durante las pruebas es útil inspeccionar el array $plugins, pero hazlo de forma segura:

• Limítalo a administradores.
• Evita dejarlo activo en producción.
• Imprime con wp_die() para cortar la salida de una forma controlada.

En este ejemplo usamos el parámetro ?cl_show_plugins en la URL para ver la lista de plugins activos):

<?php
if ( isset( $_GET['cl_show_plugins'] ) && current_user_can( 'manage_options' ) ) {
	echo '<pre>';
	print_r( $plugins ); // phpcs:ignore WordPress.PHP.DevelopmentFunctions
	echo '</pre>';
	wp_die();
}

Ventajas

• Ahorro real de recursos: si un plugin no se carga, no ejecuta el PHP, no registra hooks ni añade lógica.
• Mejoras medibles: suele reducir la memoria y la CPU; en páginas sin caché puede reflejarse en un menor TTFB.
• Menos superficie de conflicto: menos plugins coexistiendo en la misma petición.
• Muy útil en proyectos personalizados, multisites y entornos con reglas distintas (producción/staging).

Precauciones

Esta técnica da mucho control, pero también puede romper cosas si se aplica «a lo bruto». Algunas reglas básicas para evitar esto:

• No empieces condicionando plugins críticos (caché, seguridad, roles/capabilities, login, backups, etc.) sin un análisis claro.
• Empieza por plugins «aislados» (formularios, sliders, embeds) y ve escalando.
• Ten en cuenta REST, AJAX y cron: si un plugin se necesita en esos contextos, no lo desactives ahí.
• Si tu WordPress es multiidioma, las rutas pueden cambiar (/es/contacto/, /en/contact/). Ajusta el matching para contemplarlo.

Aplicado con cabeza, ya que el salto respecto a «solo hacer dequeue de assets» es grande: aquí no estás recortando el frontend, estás recortando el backend y el stack completo de ejecución.

Condiciones habituales para la descarga de plugins (mu-plugin)

A continuación tienes un listado rápido de condiciones típicas que puedes usar dentro de tu mu-plugin (por ejemplo, antes de hacer unset del plugin en option_active_plugins). Son checks pensados para ejecutarse temprano, sin depender de is_page().

URL (ruta)

• Obtener el path y compararlo por igualdad o por prefijo.
• Condición: «si la ruta no empieza por tienda/, descarga WooCommerce»

Usuario

• Estado de login: is_user_logged_in().
• Capacidades: current_user_can( 'manage_options' ).
• Condición: «si no está logueado, descarga el plugin de área privada»

Fecha y hora

• Hora local con wp_date() o current_time( 'timestamp' ) (según necesites).
• Condición: «si estamos fuera del horario laboral, descarga el plugin de chat/soporte»

Cabeceras

• Leer las cabeceras con getallheaders() si está disponible (o $_SERVER['HTTP_*']).
• Condición: «si no existe X-Preview: 1, descarga el plugin de previsualización»

IP

• Detectar IP real con cuidado (si hay proxy/CDN): priorizar HTTP_CF_CONNECTING_IP, luego HTTP_X_FORWARDED_FOR (primer valor), luego REMOTE_ADDR.
• Condición (ejemplo rápido de check): «si la IP no está en una lista permitida, descarga el plugin»

País

• Si usas Cloudflare: $_SERVER['HTTP_CF_IPCOUNTRY'] (código ISO, p. ej. ES).
• Alternativa: GeoIP del servidor o del CDN (si existe), pero mejor evitar llamadas externas aquí.
• Condición: «si el país no es ES, descarga un plugin de métodos de pago locales»

Tipo de petición (contexto técnico)

• Admin: is_admin()
• AJAX: defined( 'DOING_AJAX' ) && DOING_AJAX
• Cron: defined( 'DOING_CRON' ) && DOING_CRON
• REST: defined( 'REST_REQUEST' ) && REST_REQUEST
• WP-CLI: defined( 'WP_CLI' ) && WP_CLI
  Uso típico: «no descargar plugins que necesitas para cron/REST aunque no los uses en frontend»

Método HTTP

• $_SERVER['REQUEST_METHOD'] (GET, POST, etc.)
  Uso típico: mantener un plugin solo si hay POST (formularios, checkout) y descargarlo en GET.

Query string / flags de depuración

• isset( $_GET['preview'] ), isset( $_GET['elementor-preview'] ), isset( $_GET['fl_builder'] ), etc.
  Uso típico: evitar desactivar cosas durante previsualizaciones o builders.

Referer

• wp_get_referer() o $_SERVER['HTTP_REFERER'] (si existe)
  Uso típico: mantener un plugin si vienes de una ruta concreta (poco común, pero útil en flujos).

Cookie

• isset( $_COOKIE['mi_cookie'] )
  Uso típico: carga condicional por estado (A/B testing, consentimiento, usuario con carrito, etc.). Ojo con cachés.

Host/subdominio

• $_SERVER['HTTP_HOST']
  Uso típico: multisubdominios (por ejemplo tienda.dominio.com vs blog.dominio.com) o separar staging/producción.

Protocolo / HTTPS

• is_ssl() o $_SERVER['HTTPS']
  Uso típico: mantener plugins de seguridad/redirecciones solo en ciertos escenarios (normalmente no lo recomiendo, pero existe).

Idioma (si va en la URL)

• Detección por path: es/..., en/...
  Uso típico: cargar plugins condicionalmente por mercados cuando cada idioma es un país (si usas rutas /es/, /pt/, etc.).

Rol/capacidad (más fino que “logueado”)

• current_user_can( 'edit_posts' ), current_user_can( 'manage_woocommerce' )
  Uso típico: cargar plugins de edición extra solo para editores/admins, y descargarlos para visitantes.

Tipo de dispositivo (a través de headers)

• wp_is_mobile() (depende de UA, no es infalible)
  Uso típico: carga condicional un plugin pesado de animaciones o chat solo en desktop (con precaución).

“Modo mantenimiento” o “modo auditoría”

• Constante propia, por ejemplo CL_MAINTENANCE_MODE, o variable de entorno.
  Uso típico: desactivar plugins no esenciales durante una ventana de mantenimiento o auditoría.

Condición sobre cabeceras de CDN/proxy

• Cloudflare: HTTP_CF_RAY, HTTP_CF_VISITOR, HTTP_CF_IPCOUNTRY
  Uso típico: decisiones basadas en presencia de CDN (por ejemplo, si no estás detrás de Cloudflare, no aplicar ciertas reglas).

Carga condicional de scripts y estilos

Aunque no es tan «profunda» como descargar plugins completos, la carga condicional de scripts y estilos es una de las formas más rápidas y efectivas de mejorar el rendimiento del frontend. En muchos sitios, sobre todo cuando se han detectado problemas en Core Web Vitals, el cuello de botella no está tanto en el servidor como en el navegador: demasiados JS/CSS, demasiadas peticiones, demasiadas dependencias y, en general, demasiadas cosas cargándose aunque esa página no las use.

La idea es sencilla: si en una URL no existe un formulario, un slider, un mapa o una funcionalidad concreta, no tiene sentido que esa URL arrastre sus assets.

¿Qué hace exactamente esta técnica?

Permite evitar que WordPress cargue determinados archivos JavaScript y hojas de estilo CSS añadidos por plugins o por el tema en páginas donde no son necesarios.

Esto se traduce normalmente en:

• Menos peticiones HTTP (y menos trabajo de red).
• Menos bytes descargados.
• Menos CSS que el navegador tiene que parsear y aplicar.
• Menos JS que el navegador tiene que parsear, compilar y ejecutar.

Y con ello, suele impactar directamente en métricas como:

• LCP (Largest Contentful Paint), porque reduces recursos que compiten por ancho de banda o bloquean el renderizado.
• FCP (First Contentful Paint), porque hay menos bloqueos iniciales.
• CLS (Cumulative Layout Shift), especialmente si eliminas CSS/JS que inserta elementos tarde o recalcula alturas.

Importante: el impacto exacto depende de qué elimines. Quitar un CSS pequeño que ya está cacheado no cambia gran cosa; quitar un JS pesado con dependencias y ejecución temprana sí.

Ejemplo práctico con Contact Form 7

Uno de los casos más comunes es evitar que Contact Form 7 cargue sus archivos en páginas donde no hay formularios.

<?php
add_action(
	'wp_enqueue_scripts',
	function() {
		if ( ! is_page( 'contacto' ) ) {
			wp_dequeue_script( 'contact-form-7' );
			wp_dequeue_style( 'contact-form-7' );
		}
	},
	100
);

Por qué la prioridad 100 es clave: porque asegura que tu callback se ejecute después de que el plugin haya encolado (enqueue) esos assets. Si usas una prioridad baja, puedes intentar hacer wp_dequeue_*() antes de que el plugin haya registrado su script/estilo, y entonces no pasa nada.

Dos matices prácticos:

• A veces el handle no es exactamente contact-form-7. Si no funciona, lo normal es que el plugin use otros handles (o encole condicionalmente por su cuenta). Por eso conviene confirmarlo.
• En algunos casos, además de wp_dequeue_*(), podrías necesitar wp_deregister_*() si algo vuelve a encolar ese mismo handle más adelante.

Detectar qué eliminar: los handles

Para poder hacer dequeue necesitas identificar los handles reales de cada script y estilo. Herramientas útiles:

• Query Monitor (plugin gratuito): suele ser la forma más rápida de ver scripts/estilos encolados, dependencias y de dónde vienen (tema o plugin).
• DevTools del navegador: pestaña «Network» para localizar recursos, tamaños y tiempos.
• Plugins como Asset CleanUp o Perfmatters en modo debug (sirven para mapear assets por URL).

Una vez identificados los handles, puedes realizar su carga condicional según las reglas.

Ejemplo típico: recortar los assets de WooCommerce fuera de la tienda

En muchos proyectos, parte del CSS y del JS de WooCommerce se carga en páginas donde no se necesita. Un ejemplo sencillo es retirar los estilos base y «cart fragments» fuera de las fichas y de las páginas de la tienda.

<?php
add_action(
	'wp_enqueue_scripts',
	function() {
		if ( ! is_singular( 'product' ) && ! is_shop() && ! is_cart() && ! is_checkout() ) {
			wp_dequeue_style( 'woocommerce-layout' );
			wp_dequeue_style( 'woocommerce-smallscreen' );
			wp_dequeue_style( 'woocommerce-general' );

			wp_dequeue_script( 'wc-cart-fragments' );
		}
	},
	100
);

Notas:

• Aquí sí usamos condicionales como is_shop() / is_cart() / is_checkout() porque ya estamos en wp_enqueue_scripts y la query principal está resuelta.
• wc-cart-fragments es un clásico: útil para un minicart dinámico, pero puede ser caro en el frontend. Si tu theme no depende de ello fuera de páginas de compra, puede merecer la pena retirarlo.

Carga bajo demanda en vez de «dequeue»

A veces no te interesa quitar assets que el plugin encola, sino evitar que se encolen por defecto y cargarlos solo cuando se detecta el caso real.

Ejemplo típico: un slider que solo se usa en la home con un shortcode.

<?php
add_action(
	'wp_enqueue_scripts',
	function() {
		global $post;

		if ( isset( $post ) && has_shortcode( (string) $post->post_content, 'slider_shortcode' ) ) {
			wp_enqueue_script( 'slider-script' );
			wp_enqueue_style( 'slider-style' );
		}
	},
	20
);

Este enfoque tiene varias ventajas:

• Mantienes el sitio ligero sin perder funcionalidad.
• Si el contenido cambia (por ejemplo, el shortcode se elimina), los assets dejan de cargarse automáticamente.

Y también una limitación práctica: si el plugin encola «siempre» sus assets, tú no puedes impedirlo con wp_enqueue_*(); en ese caso toca hacer wp_dequeue_*() (o cambiar el comportamiento del plugin si ofrece filtros).

Limitaciones reales de este enfoque

Esta técnica es muy útil, pero hay que tener claro lo que no hace:

• No impide que el plugin esté activo.
• El PHP del plugin se sigue cargando y ejecutando.
• Sus hooks siguen registrándose.
• Puede seguir afectando a consultas y a lógica del backend (aunque tú no cargues el JS/CSS).

Por eso, para realizar una optimización profunda del servidor (TTFB, CPU, memoria), el siguiente nivel es cargar plugins completos de forma condicional con un mu-plugin.

Cuándo usar esta técnica

Encaja especialmente bien en:

• Sitios con muchos plugins donde el frontend se ha vuelto pesado.
• Casos en los que no puedes eliminar un plugin (por negocio), pero sí limitar su impacto.
• Proyectos donde quieres mejorar las métricas del frontend sin tocar la arquitectura del backend.
• Es el primer paso lógico tras una auditoría: es ligera, relativamente segura, y suele dar resultados rápidos.

En resumen, la carga condicional de scripts y estilos es una herramienta de alto impacto y bajo riesgo cuando se aplica con método: identificar handles, definir reglas por tipo de contenido y validar que no rompes dependencias visuales o interacciones en páginas concretas.

Comparativa y recomendaciones

Después de ver las dos técnicas principales, toca compararlas con calma y escoger una estrategia realista: cuándo tiene sentido usar cada una, qué riesgos asumes y cómo plantear una adopción progresiva sin romper el sitio.

Comparativa técnica

En términos simples, «dequeue de assets» recorta lo que llega al navegador, mientras que «descarga condicional de plugins» recorta el trabajo del servidor. Por eso, aunque ambas pueden mejorar el rendimiento, lo hacen en capas distintas.

Una lectura práctica de esta tabla:

• Si tu problema principal es que el frontend es «pesado» (muchos JS/CSS), empieza por los assets.
• Si tu problema principal es el backend (TTFB alto, CPU/RAM altos, páginas sin caché lentas), el salto está en cargar los plugins condicionalmente.
• En proyectos grandes, casi siempre terminas combinando ambas.

Estrategia recomendada

Una estrategia segura y escalable suele ser incremental:

1. Empieza por controlar scripts y estilos.

Identifica los recursos pesados y quítalos de las páginas donde no se usan con wp_dequeue_script() y wp_dequeue_style(). Esto suele ser:

• Rápido de implementar.
• Fácil de validar visualmente.
• Reversible.

2. Audita qué plugins «aportan» por ruta.

Antes de descargar losplugins, necesitas saber qué parte del sitio depende de qué plugin. Lo normal es agruparlos por secciones:

• Blog y contenidos.
• Tienda (producto, categoría, carrito, checkout, mi cuenta).
• Landings y campañas.
• Área privada / membresía.
• Admin, REST, AJAX y cron.

3. Aplica descarga condicional de plugins en mu-plugins.

Construye condiciones robustas (rutas, contextos, entorno, usuario) y empieza por plugins «aislados», por ejemplo:

• Formularios (si solo existen en una o dos páginas).
• Sliders y builders de landing.
• Integraciones específicas (CRM, feeds) si no afectan a todo el sitio.

Y deja para más tarde (o directamente evita) plugins transversales sin un análisis serio: seguridad, caché, login, roles/capabilities, etc.

4. Combina ambas técnicas.

• El control de los scripts y de los estilos te da precisión visual.
• La descarga de los plugins te da eficiencia de ejecución.

Aplicadas juntas, reducen tanto el peso de la página como el coste del servidor.

Buenas prácticas para ambos enfoques

Estas prácticas te ahorran problemas y hacen que el sistema sea mantenible.

Funciones pequeñas y bien nombradas

Si lo haces en código (y especialmente en mu-plugins), es mejor dividirlo en funciones claras:

• cl_disable_plugins_on_blog()
• cl_disable_woocommerce_on_non_shop_routes()
• cl_dequeue_contact_form_assets()

La ventaja es que el día que algo se rompa, vas a poder localizar rápido qué regla está afectando.

Condiciones seguras por entorno

Si tienes staging/local, apóyate en:

• WP_ENVIRONMENT_TYPE (si lo tienes configurado).
• WP_DEBUG.
• Constantes propias.

Por ejemplo: permitir debug de plugins o «mostrar qué queda activo» solo en staging.

Registro y trazabilidad

Conviene tener alguna forma de saber qué está pasando:

• Un log mínimo con error_log() cuando estás probando.
• Un modo debug activable por query string, pero restringido a administradores.
• Documentar cada regla: qué plugin afecta, en qué rutas y por qué.

Automatiza validaciones en sitios complejos

Cuando hay muchas reglas, probar «a mano» se vuelve lento. Una forma simple es automatizar checks con curl o scripts, por ejemplo:

• Comprobar que URLs clave devuelven 200.
• Comprobar que páginas de compra cargan lo necesario.
• Revisar que el admin no se rompe.

No hace falta montar un CI enorme (Integración Continua): con 10–20 URLs críticas ya detectas la mayoría de roturas.

Evita condicionales ambiguas

Reglas genéricas tipo «si la URL contiene shop» pueden fallar por:

• Slugs en otros idiomas.
• Subrutas.
• Query strings.
• Redirecciones.

Mejor basarte en rutas normalizadas (path sin query) y prefijos controlados, como en el mu-plugin.

Herramientas comerciales: pros y contras

Hay plugins que ofrecen una interfaz para aplicar parte de estas optimizaciones sin tocar código. Los más habituales en este terreno son:

• Perfmatters: suele incluir opciones para carga condicional de scripts, desactivar emojis, limitar fuentes externas y otras optimizaciones relacionadas. Tiene un modo de activar como mu-plugin.
• Asset CleanUp: muy centrado en desactivar scripts y estilos por URL, tipo de contenido, etc., con un modo de inspección cómodo.
• Plugin Organizer: orientado a ordenar y carga condicional de activación de plugins en distintos contextos.

Ventajas

• No necesitas escribir código.
• Visualizas mejor qué se carga y dónde.
• En proyectos de clientes, facilita que alguien no técnico pueda entender los ajustes (aunque no debería tocarlo sin criterio).

Limitaciones

• Añaden su propia carga (más hooks, más opciones, más lógica).
• Algunas reglas avanzadas (por cabeceras, entorno, condiciones muy específicas) son más complicadas o directamente no están.
• En muchos casos, lo que hacen es recortar assets o modular comportamientos, pero no siempre descargan por completo la ejecución PHP del plugin.
• En sitios ya muy optimizados, el sobrecoste de estas herramientas puede comerse parte del beneficio.

La lectura correcta aquí no es «herramienta mala o buena», sino: qué equilibrio entre ventajas y desventajas te conviene. En proyectos sin perfil técnico, pueden ser útiles. En proyectos donde buscas el máximo control y la mínima carga, el enfoque en mu-plugin suele ser más limpio.

Conclusión

La descarga condicional de plugins ofrece una ventaja clara en sitios con muchos recursos: recorta la ejecución real y reduce el coste del servidor. Tiene una curva de aprendizaje mayor y un riesgo algo más alto, pero a cambio te da un nivel de control que no consigues solo con wp_dequeue_*().

Por otro lado, desactivar scripts y estilos sigue siendo una técnica muy valiosa y complementaria: aporta mejoras rápidas en el frontend y suele ser el primer paso en una auditoría de rendimiento.

Combinadas, ambas técnicas forman la base de una estrategia de WPO profesional y escalable: menos peso visual, menos trabajo backend y un WordPress más modular.

Optimizar WordPress va bastante más allá de instalar un plugin de caché o comprimir imágenes. Esas medidas ayudan, pero muchas veces el verdadero «suelo» de rendimiento está en algo más básico: controlar qué se carga, cuándo se carga y por qué se carga.

En WordPress, el comportamiento por defecto tiende a ser global: activas un plugin y pasa a formar parte del stack de ejecución de casi cualquier petición. Con el tiempo, esto deriva en sitios que funcionan, sí, pero arrastran una carga innecesaria en muchas URL. La carga condicional (tanto de scripts/estilos como de plugins) te permite romper ese patrón y volver a un enfoque más modular: cada sección del sitio carga lo que necesita y nada más.

Cuando implementas carga condicional de forma correcta, el impacto suele notarse en varios frentes:

• Reduces el consumo de recursos del servidor (CPU y memoria) al evitar ejecutar código que no aporta nada en esa ruta.
• Aceleras el backend y el frontend: menos trabajo en PHP y menos recursos que descargar y ejecutar en el navegador.
• Mejoras métricas como Core Web Vitals y, en escenarios sin caché, reduces el TTFB.
• Disminuyes el riesgo de errores por conflictos entre plugins, porque hay menos piezas compitiendo en la misma petición.
• Consigues un entorno más predecible, estable y escalable: sabes qué se está ejecutando en cada tipo de página.

¿Por dónde empezar?

Si quieres aplicarlo sin convertirlo en una «operación de alto riesgo», lo ideal es seguir un orden lógico.

1. Audita tus plugins y su uso real.

Hazte una pregunta simple: ¿qué plugins son imprescindibles en cada sección?

• Blog y contenidos.
• Tienda (producto, categoría, carrito, checkout, mi cuenta).
• Landings y campañas.
• Área privada.
• Admin / REST / AJAX / cron.

Este mapa te da claridad para decidir qué se puede recortar y dónde.

2. Identifica scripts y estilos innecesarios en el frontend.

Empieza por la parte «fácil»:

• Localiza assets que se cargan en todo el sitio, pero solo se usan en una o dos páginas.
• Aplica wp_dequeue_script() y wp_dequeue_style() con condiciones claras.

Aquí ya puedes conseguir mejoras visibles sin tocar la arquitectura del stack de plugins.

3. Implementa un mu-plugin para descargar plugins completos.

Cuando ya tienes claro qué funcionalidades están aisladas, da el salto al nivel avanzado:

• Crea un MU-plugin.
• Define condiciones robustas por ruta, entorno, usuario o contexto.
• Empieza por plugins «aislados» (formularios, sliders, integraciones puntuales) antes de tocar piezas críticas.

4. Mide y valida.

Mide antes y después con herramientas como:

• GTmetrix o PageSpeed Insights (sobre todo para el impacto en el frontend).
• Query Monitor (para ver queries, hooks, scripts/estilos y comportamiento general).

Y valida siempre las rutas clave: home, blog, una página de contenido, tienda (si la hay), carrito/checkout y la zona de administración.

Herramientas comerciales vs enfoque con mu-plugins

Las herramientas comerciales pueden facilitar mucho la parte de desactivar scripts y estilos, sobre todo en proyectos de clientes donde no quieres tocar código. Sin embargo, si el objetivo es el máximo control y el mínimo overhead, el enfoque con mu-plugins suele ser el que ofrece la mejor relación entre rendimiento y precisión.

No es tan accesible para usuarios noveles, porque exige pensar en condiciones y dependencias, pero para desarrolladores o perfiles técnicos es una ventaja estratégica clara: tú decides qué entra en cada petición y qué no.

Y quédate con esta idea, porque resume bien el valor real de todo lo anterior: cada plugin que no se carga es un conjunto de hooks menos, una parte de lógica menos y, muchas veces, unos milisegundos ganados.

Cuanto más control tengas sobre la carga de tu WordPress, más rápido, seguro y eficiente será.

No esperes a que el proyecto «se vuelva lento» o a que el cliente se queje: si montas esta base desde el inicio (o la introduces de forma progresiva), estarás construyendo sitios que se sienten sólidos desde el primer clic.