Por qué deberías hacer carga condicional de tus plugins

Una de las fortalezas que tiene WordPress son los plugins, una de las maneras más sencillas de ampliar o extender las funcionalidades que tiene el propio WordPress para adaptarlo a nuestro proyecto y hacerlo más potente y competitivo, ya que existen miles de ellos disponibles, sólo en el repositorio oficial más de 54.000, y con múltiples características. ¡Vivan los plugins!

Pero los plugins no son sólo alegrías, siempre que cumplan su función para la que fueron diseñados, también tienen un problema importante, y es que siempre están activos, es decir, nuestro sistema WordPress siempre realiza la carga de todos los plugins activos en la instalación en cada llamada a la misma, lo que puede generar un problema de rendimiento en nuestro servidor si en esa llamada concreta, algún plugin no es necesario. ¡No vivan los plugins! Tampoco es eso, que vivan, pero cuando nosotros decidamos. Este es el concepto de la carga condicional: gestionar qué plugins cargar.

Qué es la carga condicional de plugins

A modo de definición básica, la carga condicional de plugins es otra estrategia WPO por la cual decidimos si es necesario cargar un plugin o no, en función de ciertos factores que nosotros decidamos:

  • Qué URL se está llamando.
  • Quién realiza la llamada.
  • En qué momento.
  • En qué entorno.
  • …..e incluso, combinaciones de varios factores.

En resumen, tener un control total sobre la carga de los plugins activos en todo momento.

Ejemplo: Carga condicional de formularios

Un ejemplo sencillo y habitual lo encontramos en los plugins de creación de formularios, que normalmente utilizamos en nuestras páginas de contacto, es decir, en una sola página de todo nuestro sitio, pero que es cargado en todas y cada una de las URL aunque no se necesite de dicho formulario.

Normalmente se puede apreciar en el front-end por que incluye una llamada a un fichero JS y un fichero CSS propios del plugin, aunque también consume carga en el servidor, en el back-end, que es donde queremos incidir todavía más con esta estrategia, no cargando plugins no necesarios.

En este caso tendríamos una mejora apreciable incluso en el front-end, aunque también veremos ejemplos incluso más sencillos, para no cargar plugins que sólo son necesarios en el administrador de WordPress.

Esta estrategia es complementaria a todas vuestras actuales estrategias de WPO que ya estés utilizando en tus proyectos con WordPress, como caché, HTTP/2, carga diferida, compresión, y un largo etcétera; y como te decía, tiene un objetivo doble: reducir el tiempo de carga en el servidor al no cargar ciertos plugins si no son necesarios, mejorando el TTFB y por tanto el tiempo de carga global, y reducir el tiempo de carga en el cliente, al no requerir la llamada de ciertos recursos que no se vayan a utilizar en la página, de nuevo menor tiempo de carga global y mejor UX. Y como toda buena estrategia de WPO, por ende, reducir los recursos necesarios en nuestro servidor.

Todo esto está muy bien y ahora seguro que te estás preguntando cómo se llama el maravilloso plugin que hace todo esto o donde está el código que habitualmente Fernando Tellado te prepara con cariño para que pegues de una manera sencilla.

Lamento deciros que este no es el caso. Al tratarse de una técnica «a medida» de cada proyecto, es necesario entenderla y desarrollarla a medida, debemos crear las condiciones programáticas para cada caso concreto que deseemos controlar, aunque observareis muy pronto que los patrones se repiten en casi todos los proyectos y podéis reutilizar mucho del código que habéis generado. Recordad, no hay dos proyectos iguales pero sí muchas partes recurrentes.

Pero tranquilo, que voy a ponerte unos cuantos ejemplos de uso sencillos para despertar tu cabeza de «optimizador de proyecto» y que seguramente podrás implementar por similitud en todos tus sitios.

Lo primero explicar cómo se aplica esta técnica, que es un concepto muy sencillo y que se basa en estos dos pilares:

  • El filtro  option_active_plugins, que nos permite controlar qué plugins se cargarán de entre todos los activos. La idea es decirle a WordPress que plugins se van a cargar, como si entráramos en cada petición en el administrador y desactivásemos momentáneamente uno o varios plugins.
  • Un MU-Plugin, que es donde colocaremos nuestro código, ya que estos se ejecutan antes que los plugins activos, permitiéndonos un control total sobre ellos.

