La pregunta del millón. Yo creo que la de ¿Cuántos plugins puedo instalar en WordPress? debe ser una de las cinco preguntas que más hacen los usuarios. Al menos así debe ser a juzgar por las veces que me preguntan algo así.

La respuesta es depende. Pero como por experiencia sé que una respuesta así no contenta a nadie vamos a repasar qué debes y no debes hacer a la hora de instalar plugins y cómo debe ser un plugin de calidad para que su impacto sobre la velocidad de tu web sea el mínimo posible.

El número máximo de plugins que es recomendable tener instalados

Por desgracia la respuesta a esta pregunta no es sencilla. No hay una cantidad que podamos decir que es el límite recomendable de plugins a instalar. He visto webs que con cuarenta o cincuenta plugins van con un tiro, y otras que con quince están para tirarlas.

Sin embargo, sí hay una serie de claves a tener en cuenta a la hora de escoger los plugins que instalamos, y también una serie de «normas» de comportamiento que podemos seguir a la hora de instalar o no nuevos plugins. Y estas cosas, monamí, sí serán determinantes en la eficiencia y la velocidad de la web.

Cómo afectan los plugins al rendimiento de una web

Como con tantas otras cosas con todo en esta vida, el secreto de tomar buenas decisiones es tener la información necesaria para ello. Así que lo primero debería ser saber cómo y por qué afectan los plugins a la velocidad de carga de tu web.

A ver si te has parado a pensar en esto: WordPress (el core) tiene en torno a medio millón de líneas de código. ¿Por qué entonces los plugins pueden afectar tanto al rendimiento del sistema, si sólo aportan entre unos cientos y unos (pocos) miles de líneas de código extra?

La respuesta es simple: no es la cantidad lo que afecta a la eficiencia de la web. El impacto que un plugin puede tener sobre la velocidad del sitio viene de otros factores.

Peticiones HTTP: llamadas a scripts y estilos

Hoy en día, con las conexiones a internet que se comercializan, el tiempo que se tarda en descargar unos miles de líneas de código es ridículo. Puedes descargar unos megas de código JavaScript o de CSS en apenas unas décimas de segundo.

El problema está en las peticiones: para descargar este código el cliente (el navegador) debe hacer una petición al servidor y éste responderla. Debe haber una serie de comunicaciones para que la descarga de ese archivo JavaScript o CSS comience. Y eso lleva su tiempo.

Imagina que tienes treinta plugins, y que cada uno de ellos llama a un sólo archivo JavaScript y a un sólo archivo CSS: ya tienes ahí sesenta peticiones adicionales al servidor. Si cada uno de esos plugins encola ambos archivos en todas las URLs de la web (las utilice en ellas o no) mal vamos.

Lo que diferencia un buen plugin de un mal plugin en la carga de scripts y estilos

Ante todo yo diría que, por profesionalidad, un programador no debería incluir scripts y estilos en un plugin a menos que sean necesarios para que realice su funcionalidad correctamente. Personalmente pienso que de un tiempo a esta parte se abusa del JavaScript, pero también comprendo que el usuario demanda ciertas cosas, así que el equilibrio es difícil.

Pero lo que clama al cielo es no encolar los scripts y estilos de forma condicional. Porque, aunque parezca mentira, hay quien carga sus scripts en todas las URLs de una web, incluso en URLs en las que el plugin jamás va a actuar.

A ver, alma de cántaro: si haces un plugin para añadir una funcionalidad al checkout, ¿por qué narices no compruebas si la carga de la página se está realizando en el checkout antes de registrar y encolar el archivo correspondiente?

Pues no, algunos actúan como si tuvieran derecho a campar a sus anchas, como si todos los recursos del mundo les pertenecieran por nacimiento.

Si ves que el plugin que utilizas está cargando archivos JS o CSS en lugares en los que no son necesarios… mal asunto. Puedes verlo echando un vistazo al código fuente de la web (ctrl+U o Cmd+U).

