No es cuántos plugins tienes. Es qué hacen en cada página.
Un plugin de formularios puede ser perfecto y estar cargando su CSS y su JavaScript en la portada, en el blog y en el checkout, donde no se usa. Ese es el problema: no el número, sino el reparto.
Mide antes de tocar. Apunta el TTFB y el peso de una página concreta, desactiva plugins por grupos en una copia, vuelve a medir y compara. Si no hay copia, no lo hagas en producción a media mañana.
Cómo se nota un plugin pesado
No siempre se nota en la portada. A veces la home vuela y la ficha de producto se arrastra, porque el plugin solo se activa ahí. O al contrario: carga en todas partes porque su desarrollador lo enganchó a `init` y no se molestó en condicionarlo.
Estas son las señales que suelo encontrar:
- El TTFB sube antes de que el navegador reciba nada. Eso es PHP y base de datos, no imágenes.
- Muchos archivos CSS y JS de plugins que no se usan en esa página. Se cuentan en la pestaña de red.
- El panel va lento. Guardar una entrada tarda varios segundos: hay consultas de más en el área de administración.
- Una página concreta pesa mucho más que el resto sin motivo visual. Ahí hay un plugin cargando su mundo entero.
- El servidor se queda sin aire en picos. A veces el plugin no es lento, pero consume memoria o hace peticiones externas en cada visita.
Lo que se ve desde fuera y lo que no
Sin acceso al panel puedo ver el resultado: cuánto tarda el servidor, cuántos recursos se descargan, cuáles bloquean el renderizado, cuánto pesa el HTML y qué se pide a dominios de terceros. También puedo ver huellas en el código, como rutas de plugins en los assets.
Lo que no se ve desde fuera es la consulta concreta que se repite 40 veces o el hook que se ejecuta en cada carga. Para eso hace falta entrar. Y para entrar, una copia.
El método que funciona
- Elige una página. No la home: la que más te importe. Una ficha de producto, una landing o el checkout.
- Mide y apunta. TTFB, peso total, número de peticiones y tiempo hasta ver el bloque principal. Anota también la hora y si había caché.
- Haz una copia. Un staging o una copia local. Si no hay, no desactives nada en producción sin una ventana de mantenimiento.
- Desactiva por grupos, no de uno en uno. Primero todos los de formularios, luego los de sliders, luego los de analítica. Cada ronda, mide igual que antes.
- Vacía la caché entre rondas. Si no, estás midiendo el resultado anterior.
- Cuando encuentres el grupo, afina. Ahí sí, uno a uno. Y comprueba si el plugin tiene una opción para cargar solo donde se usa.
Con Query Monitor instalado en la copia puedes ver consultas, hooks y tiempo por componente. Es la forma más rápida de pasar de «creo que es este» a «es este, y aquí».
Desactivar plugins hasta que la web vaya rápida no es optimizar. Es dejar de hacer cosas.La diferencia importa
El caso típico: cargar en todas partes
El patrón se repite. Un plugin de formularios carga su CSS en todas las páginas porque el desarrollador no lo condicionó. Un slider carga su JavaScript en el blog, donde no hay slider. Una pasarela de pago carga su SDK en la home, donde no se puede pagar.
La solución no es borrar el plugin: es decirle que cargue solo donde toca. Muchos lo permiten con una opción, un filtro o una versión más reciente. Si no lo permiten, toca valorar si compensa.
Qué hace la auditoría con esto
La auditoría no entra en tu panel ni lista plugins. Lo que hace es medir el efecto: cuánto tarda el servidor en empezar a responder y cuántos servicios externos carga la portada. Con eso se llega a la conversación correcta: «esto pesa aquí», no «tienes demasiados plugins».
Si el problema está dentro, el informe te dice dónde mirar y con qué medir. Y si quieres que lo mire yo, ya hablamos.
Mira qué se está cargando de más en tu web.
Recursos que no se usan, scripts que bloquean y páginas que tardan más que la portada. En dos minutos y sin tocar nada.
Auditar mi web