Y dos notas antes de empezar con los ejemplos:

  • Es una técnica MUY peligrosa, es necesario conocer en detalle el sitio y el funcionamiento de los plugins.
  • Utilizar normalmente sólo para el front-end, ya que en el back-end los plugins aparecerían desactivados o pueden provocar errores.

Vamos al lío. Empezamos con la estructura básica de nuestro MU-Plugin, que será de este estilo, muy sencillo, con la llamada del filtro option_active_plugins a nuestra función  ayudawp_option_active_plugins donde modificaremos el array de plugins activos ( $plugin_list), quedando tal que así:

Ahora vamos con un ejemplo para entender cómo WordPress tiene referenciados los plugins internamente, que es la manera que utilizaremos para quitarlos del array.

Como podrás ver por el resultado de la ejecución, los plugins están referenciados por el nombre del directorio y el nombre del archivo PHP que lo ejecuta:

Nota: no utilizar el ejemplo anterior en un entorno de producción, ya que sólo ejecuta esa función y generará error al usuario.

Basándonos en el mismo concepto y en el primer ejemplo que pusimos, cómo haríamos la carga condicional del plugin Contact Form 7 sólo en la página donde tenemos nuestro formulario de contacto:

Nota: la única complejidad es manejar las dos URL que necesita el plugin, la de la página donde lo hemos incrustado, normalmente mediante un shortcode, y la que necesita el plugin internamente para recoger los datos.

Ahora un ejemplo de uso para plugins que sabemos que sólo se ejecutan en el back-end, como Classic Editor o Duplicate Post, y que no necesitamos de su carga en el front-end:

Otro ejemplo de uso donde podemos implementar esta estrategia de carga condicional de plugins es cuando estamos utilizando un entorno de desarrollo, donde necesitamos menos plugins o no son necesarios y queremos ahorrarnos tiempo, y uno de producción, sin necesidad de realizar cambios, compartiendo el código:

También podemos aplicar una condición programática de carga para usuarios conectados, por ejemplo no cargando el plugin habitual de condiciones legales para ese caso concreto:

Y por último, dos trucos que te van a encantar y que te permitirán medir de una manera muy sencilla la velocidad de carga, que se que te encanta, de tu web sin plugins o sin un plugin concreto, sin necesidad de modificar tu instalación ni molestar al usuario.

Para el primer caso:

Y si quiero medirlo sólo sin un plugin concreto, tan sencillo como esto:

¡Una maravilla para medir el impacto de los plugins de una manera rápida!

Fácil, ¿no? Ahora sólo tienes que empezar a combinar y aplicar esta técnica en base a los ejemplos que aquí he recogido y las particularidades que tenga tu proyecto.

Espero que esta técnica te haya despertado las ganas de optimizar todavía más vuestros proyectos.

¡Quiero más!

¿Ganas de más? En breve, si el responsable de esta web me lo permite, avanzaremos con nuevos ejemplos sobre la base de esta estrategia para mejorar todavía más la carga, por ejemplo, dentro del administrador de WordPress o aplicar test A/B de plugins o cargar plugins sin necesidad de activarlos en el back-end o en las integraciones con otros servicios.

Nos vemos o nos leemos.

VALORA Y COMPARTE ESTE ARTÍCULO PARA MEJORAR LA CALIDAD DEL BLOG…
(11 votos, promedio: 5)
¿Te gustó este artículo? ¡No sabes lo que te estás perdiendo en YouTube!

Autor: Fernando Puente

Informático de profesión / Formador frustrado / Beginner de comer y beber. Apasionado de la tecnología, llevo casi 20 años desarrollando proyectos en Internet en casi todos los sectores, desde hace 8 en medios de comunicación deportiva, y de todos he sacado algo bueno. Puedes seguirme en @fpuenteonline.

Comparte esta entrada en
468 ad
Ir al contenido