Y aún hay que añadir otra consideración a este tema. Si ya sabemos que Google PageSpeed penaliza los estilos y scripts que no están minificados, ¿por qué no incluir (y usar en producción) una versión minificada del código JavaScript y CSS?

Hay herramientas online que lo facilitan (yo uso JSCompress y CSS Minifier y es muy fácil incluir en el código el archivo normal para desarrollo y el minificado para su uso en producción.

Consultas a la base de datos

Para que un plugin sea realmente útil debe ser capaz de adaptarse, aunque sea mínimamente, a las necesidades de la web en que se va a utilizar; para eso están los ajustes. Estos ajustes, definidos por el usuario, se guardan en la base de datos, y cuando el plugin necesita saber qué ha quiere el usuario que haga en una situación particular consulta esos ajustes.

Pero claro, eso requiere llamadas a la base de datos: hay que conectar al servidor de base de datos, hacer la consulta y procesar la respuesta. Y, ya lo habrás adivinado, todo eso lleva su tiempo. Por eso (lo habrás leído muchas veces seguramente) es más eficiente usar directamente código: las decisiones están ya hechas sobre el código y no hay que consultar a la base de datos. Pero no todo el mundo sabe adaptar el código a sus necesidades particulares.

Lo que diferencia un buen plugin de un mal plugin en las peticiones a la base de datos

Aquí, de nuevo, hay buenas y malas prácticas. Es inevitable (la mayor parte de las veces, excepto en plugins que hacen una función muy concreta) realizar consultas a la base de datos, pero siempre deben ser las menos posibles.

Un mal plugin desarrollador:

• Realiza una consulta a la base de datos para conocer el valor de un ajuste cada vez que va a usarlo
• Guarda los ajustes como opciones diferentes y accede a cada una de ellas cuando hace falta

Por contra, un plugin de calidad:

• Realiza una consulta a la base de datos y guarda el valor en una variable para utilizarlo cada vez que lo necesite sin tener que realizar consultas adicionales
• Guarda todos los ajustes en un array, de forma que sólo hay que realizar una sola consulta a la base de datos para obtener los valores de todos ellos

Código eficiente

Para terminar de hacer las cosas de forma adecuada, añadiría el hecho de optimizar el código y hacerlo eficiente, aunque realmente esto ya no afecta tanto como los dos puntos anteriores.

Por supuesto un código ineficiente, lleno de bucles, mal programado, etcétera, afectará a la velocidad de carga de la web, aunque con las velocidades de procesamiento que se manejan hoy en día y la introducción de la OPcache a partir de PHP 5.5 el efecto de esto es limitado.

Sin embargo mientras que los dos puntos anteriores puede implementarlos cualquier desarrollador que tenga un mínimo de estima por su trabajo y de ganas de hacer las cosas bien, la eficiencia en el código depende más de la experiencia con un lenguaje que de buena voluntad.

Pero siempre, sea cual sea el nivel de programación, hay una cosa que el programador puede hacer: esmerarse.

Ahora de nuevo: ¿cuántos plugins puedo instalar en WordPress?

Pues sabiendo todo esto, ya puedo contestar sabiendo que entenderás la respuesta: los que necesites, siempre y cuando sean plugins de calidad.

En general, antes de instalar un nuevo plugin, deberías estar seguro de que realmente lo necesitas. Para ello puedes hacerte una serie de preguntas:

• ¿Es necesario este plugin (técnica o legalmente) para el funcionamiento de la web?
• ¿Aporta valor a los usuarios y/o me permite ofrecer un mejor servicio, o simplemente «me gusta como queda»?
• ¿Aumenta las ventas, la tasa de conversión o el ticket medio?

Si la respuesta a alguna de estas preguntas es sí, entonces instala el plugin. Si no, mejor déjalo correr. Si te preocupas de que los plugins que intalas sean de calidad, entonces verás que la pregunta ¿cuál es el máximo de plugins que puedo instalar? pierde buena parte de su sentido.