 un tallercillo a menos de como a menos. Gracias, Juanma. Eso va a ser a menos seguro de cómo podremos optimizar más todavía nuestros sitios web con Warprez. Así que todos tuyos. Muchas gracias. Bueno, buenas tardes. Muchas gracias por acudir a este taller. Lo primero a agradecer a la organización que haya seleccionado este taller dentro de lo que es el programa de Warcan Zaragoza, segundo año. Para todos aquellos que sean vuestra primera Warcan, os invito no solo a que vengáis a ésta, sino que todas las que podáis ir, hagáis el intento, siempre de ir porque se aprende un montón, se conoce gente súper interesante y para mí lo más importante y creo que se comenta muy poquito, tenéis a vuestra disposición la propia gente que hace Warprez o los que trabajamos todo el día con Warprez, o sea fuente total de conocimiento. Terminada esta introducción, pues vamos un poquito a entrar en temario. Hoy vengo a hablar de una de las estrategias de WPO, que es en este caso la carga condicional de plugins. Lo primero a presentarme me llamo Fernando Puente para los que no me conozcáis. Llevo desde el año 1996 trabajando en Tecnología de la Información en diferentes sectores. Soy consultor Enterprise para Siteground. Soy consultor de desarrollo de negocio para Giz, CTO de las plataformas esprimeviajes y dormir de chollo, soy además formador en la Fundación COPPE y consultor especializado sobre todo en Tecnica de Performance en grandes medios. Y como decía, hoy venimos a hablar de WPO, ¿no? ¿Qué relación hay entre WPO y Warprez? Al final, ¿por qué llevamos varios años hablando de WPO? Primero porque es tendencia, queremos cada vez tener nuestras páginas más optimizadas, más rápidas. Segundo porque es un ahorro de recursos en el caso del servidor. Cuanto más optimicemos el servidor, menos recursos necesitamos, menos dinero necesitamos invertir. Y al final, que es casi a lo que vamos, es una mejor experiencia del usuario porque se entrega antes el contenido. Hoy veremos, como decía esta estrategia, que es la carga condicional. ¿Qué significa este concepto de carga condicional? Porque realmente lo que vamos a ver hoy es, realmente, lo que es la estrategia. Y lo que quiero que salgáis de aquí es aprendiendo cuál es esa estrategia. Y ya os digo que la vais a implementar de manera diferente en todos y cada uno de los sitios. En todos se puede aplicar y luego vais a entender el por qué. ¿En qué consiste? Como bien sabéis, uno de las fortalezas que tiene Warprez son los plugins. Es la manera de extender Warprez con funcionalidades que son adicionales. Pues oye, qué gran idea, ¿no? Esto de los plugins. ¿Qué es lo que pasa? Pues que al final, en nuestras instalaciones de Warprez, tenemos nuestro tema y tenemos 5 plugins, 6 plugins, 7 plugins, porque vamos aumentando las necesidades de nuestras funcionalidades. ¿Cuál es el problema tiene Warprez a nivel de programación? Que los plugins, como bien sabéis, están siempre activos, pero a veces no se necesitan. ¿Por qué vamos a utilizar un formulario de contacto en toda la web, en toda la profundidad del site, si solo lo requiero para una página concreta? Y seguro que habéis estado en charlas de WPO, de donde se hablaban, ¿vale?, de quitar, seguramente lo habéis visto, ¿no?, de cómo quitar, cómo desencolar el Javascript de Contafone o cómo no aplicar el CSS. Todas estas estrategias están muy bien, pero esas estrategias se ejecutan a posteriori, es decir, Contafone se ha ejecutado y luego lo que hacemos es la trampa de quitarlo, lo que hacemos es ahorrarle tiempo al usuario. Bueno, pues esta estrategia consiste en hacerlo a nivel de servidor, es decir, que no se lleve a ejecutar el plugin. Es como si cada vez que hubiera una petición vosotros entraréis en vuestro administrador y dijeraís, pues esto es una solicitud de la home. ¿La home necesita el plugin de Contafone? No, no se lo entrego, no lo ejecuto, es decir, vamos a ahorrar sobre todo recursos a nivel de servidor. Evidentemente esto implica que al usuario final le vamos a entregar menos contenido, le vamos a obligar a que haga menos solicitudes. Esa es en lo que se basa esa estrategia. Recordatorio, WPO como decía antes, no es solo velocidad, puede ser una derivada que nosotros aplicando WPO en nuestro servidor lo que consigamos es reducir la velocidad, pero sobre todo nos encaminamos a que el servidor necesite menos recursos y eso es posible que haga que la máquina, que la página vaya más rápido, pero sobre todo nos encaminamos a eso. ¿Cuál es el objetivo? Que cuando tengamos un pico de carga, si el servidor está menos necesitado de recursos, podremos atender esa carga. Estrategia, como decía, para reducir tres grandes. El tiempo de respuesta, ¿vale? Que es la parte de servidor. Esta es una estrategia que lo que busca es eso, reducir que el servidor ejecute menos cantidad de código y entregue antes, empiezan a entregar antes las páginas. Carga innecesaria de código, como decía, porque hoy vamos a ver el ejemplo. Muchas veces hay plugins que no necesitamos en todas y cada una de las páginas y seguro que ya os está pasando. Y el número de recursos que va a entregar la página, como decía, va a ser menor, con lo cual la página se va a cargar antes. La magia va a ser este filtro realmente. Es el que vamos a utilizar. Obtionate plugins, que lo que hace es que en toda la carga de WordPress, en todas las llamadas que va a ejecutar WordPress, WordPress hace una llamada a este filtro. ¿Por qué? Porque va a la base de datos, consulta cuáles son los plugins que están activos y empieza a ejecutarlos. Entonces, lo que vamos a hacer es, dentro de nuestra estrategia, engañar a WordPress. En función de la solicitud le vamos a decir que plugins no están activos. Realmente no se desactiva el plugin. Lo único que no le decimos a WordPress es que en esa ejecución utilice ese plugin. Notas finales, importante. Técnica muy peligrosa, no, lo siguiente. Porque estoy entregando en un servicio de producción a una página concreta, le digo desactiva ese plugin. Si el plugin no es el correcto, estamos haciendo un proceso de check out y le decimos que no entregue el plugin de Google Comers, pues lo mismo la página tiene algún problema. Hay que crear condiciones programáticas para cada caso concreto. Hoy vamos a aprender estrategia. Luego en cada una de las instalaciones habrá cosas que se repitan, el famoso formulario de contacto. Pero en mi página se llamará barracontacto y en otras se llama barracontacto. Y tendremos que crear una condición específica a nivel programación. Y es a medida de cada proyecto, porque los plugins son diferentes, las estrategias son diferentes, las URLs son diferentes. No existe una estanda. Así que venga, vamos a hacer un poquito de taller. Voy a enseñar a lo primero una instalación que he preparado, estandas, sin floreturas, para entenderlo. Aquí lo que tenemos es un WordPress, tiene una parte de blog, tiene una parte de tienda, sobre todo para que veáis los diferentes tipos de plugins que podemos utilizar, que podemos trabajar con ellos. Y os voy a enseñar lo que sería la parte de backend. Para que veáis más o menos que son plugins que seguramente todos estéis utilizando o utilicéis en vuestras instalaciones de clientes. Tenemos a CF, tenemos a MP, tenemos Brooklyn Link Checker. ¿Qué queda tanto miedo? Pues sí, Contafone, Duplicate POS, Editor Clásico, Flamingo. ¿Conocidos? Os usáis ¿no? Seguro que alguna usáis. SESMAS para las imágenes, Sukuri, bucomes, los bloques, Stripe, incluso HighLogging o Javas. ¿Cuántos de vosotros utilizáis a CF? O Duplicate POS, dejar la mano. ¿Lo utilizáis en el vaqueno, en el frontend? Duplicate POS, ¿dónde lo usáis? En el vaquen. ¿Y por qué se lo entregáis al usuario? Cada vez que pide una solicitud. Es posible. Hacerla por evalúo cuando vayáis. Y empezar a ver en el, porque la lógica sería, si yo pienso, la primera función que debería tener supply en el, si no estoy en el administrador, fuera. No, voy a cargar variables, voy a ocupar memoria, no sé cuánto. Y si no estás en el ambiente sales. Ese tiempo es lo que quiera ahorrar. Quiero decirle a WordPress, si estás en el frontend, olvídate de ACF, olvídate de Duplicate POS, olvídate de el que sea. Eso es una estrategia. Y eso es lo que nos va a ahorrar, tiempo de ejecución. Y entregar menos cosas al usuario. Me diréis, no, el Duplicate POS no entrega cosas al usuario, en ese caso no entrega cosas al usuario. Pero lo estoy ejecutando cuando realmente no se necesita. Por ese concepto que tiene simplemente WordPress. Esta es mi instalación, como decía. Tengo PHP 7.214, está en un servidor. Yo voy a enseñar un poco el concepto que necesitamos trabajar. Esta es mi parte de ficheros. Lo he instalado incluso en un subdirectorio, para que veáis un poquito la diferencia. Por eso os digo muchas veces que no es un estándar. Al utilizar WordPress dentro de un subdirectorio, en mi caso el barratienda, pues todas mis URL serán barratienda, lo que sea. Y lo que utilizamos son los MU plugins. ¿Sabéis lo que son los MU? Los MU son, para aquellos que no lo sepáis, plugins que están siempre activos. Tienen una condición especial que están dentro de esa carpeta debajo de WP content, esa carpeta MU plugins. Y lo que hacen es la única diferencia que están siempre activos. ¿Cuál es la diferencia fundamental? Que se ejecutan antes que los plugins y es el punto que nosotros queremos coger. Si esta estrategia que estamos haciendo ahora la hicieramos como un plugin, no funcionaría. Porque seguramente habría plugins, filtros o acciones que se ejecutarían antes que nosotros. Entonces lo que tenemos que hacer es ejecutarlo antes que empiecen a ejecutarse los plugins. De esto lo destacapeta lo que tengo es una serie de archivos, ahora mismo como ficheros de texto. Voy a ampliarlo un poquito, perdón, me he pasado. Para que lo veáis, en el cual iremos viendo una serie de pasos. Os iré enseñando, perdón, el código que incluye, que va a ser un código muy sencillo. Este por ejemplo es para que veáis el concepto de la carga. Y durante el taller lo que voy a ir haciendo es de una manera muy sencilla, simplemente cambiarlo a PHP. Ya está activo, a partir de este momento ya está activo y ejecutar el sitio. Si os acordáis y lo habéis visto, aquí tengo un esync maravilloso que es lo que va a hacer que deje de cargar. Es decir, se está ejecutando antes de los plugins. ¿Qué es lo que quiero mostraros o me gustaría mostraros? Un poco el concepto de ejecución. Esta es la pila de llamadas que se han realizado y empieza por aquí. Es el nds de WordPress, empieza a ejecutarse, el nds llama el header, el header llama lvp-load, lvp-load a lvp-config, que llama lvp-settings y lo primero que hace es instanciar los mu plugins. O sea que estoy llamando muy por delante de lo que es el resto de la ejecución. Ese siempre es el objetivo. Evidentemente con este no hacemos absolutamente nada, lo voy a dar simplemente para enseñaros cuál es el concepto del taller. Creo que se ve mejor en el segundo paso, no he enseñado el código. Esto es lo que vamos a utilizar, este filtro, el filtro, opción, active plugins, llamamos a una función y en este caso veis que el parámetro de esa función va a ser un array, que es el listado de plugins. Lo que ha hecho WordPress por detrás es irse a la base de datos, al uvp-options, coge el listado de plugins activos y lo cargan esa lista. Que es lo que he hecho por código, como podéis ver, hacer un print de esos plugins. ¿Os acordáis de la parte del administrador? Tengo mi ACF, mi Mp, papá, papá, papá, papá, papá. Esos son mis plugins. Aquí está la traza que veíamos antes, eso son mis plugins. En este caso tengo 21 plugins y la forma que tiene de guardar WordPress los plugins, de avisar, es esa. El nombre del el directorio y el PHP con el que lo lazo. A partir de aquí, ya vuestro cerebro debería estar se haciendo maldades. Ya habéis empezado a ver la luz, ¿no? Al final del túnel. Coño, si hay una RAI que lo traigo de base de datos y se lo tengo de devolver a WordPress, ahí está. Es facilísimo. Voy a modificar ese RAI. Esa es el concepto. Eso es lo que vamos a ir haciendo. ¿Vale? Detectar de si estoy en el front-end, pues quito el 0, el 3, el 6. Me quito a lo mejor 5 o 6 plugins. Mucho tiempo de ejecución le estoy ahorrando al servidor. Eso es lo que vamos a trabajar. Como nota, el porqué del MEO plugin y cuando vayáis. Seguramente en instalaciones que tengáis, actualmente en producción, ya disponéis de MEO plugins, ¿no? Seguro, ¿alguno lo utilizáis? Seguro, ¿vale? Bueno, pues hay un pequeño problema. Os voy a enseñar dos plugins adicionales. Este va a hacer un ECO y luego tengo aquí abajo otro plugin. Si no se ha ido, sí se ha ido. Si os acordáis, este plugin hacía simplemente un ECO y yo, en el que os había enseñado, tenía un exit, ¿no? Pues da absolutamente igual. Se ejecutan alfabéticamente, ¿vale? Los MEO plugins, que creo que no lo ponen en ningún sitio la documentación y lo he buscado, se ejecutan alfabéticamente. O sea, cuando implementáis esta estrategia, si también tenéis MEO plugins, aunque los MEO plugins no pasan por ese listado de plugins activos, ponerlo el primero de todos, ¿vale? Simplemente para que lo conozcáis. Lo mismo con el listado de plugins. Si habéis visto, estaban ordenados por nombre alfabético. Luego, evidentemente, los filtros tienen un orden y demás. Pero la carga es esa. Voy a desactivar. ¿Cuántas maldades habéis pensado ya? Vamos al tercer paso, en el que vamos a empezar a aplicar maldades. Tengo un filtro y tengo un caso concreto. Vale, hay un plugin que se llama amp.mp.hp. Por eso, si entro en el ordego, la estrategia va a ser diferente en cada uno de los sitios, ¿vale? Y lo que voy a hacer es quitarlo, quitarlo de la RAI. Veis que lo quito de la RAI. Voy a ampliarlo para el orde del fondo. Lo quito de la RAI y devuelvo a WordPress esa parte de la RAI. Voy a activar este plugin. Voy a ir al sitio, evidentemente todo está funcionando. Poderá ver esta función, ¿vale? Y voy a ver su versión amp. ¿Cuándo? No funciona. Oiga, esto debe ser el redactor de siempre que entrao y ha desactivado el plugin. ¿Está instalados? Lo he quitado, ¿veis? El sistema me está simulando realmente que lo he quitado. Esto está mal, ahora os enseñaré la trampa. Pero es lo que ha pasado. Lo que he hecho en el código, como veíais antes, era eso, quitarlo de la RAI. Esta es la base de la estrategia, detectar qué es lo que me están pidiendo y quitarlo de la RAI. Se basa en eso. Ahora, pensar la complejidad que podáis tener a nivel de plugins y a nivel de URL y combinar eso. Eso realmente es la estrategia. Vamos a desactivar ese, A o ni reartir o ni demás. Y vamos a ir al caso 4, al siguiente paso. Donde lleváis a empezar a ver un poco lo que realmente tenemos que hacer. Oye, esta estrategia que me estás haciendo de quitar plugins, aplica lo solo en Frontend. Es sencillo. Quiero quitar los plugins y demás. Voy a poner un exit para que deje de ejecutarse. Tentad quitar pantallas que no necesite. Entonces, si me voy al Frontend, perdón, si me voy al backend, ¿verdad? Algo he hecho mal. Me he cargado algo seguro. ¿El qué, perdón? Algo me he cargado seguro. No, pues está bien. He hecho mal. Pero vamos. El concepto simplemente es ese. Ahora reviso, perdón, que he meído al sitio. El sitio sigue. Disculpar. Meído al sitio, que era exactamente lo que quería hacer. En Frontend estoy aplicando esa estrategia. Y en backend sigo teniendo todos los plugins activados. Si me voy al sitio, me está ejecutando el filtro. Vuelvo a enseñaros el filtro, ¿vale? Es decir, en este caso lo que vamos a hacer es aplicar las estrategias solo cuando se ejecuten esas acciones de Frontend. Con lo cual, esos plugins que decíamos que solo son de backend, ACF, no lo necesito. Duplícate POS, no lo necesito. Sólo estoy pensando en los de backend. Si hay dudas, conceptos y demás, estamos en el mejor sitio para que me paréis. Hay parte que se ejecutan en el Frontend. Si los activas entero, no. No, no, no. Si los activas entero, no. Eso es. Sí, sí, sí, sí. Sí, sí. Eso es. Voy a enseñaros lo que veíamos antes de, perdón. Voy a enseñaros el editor de Plies. ¿Alguna duda más por ahí? Maldades, ¿cuánto lo vais a empezar a aplicar esto? Sólo uno. Me preocupa. Me preocupa. No sé si lo veis de atrás. Ejemplo de duplicate POS. De fines, acciones, filtros, no sé qué, no sé cuánto. Pues es un poco el. Aunque sea mínimo, me estás ahorrando. Te estoy ahorrando linear de ejecución. Te estoy ahorrando espacio memoria. Te estoy ahorrando una gran cantidad de cosas. En este caso, estamos hablando de la parte de backend. Lo que realmente se nota es en lo que sea parte de Frontend. Porque a veces son plugins muy pesados o que hacen muchas comprobaciones. Vamos a seguir avanzando. Todo este código, seguramente, lo subiría un guijado o algo similar. En mi caso, tengo una particularidad que no os he enseñado antes, que había un plugin, que es el HighLogin o el que cambia la URL del login. Entonces, empieza ya a coger lógica esto. Empieza a cambiar. Antes hacíamos un filtro con el isadmin. Pero si hubiera aplicado ese filtro, se ejecutó mi sitio barra login, que es donde tengo mi función, no hubiera funcionado. Porque necesitaría, en este caso, que el filtro solo se aplicara. Entonces, empieza a aplicar condiciones. Empieza a ver que sea WP Admin, que sea login. Ese tipo de cosas. Tenéis que ir trabajando todo eso, tanto en la parte de dónde no lo quiero montar como en la parte de dónde lo quiero montar. Simplemente quería enseñar. Es decir, si vuestro administrador es barra mi administrador, pues también tendréis que utilizar ese tipo de programación condicional. Continuamos. Y volvemos al ejemplo que veíamos antes. ¿Cómo se aplicaría ya? De una manera concreta. Digo, la técnica es sencilla. Voy a alterar la parte de Array de Plies. Con lo cual, os dejo ya un posible avance que sería activar plugins en tiempo real. Sin necesidad de pasar por el administrador. Que eso todavía mola más. Yo tengo un plugin que he subido al servidor, pero no lo tengo activo. Y lo que hago es que se lo inyecto en este Array. Imaginaros que es un Array, que es un plugin que no necesita configuración de base de datos. Podríais hacer también esa estrategia. Detectar, por ejemplo, para mis usuarios que están en Alemania, porque lo detecto por IP, añádeles este plugin en tiempo de ejecución, solo para los de Alemania. O sea, peligro, no. Peligrosísimo. Con la potencia que os da, es muy, muy alta. Vamos a continuar. Lo vais viendo, lo vais entendiendo. Se entiende el concepto y sobre todo se entiende el porque hay que hacerlo a este nivel. Si yo esto lo implementara como plugin, pues ya hubiera cargado el resto. Entonces tengo que hackear. Fernando, lo único que haces es en ese Array le dices a WordPress que tiene un plugin nuevo también. Entonces WordPress directamente lo que haces es ejecutarlo. Sí, en base a la condición, ¿vale? En este, no, en este, no, no, no, no, no. Imagínate en este ejemplo, ¿vale? En esta, no, no, no. En esta estrategia, ¿vale? La estrategia es siempre la misma. Oye, llámame a este filtro, llámame a esta función, ¿vale? En esta función entra el listado de plugins activos en ese, en ese momento y yo lo que hago es alterar. Y entonces hago una condición. Pues si el IP de este usuario viene de Estados Unidos, ¿vale? Añade además el plugin GDPR USA, solo para esos, para esos usuarios, ¿vale? Que es un concepto diferente al que normalmente estamos aplicando. Tengo el plugin activo y hago un, si es este, no lo, no lo entregues. Pero sería una manera. Incluso para hacer test, para hacer de bug. Oye, ¿cómo funciona esto? ¿Vale? ¿Cómo altera? ¿Vale? Es un poco, no sé exactamente cuál es el acercamiento que va a tener WordPress 5.1 para esos test de plugins y demás para que no se genere esa, esa pantalla de, ¿no? El white screen, este famoso. Pero sería algo parecido. Oye, ¿qué pasa que si yo ejecuto este plugin, ¿no? Y veo que me da un error 500. Sí, ¿podrías, por ejemplo? Eso es, eso es. Sí, por ahí, perdona. Bueno, en este caso daría lo mismo. A ver, el funcionamiento lógico es que tú activas el plugin, lo configures en base de datos para que toda la estructura que necesita el plugin en ejecución esté en base de datos. Y lo que hago es no entregarlo en una condición específica, ¿vale? El ejemplo más común que tenemos es los plugins de formularios. Doy de alta el plugin de formulario. Creo el formulario que se guarda en base de datos. Y lo que hago es que cuando no necesito ese formulario, ¿vale? Lo que hago es no cargarlo. Podría ser una estrategia. Podría ser una estrategia. Pero yo creo que sería más complicado de hacer. Yo creo que sería más complicado de hacer. También, pero piensa en la cantidad de URL o diferencias que tenga dentro de tu web. O sea, a lo mejor solo tienes dos, tres URL. Si tengo la home, el quiénes somos y el contacto. Pues seguramente, afinaría muchísimo, muchísimo más. No necesitas tener siempre los plugins activados, ¿vale? El ejemplo, como decía, ¿vale? Un poco más completo era este. Y siempre lo mismo, ¿vale? Quito del array. Vamos a avanzar un poquito más, ¿vale? Sería el 7. En cuanto empecéis a trabajar con esta técnica, pues, que además de potente y demás, lo que nos permite es no solo hacer esa parte de programación condicional, una de las cosas que yo más utilizo es esa parte que comentábamos antes de debut, ¿vale? Por ejemplo, yo instalo un plugin y siempre decimos, pues mi web va más rápido, más lento. Hago, me voy a la famosa herramienta para medir y empieza a medir la velocidad. Venga, lo desactivo. Voy a volver a medir. Añado 2, lo vuelvo a medir. Yo utilizo programación condicional, ¿qué os lo vais a ver? Cuando un cliente me dice, es que mi web va lenta, lo primero que hago es medirla sin plugins, la opción sencilla o la normal. Crearse un staging, copiar todo, activar todos los plugins. Me voy a medir, lo desactivo, todos los plugins. Me voy a medir. Voy a hacerlo en dos líneas de código. Le digo, si viene ese parámetro, no lo provéis en mi web. No sé, malos. Si viene ese parámetro, no cargues ningún plugin. Podéis medir el impacto que tienen vuestros plugins, simplemente con una línea de código. Vamos a activarlo y ver el ejemplo. Si tiene utilidad, tengo mi sitio, normal, carga normal, tengo mi parte de tienda, todo normal, están todos activos. Esto sin plugins, ¿cómo va? Aparentemente me ha desaparecido el carrito, alguna cosita más y demás. Vamos a ver un poco la diferencia. Voy a salirme para no estar logado, voy al sitio, confinamiento normal. No he ido en el escritorio desactivo. Voy a cargarlo, he habilitado el inspector de Chrome. Y quiero aquí, a ver si es posible, porque me ha cambiado la resolución. Quiero que veáis abajo. No le explotante, ya está. Tengo, en este caso, no sé, os lo voy a leer, tengo 52 peticiones. El total de requests que está haciendo mi página, en este caso, 53 peticiones. Voy a ver sin plugins. Esto sería lo bruto, sin plugins. Pues tengo 32. O sea, el impacto, por ejemplo, de los plugins en este site, ahora mismo de 20 peticiones. La utilidad que decía antes, voy a medir realmente cuál es el impacto sin plugins, que para mí es una referencia utilísima y que normalmente es un proceso complicado de hacer. Pues tienes que montar y el usuario puede seguir si tú vas a mi sitio, si no te sabes el parámetro, va a seguir funcionando exactamente igual. Puedo hacer una medición muy, muy rápida de qué es lo que está haciendo, además de visualmente ver cómo se comporta mi sitio. Evidentemente, vas a hallar algo, estoy quitando todos los plugins. ¿Por qué ir un poco más? ¿Cuánto impacto tiene AMP? ¿Cuánto impacto tiene este? ¿Cuánto impacto...? Vale, esa es la siguiente idea. Si yo puedo hacerlo, es que debería estar en vuestra cabeza. Sí, perdón. Vengo a inspiraros. Voy a cambiar un poco la condición. En vez de quitar todos, voy a quitar alguno concreto. En este caso, lo he hecho a lo bruto, sería con un parámetro. Si os acordáis al principio, creo que era en el paso 2. Sí, vamos a hacer el paso 2 para que lo veáis. Ya se firma digitalmente aquí un fichero. En el paso 2, veamos el listado. Yo voy a mi sitio en producción, mi usuario me está diciendo que tiene problemas. Yo creo que va a ser el Contazón. Yo creo que va a ser el WPO de Fernando Teyada. Yo creo que va a ser el IMP. Yo creo que va a ser, no sé qué. Vengo aquí y digo, esto va a ser el de vacá, el 1 de las plus. El 12, desactivar ese. A mi paso 8. Mi WES sigue funcionando igual. No sé el caso de antes que quitaba todos los plugins. Le digo, pero quítame el 8 y lo mido. Quítame el 1 y lo mido. El mundo del TES os acaba de cambiar. O sea, a partir de aquí podéis medir el impacto de cada plugin sin desactivar nada con un parámetro. Con un parámetro y el usuario no lo nota. El sitio sigue en producción. He tardado, llevamos 37 minutos y la hemos leado. A pensar lo que hubierais tardado en montar todos estos entornos, estas pruebas, este, no sé qué. Vamos a ver ese ejemplo. Si os acordáis antes, los sitios teníamos subversiones a MP, imagínaros para que veáis el ejemplo. Y a MP os acordáis que era el 0. Hacemos una tontería que es quitar el MP. Debería quitar el 0, ¿no? Estáis atentos. Tengo la granularidad para poder hacer eso, sin tocar el funcionamiento del sitio, sin alterar el funcionamiento de los usuarios, sin montar sitio al STI, que es el ideal, el ideal es probarlo todo en preproducción. Pero sabéis que, a veces, el impacto que hay en producción es distinto. No tenéis el mismo entorno muchas veces. Pues para esto es. Si esta función cita, que tenemos aquí, no tantas abiertas, ya nos lo podés. Vamos a volver a abrirla y así. Lo que estoy haciendo es quitando el índice que viene en la red, a nada que la modifiqueis con dos líneas. Yo voy a quitar el 5 y el 7, el 2 y el 4. Pensar en todas las soluciones a nivel de soporte, típica de los usuarios. Esta página funciona en todo, menos en esta URL. Dame la URL. Bien, empiezas. El 0, el 1. Podéis hacer incluso test automatizados. Con Jenkins, con Circle, con ese tipo de. Si hacéis este tipo de cosas, pasáis parámetro, enviáis. Este me devuelve un 200, bien. 200, bien. ¿Qué tal el 0, el 1, el 2? Todos, OK. Este devuelve un 500. Falla el plugin 17. Y al tío no le has tocado nada. Además, se dan maldades, lo estáis pensando. Me preocupa. Dudas a partir de. Dudas está aquí, perdón. ¿La estrategia es esta? A partir de aquí es realmente imaginación. Vamos a ir avanzando para ver qué son concretos. Ninguna duda? Uy, qué miedo. Dáis. No. Ahora veremos algún truco. Estamos en una carga tan previa de WordPress que está muy pocas funciones accesibles. Por eso, casi todo se tiene que hacer a nivel de URL. Os voy a enseñar luego un caso concreto. Es uno de los que más me fastidia y entiendo que a vosotros también. El aviso de cookies. Si ya estoy logado. ¿A qué sí? Si ya me logué. Pero claro, como la cookie, no sé qué sigue ahí. He perdido la cookie. Si estoy logado. ¿Para qué sigue saliendo el aviso de cookies? Me lo quito, ¿no? Si acepté en el login, si acepté, por ejemplo, ¿no? O hacer ese tipo de estrategias, incluso por tipo de usuario, perfil de usuario. Podríais llegar a eso, ¿vale? Aunque vamos a ver varias. Para mí, lo más potente de todo esto, no he llegado a hacerlo en el taller. Y lo dejo ahí de deberes. Sería hacer un test AB de plugins. Porque a veces queréis medir. ¿Cuál es el mejor plugin de noticias recomendadas? Pues este o este. Me probas un día 1 con esta estrategia. Podías hacerlo. De 7 de la mañana, 10 de la mañana, ¿das este plugin? De 10 de la mañana, 3 de la tarde, ¿das este plugin? Y luego mides en Analytics. Para los usuarios que vienen con la IP para este, los que vienen con la IP para esta. Los que vienen, qué peligro. Los WordPress que vais a romper. Más dudas, ¿vale? Esto, por ejemplo, es lo que el compañero preguntaba antes. El caso que, según lo que vosotros conocéis, AMP, ¿sabéis que AMP se ejecuta en todos los que son contenidos finales, ¿vale? En todos los singles, ¿no? Entonces, pues ya está, pues lo programó. Si la página que me están pidiendo no es single, ahorrate el plugin AMP, que además no os imagináis la cantidad de código que tiene. Y chequeos, y filtros, y demás, pues voy. Esto ya lo tengo desactivado, seguiría funcionando. Estoy ahora mismo sin ningún plugin activado. Voy a activar ese, que es el paso 9. Ese tipo de funciones, ¿vale? En este caso, no, no, realmente no funcionan, ¿vale? Es decir, lo que hemos hecho es desactivar el plugin de AMP. Si nos vamos, perdón, por aquí. No, pero no es ese. No, no me lo está. No debo tener desactivado. Pero bueno, lo que ha pasado es justo lo que no queremos, ¿vale? Porque este es un single. Este está borreler de dipón single y lo que le hemos hecho es cuando no sea single, ¿vale? Quítase el AMP. Realmente está funcionando mal. ¿Por qué? Porque la función no sea la misma que tengo el debo. La función es single, no está disponible. No está a nivel de look, ¿vale? Ese tipo de cosas no lo vais a poder hacer. Con lo cual todo lo vais a tener que gestionar, como decía antes, a nivel de URL o de IP. Es decir, estáis en esos pasos previos, por así decirlo. ¿Cómo se haría este caso? Es un caso muy habitual y que prácticamente todos los medios los tenemos implementados. Porque prácticamente todos los medios tenemos AMP. Pues se trabaja, por ejemplo, de esta manera. No os he puesto el caso de AMP, pero os pongo un caso concreto. En mi caso, la home. Y yo hago una programática. Cuando la solicitud, ¿vale? ¿Os acordáis? Mi home, en este caso, era barratienda. Porque estoy en un subdehistorio, o en el barro, o lo que sea. El de Mailchimp para bucomes no me hace falta. Porque la tienda la tengo en otro lado. Los bloques de Gutenberg de bucomes no me hace falta. El Paypal de checkout en la home no me hace falta. El Stride no me hace falta. El propio bucomes no me hace falta. ¿Vosotros pensáis que voy a ahorrar carga con esto? Esto carga de entrega. Más el duplicate post. Más el de backup, ¿vale? Sí, en el caso del Ahon, sí. No, en el caso del Rekwesurrey es el barra. Voy a sacar el inspector este que teníamos aquí. ¿Os acordáis? Te voy a quitarlo. Ahon, si os acordáis, tenía 52 solicitudes. Ahí por debajo, un montón de cosas. Está por ahí el bucomes. El Carflamban, Mailchimp, que no me hacen falta en Ahon realmente. En este ejemplo que tengo concreto, lo tengo en su directorio. Mi parte de bucomes lo tengo en el barrescaparate, que es donde debería utilizar la parte de bucomes. Voy a ejecutar ese paso 10, que os enseñaba antes, que es deshabilitar una serie de plugins. Os acabo de bajar de 52 a 41. Tenía 11 peticiones que no eran necesarias, además del tiempo de ejecución de servidor, que también lo había ahorrado. Es decir, estoy ahorrando en los dos extremos. Ahora, si este web tiene 15,000 URL, si tiene 10,000 condicionales excelentes, es donde se os va a complicar realmente el trabajo. Por eso están a medida. A veces tendré bucomes, a veces tendré contafón, a veces tendré lo que sea. Esa es un poco la diferencia. Es una técnica muy potente, pero muy poco de reproducir en todos y cada uno de los sitios. Muchas veces sí, pero a veces que no sabes lo cargo o no lo cargo, dudas. Sí, en este caso sí. Si el contenido ya estaba cacheado, a lo suelo le voy a devolver el cacheado, por así decirlo. La idea, no lo he contado antes, pero no hay ningún sistema de cacheado activado ni demás. Evidentemente, esto tendría que programarlo antes. Y, entonces, la primera petición que llega al usuario, en este caso, la petición que hemos hecho, si no está cacheado al ahón, haría esa condición, se cacharía al ahón y, a partir de ahí, todos los usuarios que vinieran a ver el ahón verían esa ahón cacheada que está optimizada. Alguna duda más, porque ahí interviene más cosas. En función de los filtros y demás, acordaros que hay un tipo de orden y demás. El orden realmente, el orden que yo he visto, es un orden alfabético, que es el que habéis visto. Está montado en el array. A partir de ahí empieza a cargar, ¿vale? Y PHP carga linealmente. Si el primero plug-ins tiene un exit, los demás no cargan. Pero, a partir de la carga que tengan en PHP, los filtros y demás que vayas añadiendo, sabes que tienes propiedades, puede que se ejecuten, simplemente sea un filtro que le avise cuando pase una acción concreta, ¿sabes? Ahí no hay una carga condicional. Lo único que estoy diciendo a WordPress es, en el array, los que quiero que estén activos para esa solicitud concreta. Igual que hemos hecho antes. Igual que hacíamos el ejemplo, ese de Simplagings. Yo puedo seguir trabajando Simplagings y voy a Vidania y le digo, oye, proba a mi web y él, si no sabe que existe separado, va a seguir viendo la web perfectamente. Es solo para esa solicitud concreta, en ese caso, en el parámetro. En el caso esto de la home, os sería aplicarlo para todos. Pero puede hacer algo condicional. Si es la home con el parámetro, no sé qué. Si es la home, se viene, no sé qué. Si el tío venía de esta acción y ha llegado a otro lado, podés ir combinando, esa es la potencia. Esto lo haríamos ampliando las condiciones. Igual que antes lo veíamos. Oye, cuando sea home, me quita todos estos. Pero es que cuando sea mp, tampoco necesito estos. Y cuando sea, no sé qué. Y cuando no sea, no sé cuántos. Esa es la idea. Al final, ir trabajando sobre esto. ¿Qué petición me está haciendo? ¿Qué URL? ¿Qué condición tengo? Puede ser condiciones como veíamos antes, por IP, por el país, por no sé qué. Esto lo que haría sería para mi home y para los archivos mp. Yo no necesito todo esto. Con lo cual voy a dar todavía, aunque en esto sí que es cierto que el plugin mp está bastante bien construido y no entrega ciertas cosas, pero no solo no lo entrega. Me aseguro que no se ejecuta. Que es muy importante. Es donde quiero que veáis esta técnica porque ahorra cosas de servidor que antes no lo veíamos. Todas las estrategias que hemos ido viendo últimamente a nivel de WPO, pues estaba en eso, en caché. Estaba en no entregues el JS, no entregues el CSS, pero ya se ha ejecutado. Continuamos, si no hay más dudas. Este sería el ejemplo que veíamos antes. Yo en mi caso no utilizo ACS, pero está activado. Pues me lo quitaría. Por ejemplo, el caso que tú decías antes, ACS en la home. Si no estoy utilizando ninguno, pues lo quito, ¿vale? En el caso de Frontend, el Blocking Link Checker, este queda siempre tanto miedo. Pues lo desactivo, ¿vale? El editor clásico, el Duplicate Plus, el plugin de Backup, ¿vale? El Smash. Esto sería otra condición, por así decirlo. Esto empieza a unirlo a la otra que veía, de la URL, de la mp. Al final, esto que os estoy enseñando siempre en porciones de código, en una instalación real o podéis imaginar el kilómetro de condiciones que vais a tener. Que iréis ajustando, afinando, mejorando, por conocimiento del sitio y por conocimiento del plugin. Yo sé más o menos que el Duplicate Plus no lo necesito en Frontend. Pero a veces os va a pasar que llegáis a instalaciones y veis uno que se llama WP, WP, WP, WP y dices, hostia, esto para que será. Te tienes que conocer el plugin para saber en qué opciones hay que, o te pones a investigar el código o lo conoces o lo que sea, para saber en qué opciones lo puedes habilitar y lo puedes deshabilitar. Vamos al caso concreto que decíamos antes. El típico de formulario, ¿vale? En este caso he usado Contafone 7. Podía ser cualquier otro. El formulario siempre es el ejemplo más claro de cuando no necesitamos un plugin más allá de una página. No lo estamos utilizando, a no ser que seamos un generador de landings y está generando por un aire de contacto contigo, en todas y cada una de las páginas. La idea es solo utilizarlo en aquella donde no necesitamos. Entonces, combinar esto que estábamos viendo. Si yo mi página de contacto la tengo en barracontacto, pues yo sé que cuando no sea barracontacto, lo que te va a hacer es no ejecutar eso. Y os puedo asegurar que en el caso de Contafone, muchas cargas, porque, mira, a ver si hay algo activo en esa página, si no está en esa página, ¿vale? Pues eso sí, son plugins de frontend, o sea, que tienen que chequear y ahorran mucho tiempo. Voy a enseñaros el paso 13, como siempre me interrumpís cuando sea. Un ejemplo basicísimo. Oye, cuando no sea barratienda barracontacto, el plugin de Contafone me lo quitas, ¿vale? En mi caso, como veíamos antes, yo tengo, evidentemente, una página habitual de contacto con el plugin de Contafone instalado. Si me vuelvo a la home y saco el código fuente, hay una serie de, aquí, seguro que he conocido por vosotros, ¿no? Hay una serie de JavaScripts y CSS que Contafone, por si acaso, añade en todas y cada una de las páginas. En este caso es la home. Tenemos ahí el CSS y aquí el JS, ¿vale? Que lo tenemos ahí. Pues vamos a hacer eso. Vamos a hacer esa prueba. Vamos a activar el paso 13. Como veáis antes, era. Y vamos a mostrarlo directamente, solo en la parte del código. Me acabo de quitar Contafone. Es que no lo necesito. No lo necesito en la home. Acabo de solucionarlo. El plugin solo se ejecuta en el vaquén, por supuesto. Y en la URL barratienda barracontacto. Sí. Ya llegaremos. Ya va, jude, este. Uy, uy. Ahí sí que ya. Hay así el armacino, ¿vale? Sobre todo se veis trabajado con instalaciones grandes. Los vaquéns empiezan a ir lentos. También se pueden hacer ajustes de ese estilo. Ahora vamos a ver alguno. Voy a probarlo, por si acaso. Veamos, Fernando. Lo siento. Vale. Y le voy a dar a enviar. Contafone, no solo necesitas URL. Envía los datos, ¿vale? A través del lápiz. Los datos nos envía ahí. No, no, hija, utiliza esa URL. Yo no hablo aquí de res, ni acuerdos. Trabajamos a nivel de URLs. Pues ya está. No se me había ocurrido. Por eso os digo muchas veces el conocimiento del plugin. Os enseño mi paso 14. Estaba previsto. Tranquilos. ¿Vale? Cuando no sea, ni tiene contacto, ni sea este tipo de URL, que es la que utiliza, en este caso, Contafone para enviar el formulario. Atemoslo en la condición. Es decir, Contafone, en este caso, es necesario en dos URLs, ¿vale? Por así decirlo. Por simplificarlo. Sigue funcionando. Aquí está un poco hábil. El asunto que no es obligatorio. Al mensaje, por si acaso. Bueno, no lo voy a poner, para que sea igual que antes. ¿Vale? Y envío. Gracias por tu mensaje. ¿Por qué? Porque Contafone también está escuchando en esas URLs. O sea, que os puede pasar también con plugins de esos que tengan Ajax, ese tipo de cosas. Que seguro que ya tenéis muchos en la cabeza. ¿Dudas? Qué fácil es y qué peligro, ¿no? Pues seguimos. Vamos a seguir a otra tipología. Algo muy habitual en el desarrollo. Trabajar en local, en preproducción, en producción, en integración, en integración de equipo, en integración de máster, en integración de no sé qué. Y seguro que os pasa que, bueno, cuando estoy en local, activo este. Cuando estoy en producción, activo este otro, porque me hace falta. No puedo activar, llevas en local, porque no sé qué, no sé cuántos. No puedo activar o drag push, ¿vale? Hagamos, ¿no? También. Hagamos carga condicional. Escole mismo código. Y estoy realmente viendo lo que impacta, ¿vale? O pongo un ejemplo. Si estoy en local, para que me vaya más rápido, porque mi máquina, seguramente, no es tan buena como la que tengo en el servidor, pues, ¿para qué necesito el plugin de vaca? ¿Para qué necesito el deseo? ¿Para qué necesito el enmal? ¿Para qué necesito no sé qué? ¿Para qué necesito no sé cuánto? O a lo mejor, porque dentro de todo el proyecto, solo trabajáis en una parte. Y si el proyecto es muy grande, de esta manera, cuando estás trabajando en local, haces esa carga condicional y te va a ir todo muchísimo más rápido, ¿vale? Esto llevarlo, posa un concepto de entornos. Oye, cuando desplegamos en Kubernetes, con el no sé qué, no sé cuánto, es barra local, barra, no sé qué, no sé, haces estos plugins. O sea, podríais tener incluso instalaciones replicadas, que activen, desactiven cosas. Este es el concepto, realmente. Es decir, incluso habilitar por cada uno de los entornos. El caso para mí, bastante habitual, porque normalmente no es el mismo entorno, ¿vale? Sobre todo cuando hacéis instalaciones. Y de esta manera, tenéis una réplica, por así decirlo, lo más fiel posible. Porque tú llegas a tu local host y lo desactivas, y te funciona todo. Y luego cuando activas, pues si lo tenías desactivado, probalo de esta manera. Por ejemplo, el plugin de Caché no me lo actives en local. Podría ser también, ese tipo de cosas. O plugins que utilizamos para conectar con un RP externo, y no nos funcionan en local, y tienes que estar entrando, desactivando. Beneficiemonos de ese tipo. Y vamos al ejemplo que decía esto antes. Oye, pues para ciertos usuarios que están logados, para ciertos usuarios que tienen cierta condición, haz esto, que es quitar un plugin, añadir un plugin o lo que sea. Puedo enseñaros, sería algo así. Función habitual, si la historia está logada. ¿Cuál es el único pero? He tenido que invocar a la fuerza el plogable, ¿vale? Porque si no, no tengo disponible esa función. Problema, que aquí ya no me aseguro 100% que no se haya cargado ningún plugin. Lo podría, aun así, consultar y demás, porque me estaría llamando a mí mismo. Y este es el ejemplo que decía antes. Vamos a probarlo. En este caso, lo que voy a hacer es, lo decía, el famoso aviso de cookies. Como ejemplo, pero podría ser, para vuestros usuarios, un caso concreto. Las noticias relacionadas en los usuarios conectados no salen, y en los usuarios no conectados sí salen. Por ejemplo, en vez de un if, pues esto sería más potente, por así decirlo. Voy a mi sitio, me sigue saliendo aquí el aviso de cookies, y voy a logarme, en este caso, a lo bestia, ¿no? Yendo para el administrador, estaría logado, ¿vale? Estoy simulando que soy un usuario logado, vuelvo a mi sitio, qué maravilla, tío. No me salta el aviso de cookies. Estoy súper tranquilo, pero le va a seguir saltando al resto, porque no están logados, o sea, hago una condición. Pues eso también lo podríais hacer, hacer una condición para algo concreto. Para los usuarios de tipo roll5, le hacemos esto. Estamos casi terminando. Esperaba muchísima más pregunta. Soy demasiado bueno. Continuamos un poquito más, ¿vale? Vamos a darle chicha, ya, de verdad. Hemos visto gestión por URL, ¿no? Y ya os ha venido muchas ideas. El lajon estoy implementando cosas que no necesito. En el barra contacto solo necesito, ¿dónde necesito el plugin de formulario? Esa parte de bucomer solo necesito en la parte de tienda, no lo necesito. Funcionamiento normal de todas y cada uno de los sites que tenéis, ¿vale? Pero no sé si sabéis que hay una URL maravillosa, es el wpecron, ¿sabéis lo que es? Y que se habla mucho sobre el rendimiento o el empeoramiento del rendimiento que provoca wpecron, ¿vale? Por defecto, en todas y cada una de las visitas, por si no lo sabéis, que llegan a vuestro sitio web, se ejecuta wpecron, ¿vale? Es cierto que hay una serie de estrategias para limitar el impacto para que se ejecuta durante cierto tiempo. Pero os aseguro que en sitios muy grandes el impacto es muchísimo mayor, porque lo que haces es ver todas las tareas que hay pendientes. Y a veces pueden ser muchas. Enviar el site map, porque no sé qué, un artículo que hay que publicar, vaciar la papelera x1000 funciones. Pues podemos también mejorar wpecron con esta técnica. De esta manera, cuando se ejecuta wpecron, que WordPress lo que haría sería lo mismo de siempre, invocar todos y cada uno de los plugins. Por eso, a veces, el impacto wpecron es tan grande, aunque no hagan nada, pero se cargan. De esta manera, le digo a mi instalación, cuando tengas que hacer una tarea de crón, quiero que me deshabilites este, este, este, este. Porque yo sé que son plugins que no hacen nada en la parte de crón y tienen mucho código y tienen una serie de cosas. Esto, en instalaciones grandes, os va a mejorar que no se imagináis. Porque la mayoría, a veces, no necesitáis todos estos plugins. Y se cargan. Se instancia, utiliza un espacio en memoria, utiliza un espacio de direccionamiento, o sea, se cargan. Y contafón, no sé, tiene, creo que no tiene ningún crón. El dejander es login, duplicar pods, hay una serie de cosas que no necesitan. Podríais hacerlo de esta manera. Le paso un listado y lo deshabilito. Acorda a los de este código, más el otro, más el otro, más el otro, más el otro, más el otro. Y ahora voy incluso a casos concretos. ¿Alguien utiliza el broken lin checker o sabe un poquito de qué va? Bueno, todos decimos que no lo utilizamos, pero luego los hagamos todo. Lo que pasa es que todo el mundo nos recomienda. Broken lin checker es un plugin muy, muy potente, porque nos hace muchas cosas. Nos buscamos RLs, nos marca, no sé qué, nos avisa. Pero tiene un impacto grande. Y entonces, yo, en ciertas instalaciones, por recomendar a mis usuarios, pues no utilizarlo. Pues, claro, medio que tiene lo mejor. 300,000 RLs que llevan metiendo durante 12 años, o de pues es una herramienta utilísima. Y te yo le pregunté. Dí, oye, ¿tus usuarios, tu tráfico en analitis, ¿cuándo tienes? Pues de, yo tengo el pico, empiezo a las 7 de la mañana. Y a partir de las 12 de la noche, no entra la gente. Digo, ya sé dónde se va a ejecutar broken lin checker. Cuando no hay carga de usuarios. Voy a utilizar esa técnica. Hacer carga condicional. ¿Cuándo tenéis vuestras horas valle? ¿Cuándo vais a consultar el blog de Mao, o el de Davidania, tu tarde desde España, normalmente, pues de 8 de la mañana a 11 de la noche? Pues en mi caso, concreto, yo lo decía. Oye, si esa de las 7 de la mañana a las 11 de la mañana, ¿vale? Broken lin checker se ejecuta con las tareas de crón. Oye, cuando sea la tarea de crón y estemos entre las 7 y las entre la mañana, no ejecute broken lin checker. Porque me afecta a los usuarios. Me bajas el rendimiento del servidor. Eso lo podéis hacer, como decía antes, incluso con ese concepto de TSAB. Oye, por la mañana, aplona el plugin de no sé qué, y por la tarde, el de no sé cuánto. Y luego mides. Y no es tocado nada del servidor. Magia. Hago el resto que teníamos antes. Podéis imaginar todo lo que ahora. Los backups, ese tipo de cosas. Esto, si además sabéis de programación de la parte de sistemas, el poder conectarlo, imaginaros a la gestión del servidor, poder preguntarle al servidor, imaginate si estás por encima del 80% ejecuta. Y si no, no. Imaginaron la potencia de poder tener eso. Sólo ejecuta lo acá, si la carga del servidor es por debajo del 23%. Ahora empieza a molar, ¿no? Y esto es básicamente lo que se puede hacer. Básicamente, a partir de aquí, imaginación todo. Nos hemos centrado en lo que es más fácil, en la parte de Frontend. Preguntaba, Juan Manuel, el tema de backend. ¿Dónde a veces también lo hay? Al principio, hacíamos ese isadmin. Sólo utiliza esto en Frontend, porque nos queríamos centrar sobre todo en eso. En instalaciones pequeñas no se nota tanto, pero en instalaciones grandes, la parte de backend tiene muchas llamadas AJAX. Seguro que la habéis visto. Vamos a ver un ejemplo, porque a lo mejor no la habéis visto. Voy a este aquí abajo para verlo. El vaquén, además de las peticiones, perdón, solo cuando cargo el caso del escritorio, además de esa petición, tiene por detrás una serie de llamadas que se están ejecutando. Pues en este caso, tenemos aquí, el parámetro es un resumen del VLC, es el bloc enlite checker. Si tenéis instalado el plan de analitis, esta gráfica se genera a través de un AJAX. Si tenéis bucomers, pues sabéis que se trae el número de pedidos, es decir, solo en ese escritorio que parecía que era una URL, yo estoy haciendo un montón de URLs. Y pasa exactamente el mismo comportamiento. Yo este, si este es el del bloc enlite checker, este, perdón. Esta es una llamada que hace a nuestro propio WordPress, donde le pide los reports. Desde hoy, no, desde hace 30 días hasta ayer. Le estamos pasando. WordPress hace exactamente lo mismo que veíamos antes. Cogela llamada, se va al listado de plugins, consulta todos los plugins y alguien coge esa opción y dice, esta es mía, pero hemos ejecutado todos los plugins. Pues vamos a hacer esa magia también, porque esto ya es un poco ya encaje, ¿no? He puesto solo esa parte de código, pero esto habría que mezclarlo con lo demás. Incluso yo es animo a que tengáis diferentes funciones para cuando quito en el front end y cuando quito en el y lo que hago es lo siguiente, ¿vale? Al mismo filtro que veíais siempre y le digo, oye, cuando estés haciendo un Ajax, Silación es la de Broke enlite checker. El acción estál solo carga el bloc enlite checker. Silación es la del Google, el WordPress este, Google enlite dashboard, solo cargas el plugin para que vas a cargar lo demás. Si es un escaneado de Sucuri, para que vaya a cargar lo demás. Si es el Herbit, no carga ningún plugin, ¿vale? No hace falta poner condiciones, ni cosa rara, ni rota un falso, no, ejecuta de aquí. De esta manera también mejoramos muchísimo la parte del administrador en ese tipo de acciones. No en el pintado, en el pintado tienen que estar todos los plugins, pero en una parte que necesito concreta la puedo mejorar de esta manera. Sí, lo que pasa es que si desactivas un plugin, imagínate que yo digo, en el WP Admin quito la MP, quítase la MP, no puedes acceder, estás jodido. Realmente lo que estoy haciendo es, solo en esa petición, que se defiere en la parte de Ajax, en vez de ejecutar todos los plugins y ver quién se queda esa petición, no, no. Tú cargas solo ese, que yo sé que es el que necesita. Esa ejecución va a ser muchísimo más rápida, porque solo estás cargando un plugin. Porque WordPress no sabe de quién es la petición, entonces tiene 18 plugins, llama a los 18. Y hay alguien que tendrá el actio, no sé qué, que es el que se la coge, pero entre medias hemos cargado todo eso. Cambiamos el handbook de los plugins. Claro, potente, el tema peligroso también. Y me quiero ir dejando un poquito más delicatessen. Hemos visto en una instalación un sitio único y demás, ¿vale? Imaginaos que tenéis un multisite. ¿Quieres manejar algún multisite? Esto, evidentemente, lo haríamos a nivel de site. Pero mola mucho más en un multisite, deshabilitar plugins en función del site concreto. Plugins que están activados a nivel de red, que en un caso concreto lo quiere desactivar, potentísimo. Y que no puedes hacer a través del administrador. Alguien te lo ha activado, pues lo puedes hacer a través de código. Lo haces para todos. Hay una condición, ¿vale? Hay un nuevo filtro que utiliza este, que es para la parte de multisite, y lo llama a los dos. Hay una variable global y yo le digo, de todos los blogs que tengo, en el 2 desactiva AMP. En el 5 activa, no sé qué, en el 7 quita tal. Esa es la idea. Puedes llegar incluso a ese control más concreto, por así decirlo. Esto, que os han activado a acordaros a nivel de network, que tenéis un plugin a nivel de network activado. Por mucho que antes en el administrador, no puedes desactivar. Lo puedes hacer. Yo activo yo a espátulos sitios, o el plugin que sea, menos para el 3, y luego por programación útil. Pues espero que lo disfruteis muchísimo. Muchas gracias. No sé si hay alguna pregunta, alguna sugerencia, más allá de que no rompáis nada. Sí, sí, por ahí. La única diferencia está, en qué momento lo hacen? Porque si ya se ha cargado previamente, no, si es a nivel de plugin, te vas a ejecutar por detrás de otro. Entonces, a mí, esas soluciones no conozco cómo está hecho por dentro, pero la única manera que he encontrado es esta. Y, además, entre medias he detectado lo del orden alfabético, porque me pasó en un caso concreto. Había un error, y es que había otro MIU plugin, que se ejecutaba antes que yo. Simplemente por tema alfabético. O sea, que a partir de este momento creo que los hago todos con guión bajo y guión bajo a punto PHP. O sea, me pongo el primero, sí o sí. Si te funciona y te está haciendo eso y te está dando solución, adelante con ello. Pero tengo mis dudas de que se ejecute en el momento concreto y, sobre todo, que puedas llegar a la granularidad que hemos estado aplicando, que es muy variada. De entornos, de URL, de IPs, de pfff. Es que puede ser de todo. Yo tengo ejemplos incluso con control de cookies. Alguien que le ha dejado una cookie y no le entregó un play. Qué maldades. Carlos. Hola. Déjame salir, por lo menos. Intentaré, si no, me apoyaré como no tengo ni blog, ni soy activo en redes, ni pues algún sitio común que todos encontréis. Es que esto me da miedo subir a los repositorios de Google. Esto tiene un peligro. A partir de ahí, bueno, un guijad o algo de eso, evidentemente, para que esté disponible. Por lo menos para que veáis un poco simplemente los ejemplos. Pero que esto es imaginación y, como habréis visto, seguro que si tenéis 10 sites, los 10 son distintos. Y las condiciones son distintas. Por eso es una estrategia muy de hacer a mano. Pero es muy potente, de verdad, ahorrar tiempo de carga en servidor cuando tienes mucho. No solo ahorras esa parte de tiempo de carga, sino que entregas menos solicitudes al cliente final. Es que no sé cómo lo hace por dentro. No sé cómo lo hace por dentro. Sí, sí, no. Yo esto lo empecé a implementar porque necesitaba unas cosas muy, muy concretas. Era un poco a mano. Entonces, teníamos que decidir eso. Usuarios de cierta IP país se entregaba esto. Y, claro, eso programarlo en un plugin no es óptimo. Hay veces que hay soluciones muchísimo más fáciles, ¿no? La típica de bucomer, ¿no? Eso lo habéis visto. No es bucomer, quita de la cola. Pero el problema es que el bucomer ya se ha ejecutado. Hemos ejecutado. Y yo lo que quiero transmitidos con esta estrategia es ponernos por delante, que no llegue a ejecutarse, que no llegue a necesitar esa instalación. Por eso, la única manera que he encontrado de estar por delante, porque ahora aquí no hemos llegado ni al tema. O sea, podemos influir incluso en este caso en tema de plugins. Podríamos influir incluso en el tema, porque nos estamos ejecutando un poco por delante. Esa es un poco la idea. Sí, bueno, que se caiga la web en producción. No era esperado. No, el ejemplo por ejemplo que habéis visto del Contafone, me costó ahora porque ya sé dónde buscar. Pero son, muchas veces los plugins, piensas que solo se ejecuta realmente de la parte visual. Pero tienen comunicación, front-end, y ese era uno de los problemas. Detectar, como tienes que manejar a nivel de URL, detectar realmente que URLs estaban fallando. Entonces, activamos los erros low con el OV double y montábamos una para detectar. Y era pues eso, un OVP-J, y eso no se quiere, que se lo estaba pasando por detrás. Dicías, Mica, un Lamar. O sea, que eso es lo más difícil. Una vez empiezas a entender, pues a partir de aquí, claro, pasa mañana cada uno que tenga el Contafone va a ir al código de Fernando Puente, el del Contafone, este y este, ya. Y todo aplicamos, hasta que Contafone saque la nueva versión y en vez de barra no sé qué, haga barra no sé cuántos. Pero es que estamos hackeando WordPress. Le estamos engañando. WordPress tiene 20 planes activos, pero en esa URL concreta, llama 15. El ejemplo que decía, ahora, que es potentísimo, el tema de las cookies, si yo he dejado a un usuario, le he pegado una cookie, porque ya he hecho una acción. A partir de ese momento, puedo tener muchas condiciones pero no hacerlo. De esta manera es muchísimo más potente. No le entrego el plugin de anuncios, porque ya hizo, no sé qué, ese tipo de cosas. Una duda más y de todas maneras, como siempre, me tendréis por aquí. No sé si he dejado por ahí mi Twitter, ese puente online, por si me queréis poner algo. Sí, perdón. Sí, como os enseñaba en el ejemplo antes, una vez instancias el Plugable, el podés acceder a ese tipo de cosas. Pero sí me he encontrado que a veces, llego tarde, es decir, no sé en qué momento WordPress, no he llegado a tanto, empieza a instalar plugins sin que yo me cuento. Lo he podido controlar, pero son demasiados if, if, if, if, hasta llegar a controlarlo. Entonces, lo más efectivo que estoy haciendo ahora, URLes, IPs, lo de las horas, lo de las horas, para mí ha sido un descubrimiento. Increíble, porque eso incluso me ha permitido hacer TSAV en, de verdad, en producción, que es muy difícil. Es muy difícil hacer TSAV. Y de esta manera lo hago. El tema de vais a utilizar muchísimo los test de rendimiento con el SIM plugins, con el SIM plugins. Imaginaros a nivel de tique de soporte, alguien que te reporta, oye, instala el plugin y tal. Vas en un momento, no le cambias nada, no desactivas, y puedes recrearlo con un parámetro. Y al usuario no lo acepta, eso es potentísimo, de verdad. Utilizarlo, al menos esa parte, aunque sea de bug, ¿vale? Iréis poco a poco, porque es difícil de irlo cogiendo. Pero hay cosas muy claras. El ajón no necesita el contafón. No necesito, no sé qué. Me lo jito, me lo jito, me lo jito. El duplicate pos. Hay 2 millones de instalaciones. Y lo cargamos. Eran 7 líneas, me da igual. Es que no quiero ni esas 7 líneas. Perdón. El Gutenberg, si lo necesita, sí. Gutenberg tiene back end y front end. Si lo utiliza, necesitan yestar un CSS. Estoy hablando de Gutenberg, si no diría editor de bloques. Correcto, ¿no? Gutenberg es el plugin. Aquí el señor me da lo que hay. Gutenberg es el plugin. Y lo que tenemos en WordPress se llama el editor de bloques. Ya había ejemplos que teníamos por ahí de bloques y demás que no se necesitan. ¿Qué sería? Bueno, gracias.