Cuántos plugins son demasiados: el peso real, no el número

Por qué el número de plugins engaña, la auditoría de una hora (inventario, perfilado, carga condicional) y la dieta permanente con reglas de entrada.

«¿Cuántos plugins son demasiados?» es la pregunta equivocada con respuesta famosa: no existe un número: existe un peso: hay webs ágiles con cuarenta plugins y tortugas con doce: lo que cuenta es qué hace cada uno y cuándo lo hace: cómo se mide el coste real de tus plugins y la dieta para adelgazar sin perder funciones.

Por qué el número engaña

Un plugin es código que se ejecuta: el de tres líneas que añade un ajuste cuesta cero: el constructor visual o la suite «todo en uno» cargan scripts, estilos y consultas en cada visita: diez plugins quirúrgicos pesan menos que tres mastodontes: y el coste se reparte en tres facturas distintas: el frontal (scripts y CSS que el visitante descarga), el servidor (consultas y PHP en cada carga: el TTFB) y el mantenimiento (cada plugin es superficie de ataque y de conflicto: la factura de seguridad).

La auditoría de plugins en una hora

  • Inventario con pregunta: lista todo lo instalado y pregunta a cada uno «¿qué función da y la uso?»: los muertos (desactivados, redundantes, instalados para una prueba de 2023) se borran hoy: desactivado no es inocuo: es código sin vigilar.
  • Pesa los vivos: un perfilador de rendimiento (Query Monitor para mirar de cerca: o el diagnóstico de tu suite de velocidad) señala qué plugins cargan qué en el frontal y cuáles comen servidor: los dos o tres culpables habituales saltan a la vista.
  • Carga condicional: el ajuste fino del oficio: el plugin del formulario solo necesita cargar en la página de contacto: las herramientas de gestión de activos descargan scripts donde no tocan: media tonelada de frontal se va por aquí.
  • Reemplazos quirúrgicos: la función concreta de la suite enorme suele existir como plugin pequeño o como snippet de diez líneas: el camino del reemplazo está en snippets sin plugins.

La dieta permanente: reglas de entrada

El peso se mantiene con aduana: antes de instalar, tres preguntas: ¿lo resuelve el theme, el núcleo o un snippet? ¿el plugin está vivo (actualizaciones, soporte, instalaciones)? ¿qué carga en el frontal? (se mira antes/después con la pestaña de red o el perfilador): y la regla de oro de las suites: una por categoría: un SEO, una caché, una seguridad: los solapamientos no suman protección: suman peso y conflictos: el stack de referencia está en plugins imprescindibles.

Preguntas frecuentes

¿Los plugins desactivados ralentizan la web?
No se ejecutan, así que no pesan en la carga: pero ocupan, se desactualizan y algún archivo suyo sigue accesible: son riesgo de seguridad sin beneficio: la política sana es no acumular: lo que no vuelve en un mes, se borra (reinstalar cuesta un clic).
¿Cómo sé qué plugin me está frenando?
Mide, no adivines: el perfilador enseña consultas y tiempos por plugin, y la prueba bruta (desactivar en staging por mitades midiendo) localiza al culpable en minutos: las listas de «plugins lentos» de internet orientan: tu web concreta decide.
¿Las suites todo-en-uno son siempre malas?
No: una suite bien hecha que usas entera puede pesar menos que cinco piezas sueltas: el problema es la suite de la que usas el 10%: pagas el 100% del peso: la pregunta no es suite sí o no: es cuánto de lo que carga estás usando.

Por dónde seguir

El contexto completo de velocidad está en acelerar WordPress: el stack mínimo de referencia, en plugins imprescindibles: y la vía de reemplazo ligero, en snippets y functions.php.