 Buenos días, como estáis. Espero que estéis disfrutando de la work-an y hoy venga a hablaros de carga condicional, ¿no? Y voy a intentar explicar qué es y para qué sirve, de una manera sencilla. Soy Fernando Puente, como me han presentado. Soy embajador de marca de Rayola Networks. Soy además profesor en el curso superior de periodismo deportivo y, bueno, consultor de nuevas tecnologías. Como decía antes en la presentación, pues llevo desde el año 96 trabajando en internet y soy un enamorado de comer y beber, así que cada vez que vengo a Sevilla lo disfruto muchísimo. Y como decía, vamos a hablar de carga condicional, ¿no? Es un término técnico. Voy a intentar explicar qué es, de una manera muy sencilla. Voy a intentar en una frase explicarlo, que es complicado, ¿no? Al final la carga condicional son una serie de instrucciones para habilitar o eliminar recursos en función, pues, de unos criterios que tengamos. Esto sería el que es, ¿no? Una definición. Luego iremos viendo más a qué nos referimos con todo esto. Y el para qué sirve es también muy, muy sencillo. Sirve para optimizar, para dar una mejor experiencia al usuario, para tener un mejor rendimiento de nuestro sitio, para liberar recursos, porque a veces no lo necesitamos en función de esos criterios que veíamos antes, ¿no? ¿Quiénes de aquí hacéis webs, levantar la mano, o desarrolláis, dejar la mano arriba, con WordPress o con lo que sea, ¿no? Y de todos estos que estáis con la mano arriba, ¿quiénes no estáis utilizando la carga condicional? ¿Estáis utilizando prácticamente todo, ¿no? ¿Quiénes no estáis utilizando carga condicional? ¿No? Es mentira. La estáis utilizando todos. Es una trampa, no lo sabéis. La estáis utilizando. En realidad son buenas prácticas. Y, voy, lo vais a ver con ejemplos, ¿no? Ya veréis o identificareis que lo estáis utilizando. Perdón. Vamos a ver ejemplos. Se me ha quedado el mando. Ahora, vamos a ver algunos ejemplos, ¿no? ¿Os suena esta porción de código? Estamos empezando a utilizar desde hace un tiempo. Esto es una carga condicional. Es una instrucción que le damos al navegador, en el cual le decimos, empieza a cargar esta imagen en un evento concreto cuando vaya hacia abajo. Otro ejemplo, las media queries de CSS. Esto también es una carga condicional. Es una buena práctica. A veces necesitamos cargar unos elementos CSS en función del dispositivo y otras veces, ¿no? Cuando cargáis una tipografía, que a lo mejor la tiene el usuario en local. Es otro ejemplo de carga condicional. ¿Lo estáis usando? Pero si es que lo estáis usando. Otro ejemplo más vinculado a WordPress. En este caso, cuando queremos encolar unos CSS o unos CSS en un momento concreto, que es en el frontend, porque si no lo haríamos siempre, volvemos a lo mismo. Son unas instrucciones para decir cuando quiero hacer algo en un momento concreto. Más ejemplos para que veáis cómo se está utilizando. Otro ejemplo, ¿no? Es una carga condicional de CSS en función del dispositivo. Esto también lo tenéis. Incluso el de la carga de las imágenes. Aquí le estamos diciendo diferentes formatos. En una instrucción, le estamos diciendo al navegador qué tipo de formato queremos que cargue en función del dispositivo o de la capacidad. O sea, que es algo que estamos utilizando. Y es una muy buena práctica la carga condicional. También se utiliza en JavaScript. Para, por ejemplo, cargar un JS en un momento determinado. Cuando nos han pulsado en un botón. Cuando hemos bajado el ratón. Esto también es una buena práctica. No cargar directamente el JS. Recordar el objetivo, ¿no? Queremos darle la mejor experiencia y en el mejor momento y obtener el mejor rendimiento. ¿Por qué cargamos entonces siempre todos los JS? O sea, a lo mejor no lo van a utilizar. ¿O por qué cargamos siempre todos los CSS? Si a lo mejor no lo van a utilizar. Ya sé que es muy cómodo cargar todo. Y luego me vais a venir en el pasillo a decir que es que si no los proyectos son inmantenibles. Mentira, ¿vale? Esta es la idea. Podemos ir a casos todavía más específicos, ¿no? Este es un ejemplo de cómo cargar solo ciertos bloques para algunos post-hike concretos en el navegador. También lo podemos utilizar para eso, ¿no? ¿Para qué sirve entonces en WordPress? ¿Cuál es un poco la idea? Lo hemos estado viendo, ¿no? Podemos gestionar estilos, scripts que queremos que carguen en algún momento concreto según nuestro criterio. Lo hemos visto en la parte de media. Podemos tener diferentes tipos de formatos y cargar unos u otros en función del dispositivo. Evidentemente lo que queremos es que cargue el más óptimo, pero al usuario le damos todas las opciones. En este caso, el usuario es el navegador. Es una pieza técnica. También puede ser en función del contenido. Le damos contenido distinto a unos dispositivos y a otros. No hablo del responsive. Eso no es contenido distinto. Eso no es carga condicional porque estamos entregando todo el contenido. O en función de la fecha y la hora. O en función de la fuente de donde vienen. También lo utilizamos y seguro que alguno de vosotros lo utiliza si su proyecto tiene algo relacionado con la geolocalización. Damos contenido distinto en función de donde están viniendo los usuarios o incluso no le damos contenido. Y hay un caso muy particular y muy interesante relacionado con la optimización que es la ejecución dinámica de plugins. Que es un concepto de carga condicional llevado a esas piezas de software que tiene WordPress, que se denominan plugins que nos dan prácticamente toda la funcionalidad. Bueno pues también y ahora vamos a ver cómo se hace también tenemos esa posibilidad. Recordar que cuando activamos un plugin el plugin se ejecuta en todas y cada una de las peticiones y no estoy diciendo páginas repito peticiones que llegan al servidor. Luego el plugin puede estar bien hecho y empezar con un if si no estoy en el admin no ejecuto y me salgo. Bueno eso sería una bastante buena práctica. Pero en el bajo nivel PHP ha tenido que reservar memoria ha tenido que reservar un hilo de ejecución estamos consumiendo recursos. Ahora lo que queremos es que directamente no cargue. Como veíamos antes por un criterio concreto cuántos de vosotros que tenéis esas webs tenéis un plugin un plugin de formulario de contacto que el plugin se está ejecutando en todas y cada una de las páginas. El formulario de contacto lo tenéis en todas y cada una de las páginas realmente no. Entonces por qué lo hacéis. Estáis haciendo una mala práctica no es que sea realmente una mala práctica que se ha diseñado WordPress pero ahora tenemos herramientas para poder corregir eso. Esto que denominamos carga condicional de plugins y lo vamos a ver con una serie de ejemplos. Os voy a explicar una serie de casos de uso que hay muchísimos que pueden estar adaptados o no a vuestro proyecto e incluso casos que se vayan a crear en ese momento para vosotros. En función de la página que esté visitando el usuario es un caso de uso como veíamos antes en el tema del formulario. Por ejemplo en el entorno de ejecución ¿tenéis a lo mejor los mismos plugins en el entorno de desarrollo de pre y de local? Pues a veces no. ¿Tenéis que ir entrando al administrador y ir deshabilitando? No. Lo podéis hacer dinámicamente. En función de la actividad o el dispositivo del usuario. En función de la fecha ahora que es un caso de uso que bueno yo me he encontrado en proyectos grandes. En función de las acciones específicas que tenga incluso el propio WordPress. Por eso insistí antes en la palabra todas y cada una de las peticiones. Porque WordPress se ejecuta no solo cuando el usuario visita una página sino también en otra serie de acciones como puede ser en la ejecución del crón o puede ser en la llamada de un Ajax porque están rellenando el carrito. Podemos tener también algún caso si tenemos un WordPress multisitio en el cual queremos deshabilitar y a lo mejor el plugin no nos lo permite porque se habilita para todo el sitio. Este sería también otro caso de uso. E incluso uno muy interesante es el de poder hacer pruebas específicas de velocidad. Llevamos muchos años hablando de WPO velocidad y demás. Pero al final estamos siempre midiendo la web con todos los plugins activos. Y luego te empiezan a preguntar como desarrollador que es ¿he añadido este plugin? ¿cuánto hemos empeorado? Técnica también nos va a poder permitir eso. E incluso medir la web sin ningún plugin. Sin tener que ir a la consola de administración y deshabilitarlos todos. Algunos ejemplos muy sencillo. Porque se implementa de una manera muy sencilla. Si es que es una función. Aquellos que habéis hecho dos líneas de código en WordPress, sabéis lo que es un filter. Es muy sencillo, hay que saber muy poquito de programación. Lo vais a ver ahora en un ejemplo. Hay un plugin que hemos estado utilizando durante unos años que es el plugin de MEP para gestionar el contenido. Con una línea de código puedo deshabilitarlo. Este sería el ejemplo. Eso es todo el código que hace falta para deshabilitar el plugin. Esto que va a hacer que cada vez que llega una petición no se va a ejecutar el plugin de MEP. Lo que le estamos diciendo WordPress es de los plugins que tiene deshabilitados el de MEP no lo utilices. Luego veremos el caso de uso. Otro ejemplo. Este es el habitual. El formulario de contacto. Tiene un plugin de formulario de contacto que solo quiero que esté activo en la página de contacto. Entonces mi criterio será que cuando venga el usuario a visitar la página de contacto le digo a WordPress. En este caso sí ejecutas el plugin de formulario de contacto. Y en el resto de casos no. Estamos ahorrando pensar la cantidad que le estamos ahorrando a WordPress en todos y cada uno de esos. Y le estamos dando una mejor experiencia al usuario porque recordar esta parte es la parte de PHP la parte que se ejecuta en el servidor pero si el formulario de contacto no se está ejecutando al navegador no le estamos enviando los JS, los CSS, es decir menor número de peticiones. El resto de páginas se van a ver beneficiadas de una manera muy sencilla con seis líneas de código. Acabáis de mejorar vuestra web. Otro ejemplo, en un criterio todos aquellos que tenéis una web con comercio electrónico y hay una parte que es el blog. En la parte del blog la gente está comprando no. Y porque seguís cambiando, cargando los medios de pago cargando bucomers cargando las zonas de envío en todo el blog. No, hacerlo dinámicamente. En la zona de comercio ejecutar tal y en la zona del blog ejecutáis otra cosa. Ese es el criterio que tenéis que hacer. Ese es el objetivo en este caso de esa carga condicional. El ejemplo del entorno que os decía antes. Mientras estáis desarrollando por ejemplo en lo caljós o como lo tengáis definido a lo mejor hay ciertos plugins que no os interesa. Porque no estéis trabajando sobre ello. Va a ser el plugin deseo o el plugin para esconder el login. Una serie de cosas. Dejáis esta línea de código subida y en función dinámicamente donde lo estéis ejecutando lo que les hará unas cosas, ahora otras. Otro ejemplo, otro caso de uso. Para ciertos usuarios que ya están logados porque le sigo dando el plugin de cookies. Si ya me ha hecho una aceptación. Son plugins pesados. Tiene mucho javascript, tiene mucho tan, los que no os aguanto. Pues esto es un caso de uso. Para el resto de usuarios va a seguir funcionando el plugin de cookies pero yo ahora determino que aquellos que estén logados en mi sitio, que son usuarios reconocidos y que han dado su aceptación pues en este caso que me he inventado este gritello, pues no se los activo. Vuelvo a reducir la carga del servidor, vuelvo a reducir el número de cosas que le envío al usuario. Le damos una mejor experiencia. El ejemplo que os decía antes de la medición con cuatro líneas de código. Voy a medir mi sitio sin plugins entonces cojo la url y digo esta página y le añado un parámetro sin plugins que me he inventado ahí, el parámetro sin plugins. Voy y hago la medición. Con plugins y sin plugins. Al menos ya tengo un criterio. Este ejemplo lo podéis ir haciendo con cada uno de los plugins. Voy a medir con todos los plugins menos con el plugin deseo. Voy a medir con todos los plugins menos el deseo, el de contazo. Os va a dar muchísima información que si no es muy difícil de hacer. O es que vais a la web desactiváis, prováis, no. Y sobre todo en torno de real. Todos estos ejemplos funcionan en torno de real. No utilicéis el sin plugins porque si no va a intentar todo el mundo inventaros un poco el parámetro. Pero ese sería vuestro criterio. Con un objetivo muy claro que es voy a medir velocidad sin los plugins ajusten más específicos. Por ejemplo en el crón. El crón es otra de las peticiones que hace WordPress cada cierto tiempo en el cual pasa lo mismo. Cuando se ejecuta el crón de WordPress se está llamando a todos los plugins. Y pueden ser muy pesados. Recordemos que hay webs con muchísimos plugins. Y a lo mejor el crón lo único que necesita es un plugin concreto. En este criterio que os estoy enseñando es el de criterio por hora. Que es un ajuste fino. Porque hay plugins de ejecución pesada como es este de Brooklyn Link Checker que lo que hace es buscar enlaces que están rotos dentro de nuestro sitio. Esto en un sitio grande consume muchísimos recursos. Si yo determino que mis usuarios vienen durante el día yo puedo decirla WordPress solo ejecuta estas acciones de búsqueda enlaces rotos por la noche acabo de optimizar. En este caso no está relacionado con la experiencia de usuario. Pero acabo de liberar recursos muy importantes para el servidor. Me aseguro que solo por la noche estamos buscándolos enlaces rotos los backups ese es el criterio que tengo y lo aplico a esa carga condicional en función de quién está entrando. Imaginais que estáis desarrollando para un cliente y quiero hacerle una prueba específica sólo para él. Oye dime tu IP el te da tu IP y dice vas a probar ahora la página sin el plugin de bucomers vas a probar ahora la página sin el plugin de mp le hacemos una prueba directa al usuario el resto de usuarios están viendo la página habéis creado un criterio muy interesante para hacer una prueba si no tenéis que montar un entorno de desarrollo que no es el mismo de producción y normalmente el cliente lo que quiere ver es el de producción hacéis el criterio y ejecutáis esa carga condicional de nuevo cinco líneas de código muy sencillos va a ahorrar mucho incluso esto lo podéis hacer con muchos entornos o con muchos is al igual que veíamos antes el ejemplo del crón tenemos lo mismo para las llamadas Ajax de nuevo en sitios grandes donde hay mucha actividad del Ajax porque hay carritos porque hay envíos al servidor sin recargar la página de nuevo cada una de las llamadas que se está haciendo aunque sea una llamada Ajax WordPress tiene que levantar todos los plugins y os aseguro que cuando viene a la llamada Ajax es para una cosa específica para añadir una cosa al carrito entonces porque levantamos el plugin de SEO o el plugin de copiar de seguridad si no se va a ejecutar vamos de nuevo a reducir no es un impacto en el usuario es un impacto en la parte del servidor aquí os pongo ejemplos cuando Sukuri está haciendo el escaneo no necesito el plugin de Sukuri o cuando estoy buscando esa parte de Brokeline Checker porque levanto el plugin de cookies si lo que quiero es buscar enlaces rotos estoy liberando de carga era el objetivo que veíamos al principio y el último ejemplo era un caso de uso que os contaba el principio que es también relacionado con multisite aquellas instalaciones de WordPress que tienen muchos sitios donde queremos hacer ajustes finos y obviamente el plugin no nos lo permite porque se activa para toda la red sería también un criterio que podéis hacer y combinar con los otros anteriores en toda mi red de sitios habilito todos estos plugins pero para un sitio concreto deshabilito este pues esta también os lo permite hacer y combinar todas que bonito no esto es maravilloso vamos a salir de aquí todos y implementarlo rápidamente hay una parte mala esto tiene muchísimo peligro y pongo ahí técnica muy peligrosa hay que conocer mucho de tu sitio, de los plugins de cómo se están ejecutando de cuándo se están ejecutando porque la funcionalidad de nuestro sitio normalmente está en los plugins si estamos desactivando podemos estar desactivando funcionalidades por eso quiero hacer hincapieno en el muy peligrosa bien ejecutada es muy efectiva si volvemos al ejemplo de antes del formulario de contacto tiene un pequeño truco porque todo el mundo diría yo quiero que el formulario de contacto solo se ejecute en la url de contacto si no no solo en la url de contacto sino también cuando le están dando al botón enviar es otra url insisto mucho en esa parte de conocer por otro lado son casos muy específicos en vuestro sitio vais a tener una programática muy concreta formular el contacto en tu sitio se llamará contacto y en el sitio de él se llamará contact y en el otro se llamará el contacto hay muy poca estandarización vais a tener que hacerlo un poco a medida os pueden guiar los ejemplos pero es un caso adaptado a vuestro sitio no existe una estanda como digo y es una técnica difícil de implementar cuando se combina con estrategias de caché recordar, si estoy cachando la página tengo una página cacheada no se ejecuta esa parte dinámica entonces esa combinación os hace de nuevo que sea difícil o una técnica por así decirlo muy peligrosa pero por favor, utilizar esta buena práctica que viene muy bien al servidor, al usuario y a la experiencia muchas gracias me vais a permitir un pequeño homenaje a esta comunidad de Sevilla donde yo arranqué dando charlas allá por el 2016 y curiosamente esta mi work-an como ponente número 30 o sea que quiero agradecer enormemente a esta comunidad de Sevilla que tanto me quiere y bueno pues gracias Work-an Sevilla y recordar un poco de lo que empecé hablando de la caché allá en el año 2016 pero no ha muerto lo de la caché sigue, sigue, sigue gracias