 Fernando Puente, informático de vocación, de profesión, formador ocasional, aunque ultimamente te veo, como se ayer hubieras estado dando unha charla en vellas artes, no? Sim, ayer creo recordar, sí. Beginner, de comer e beber. Siempre. 21 años de experiencia, pero tu quantos años tienes? Más de 21. Como se cuida, tío. 21 años de experiencia en tecnologías de la información, 11 de ellos en medios de comunicación online y desde 2007 en plataformas Wordpress para medios propios y proyectos de terceros. Despecializado en sitios internacionales de alto tráfico o comercio electrónico e vines aquí a hablarnos de UWPO. Eso voy a intentar. Pois, benvenido e muchas gracias. Gracias Juan. Hola, buenas tardes. Lo primero agradecer, por supuesto, al equipo de Ponte Vedra haber organizado esta work-an, haber seleccionado mi charla dentro de todas las que había. Daros las gracias a vosotros por venir pese a la hora que es, que ya estamos todos un poquito cansados, hemos comido y demás, a venir a escuchar algo relacionado con el UWPO, que puede sonar incluso a algo de siesta, no? Seguramente, se bajamos un poquito a las luces, alguno caiga. Como ha dicho Juan, soy Fernando Puente, soy informático, sempre me gusta resaltar de vocación e de formación. Para ser informático, para mí es necesario muchísima, muchísima vocación. Como sempre digo, veganer de comer e beber, así que aquí en Ponte Vedra me siento genial. E, pues como decía Juan, pues tengo máis de 21 años, porque eu tengo 21 años de experiencia en Tecnología de la Información. Trabajo como consultor enterprise para Sighground, trabajo como consultor de desarrollo de negocio para Giz, soy además el CTO desprime viajes e dormir de chollo, soy formador en la Fundación COPPE e soy además consultor técnico especializado en sitios de alto tráfico. E hoy venía a hablaros, pues que es esto del UWPO, que al final suena por aí, las siglas, está como de moda. Al final, hablar de UWPO es hablar de performance, de rendimiento, de optimización, todo o relacionado con as estrategias que podamos llevar a cabo para que nuestra web vaya máis ligera, máis rápida e consuma menos recursos. Básicamente seria eso, esa seria a la definición. Alrededor de ello, lo que vamos a ver hoy son estrategias, tanto para web, pero sobre todo, algunos pequeños tips relacionados con lo que veníamos a explicar hoy. Comercio electrónico. Realmente, quando hablamos de UWPO, pues para mí me gustaría que se hablara en los proyectos desde o principio. Lo que pasa es que no lo solemos hacer, nos acordamos del performance, cuando el proyecto va mal, se degrada, cuando necesitamos má recursos, cuando el cliente nos empieza a decir, oye, la web peor. E es cuando nos realmente nos preocupamos e decimos, esto como se puede mejorar. Se tuviéramos esas buenas prácticas del principio, no habría que hacerlo en ese momento. E como sempre, es máis costoso arreglar algo que ya está en producción, que ya está en funcionamiento. Así que, muchas veces, o que me pregunta a la gente, o se oye, al final UWPO está relacionado con velocidad. E yo pensé, jode, como explico esto en la work-hand de Pontevedra? E dije, ya está, super sencillo, con esta diapositiva, me van a entender perfectamente. Pues depende, no? Depende, es decir. Al final, el concepto no es que la web vaya a ir máis de prisa porque eu aplico estrategia de UWPO. Las estrategias de UWPO, lo que van a hacer es que mi site, mi sitio, al completo, mi sistema, mi base de datos, vaya máis ligero, seguramente vaya máis rápido, pero lo máis importante, admita máis conexiones, máis usuarios, enfocado en el mundo del comercio electrónico máis ventas, que é o que nos interesa. Porque a ninguno nos interesa que quando, después de conseguir el SEO, que o usuario llega está aí, a terrícel al Andy, le gusta el producto, justo quando le da al botón de comprar, le aparece un maravilloso 503, que non es un modelo de Pyo, sino que es un error del servidor. Así que o que vamos intentar, pues é, ver como se aplica, ver realmente quale son esas posibles estrategias que se aplica en UWPO, lo intentaremos ver en una serie de grupos, muy sencillo, hay una gran cantidad de información, seguramente no aplique a todos, pero sí os digo, aquellos que vayais aplicando estas estrategias, tanto a vuestra web, como a vuestra web basada en comercio electrónico, vais anotar que el sistema mejora. Como se aplica realmente o quale son las estrategias relacionadas con UWPO, son sencillísimas, vale? Eliminar aquello que non es necesario. A veces cargamos nuestro sistema de plugins, de información, de contenido que realmente non es necesario para lo que va realizar el cliente. Voy a poner 16 botónes de compra, para que? Porque seguro que así compra, pues seguramente no, seguramente lo que estamos haciendo es dan información demás. Optimizar, como os decía, el rendimento de los recursos, que non quere decir que vayan a ir má rápido, sino que tengo máis capacidad de procesamiento. Diseñar unha solución óptima, vale? Esto va en contra muchas veces de esos conceptos responsis, unha solución para todo. Realmente, a solución óptima casi siempre suele ser distinta, porque o usuario de desktop navega e compra distinto do usuario de móvil. Se os capaces de generar unha solución única para todos e cada uno dos usuarios, necesitará menos recursos e será muchísimo máso óptimo el proceso de conversión. Liberar de carga los recursos que non sean necesarios, pues que yo en mi servidor, pues tengo FTP, SMTP, SSH, non sé que non son buenos, pero lo tengo por si acaso, el por si acaso, no me hace falta. Libero recursos. Todo o que tengo instalado en el servidor, consume. Aplicar o último en tecnología, por supuesto, porque cada vez avanza má rápido e está disposición nuestra, reducir el impacto de los recursos de terceros, la gran cantidad de scripts que vamos sempre integrando de, pues, las fuentes de un script para añadir un tag, de un tag, del tag, vale? Eso vamos a irlo liberando. Realmente non lo necessitamos e vamos a reducir el impacto e a estrategia que casi sempre falla es la del sentido común, vale? Veréis, incluso ahora con ejemplos en detalle, non se me oye máso o menos e eso que voy subiendo, bajando el volumen de vos, ahora sí, cuando vengo para cá, pero es porque te llevas en micro, no? Aquí sí, aquí sí me oye, perfecto, pues nada, non me moveré, me estaré aquí quitecito. Así que, como lo decía, vamos a hablar de UWPO para web e UWPO en cierto detalles para comércio electrónico e empezamos desde lo más básico, vale? Lo que sería lo que llamamos los hierros e el software, al final esto es el hosting, no? Quando estamos hablando de el servidor onde lo vamos a poner. Que es lo que necesitamos aquí? Que tengamos lo último en tecnología, servidores con NGINX, con PHP FPM, que tengan Http2, que tengan los discos, algo que normalmente, casi todos ya tenéis e es o que están ofreciendo todos e cada uno de los proveedores de hosting actuales e que están especializados en WordPress, que tengan una versión PHP 7 o superior, yo recomiendo a partir de la 7.1 que tengáis un excelente servicio DNS, que es uno dos grandes olvidados e donde perdemos muchísimo tiempo, que utilicéis un ACDN, que utilicéis tecnologías PUS para los contenidos estáticos, tanto CSS como JS, que utilicéis servidores, lo que denominamos elásticos, que pueden crecer, que pueden escalar sobrevivo servidor, puedo tener má recursos, que esté cercano a vuestros usuarios, importantísimo. Se yo voy a dar servicio en España, aunque hosting sea aparatísimo en la outra parte del mundo, seguramente va a ser mucho máis interesante contratar algum servicio lo máis cercano posible al usuario, e sobre todo un hosting especializado en WordPress, por el servicio y el soporte que nos van a dar, es la pieza clave, por algo máis, agora, sí. Si vuestro e commerce está caído, quántas ventas ois capazes de generar? Seguramente cero, seguramente, no me atrevo a decir una, pero seguramente cero, importantísimo, la partida del hosting, porque al final es donde dejáis todo lo necesario para poder realizar el proceso de venta e truco co-cordejo aquí, que veo muy pouco a hacer a la gente, monitorizar qual es el consumo que estáis teniendo de los recursos. Só lo nos acordamos de mirar el servidor, cuando se nos ha caído. Mirar si estáis ya consumiendo en el último mes el 80 o el 85% de los recursos, porque el día que tengáis un pequeño pico, no lo vais a poder aguantar, porque estáis en el límite. Seguimos con el siguiente grupo, el tamaño y el peso que siempre importan, parece que no, pero siga importando. Utilizar algoritmo de compresión, tanto gc como deflay, de decir, comprimimos los archivos en el servidor e los enviamos comprimidos. Utilizamos menos carga del servidor, minicicarlos, es decir, vamos a eliminar todos e cada uno de los caracteres que no son necesarios. Por que digo ese pequeno truco del javascript? Porque el propio bucomers no lo recomienda, recomiendo mucho test, test, test, test, test, hay muchas librerías por ahí de el javascript que poda ser que os den algun error e antes de que vayáis al botón de minifico todo, vale, aplico minify, test, test, test, aquí tenéis información adicional, combinar las Google phones e la vais utilizar en una sola llamada aunque recomiendo en utilizar, es decir, esa estrategia de liberar recursos del servidor. En el caso de las imágenes importantísimo, esta es la mayor optimización y más fácil que se puede hacer, subérlas en el tamaño máximo para que necesito, aunque la cámara me haga fotos a 8 megapixels 16K, 24K, lo que sea se luego el tema lo máximo que admite es 1.200 de ancho no necesito subirlo más, vale, aplicar algoritmos de compresión, eu uso el 75% eliminar todos aquellos metadatos que no son necesarios e non os vao utilizar el cliente generar los thumbnails no aplicar, este es un error bastante común, el Gc-well-deflit a las imágenes, non es necesario las imágenes ya tienen un algoritmo de compresión, utilizar JPEG progresivos se utilizáis HTTPS 2 sí disponéis ya de los novos formatos webp empezar a utilizarlos son más óptimos, e aplicar este concepto de carga perezosa, este lazy load para todo aquello que no se va a ver, porque al final se o usuario non desplaza la imagen porque estamos cargando, no desplaza la pantalla porque estamos cargando de información innecesaria nuestra página web, es decir, esas páginas e esas imágenes que llevamos abaixo como sempre, tu amiga la cache esto no va resolver mil y un problemas cache de todo tipo de todo tipo, de la de navegador del plugin de cache cache de objetos la propia cdn, en la base de datos el mayor problema que tenemos con las instalaciones de comercio electrónico es el uso continuado al igual que nos pasa con las instancias de wallpress pero en bucommerce todavía máis es el uso continuado de acciones hacia la base de datos, intentamos con esta estrategia limitar os acesos hacia la base de datos con especial cuidado en lo que serían las estrategias con un proxy inverso lo que se llama reverse proxy porque tienen una configuración especial hay ciertas páginas que no se pueden cachear a del carrito la de la cuenta parece algo obvio pero yo os pudo asegurar que he realizado consultorías donde entras en un sitio e empiezas a ver la cuenta del otro, carrito del otro porque han hecho unha estrategia de cache fabulosa, todo mundo ve lo mismo como se prueba de una manera muy fácil truco, facilísimo lo podeis hacer todos, quando tenis vuestra tienda yente grada, sencillo con el ordenador que tenéis en vuestra oficina, en una localización es decir, utilizar la misma conexión abrís dos navegadores y utilizáis dos usuarios hacéis un proceso de compra por supuesto para validar que todo funciona e verificáis esas tres urls esas tres urls tienen que ser distintas con eso sabréis que no estais cacheando objetos para dos usuarios que es el maior de los errores se poden hacer más, pero con esta tenéis esa seguridad de que no estais metiendo a parte de cache el armario, donde guardamos las cosas se verán o olvidado la base de datos estamos todo o dia hablando de optimizar actualizar WordPress limpiar y demás e sempre nos olvidamos de lo máis importante que no necesita mantenimiento al final a base de datos se basa en un sistema que está guardado en disco donde se meten continuamente índices, donde se meten continuamente datos es decir, requiere de un mantenimiento continuo estrategias que tenemos que hacer pues habilitar también cacheis a nivel de queries ese mantenimiento constante utilizar algo que ahora mismo ya es obligatorio e no debe en todos e cada uno de las instalaciones pero que todavía en instalaciones antiguas siguen utilizando el anterior motor de base de datos e máis pequeno truco añadir esa que seguro que lo habéis visto cien veces añadir un pequeno índice en la tabla ovp options para el tema de los autoload e no hagáis experimentos raros que los hai e son compatibles podí montar un WordPress con posgre con SQL server, con azure no hagáis experimentos raros nos jogueis vuestro comercio electrónico por instalar algo que no es 100% compatible ante a pregunta que seguro que os han hecho mil e unha veces al final que xima sql que xi maria db que xi percona qual es realmente o mejor eu os respondo de una manera muy sencilla e me o habéis hecho muchas veces o mejor sistema seria aquel que no tuvieramos que llegar a la base de datos porque la base de datos es el máis lento e realmente hay muy poquita diferencia e quizá maria db es un poquito má rápido pero estamos hablando de mil e segundos o jala no tuviera que llegar a la parte de base de datos sí que os digo que a partir de la nova versión de máis sql que acaba de salir que es la 8 seguramente no tengáis todavía disponible cambia completamente e nos iremos todos de novo a hablar de máis sql llevar siempre lo justo e necessario al igual que hacéis en vuestro dia a dia aquellas cabeceras que no son necesarias machete con ellas os emojis os enbech todo aquello que no vallamos utilizar e que WordPress lo inyecta por defecto no lo necessitamos e o usuario no lo necesitan para que se lo vea a dar reducir el herbito eliminarlo deshabilitar el cron interno e sobretodo revisar todos e cada uno dos procesos cron que tenéis en vuestra máquina porque a lo mejor no son necesarios aplicar limpieza e pulcritud a vuestros servidores igual que hacéis en vuestro disco duro del portátil o Mac donde utilicéis del sistema de escritorio vuestra apepia actividad diaria não guardéis o que se denomina o famoso síndrome de diógenes estou arto de hacer auditorías en sitio onde pone foto 1 foto 1 ok foto 1 temporal foto 1 temporal ok ok 2 foto 1 ok po se acaso pues siguen estando aí e eso al final não benefician nada e po se acaso, se tengo 100 gigas de disco ya pero al final es un recurso que estamos cargando innecesariamente porque carga o zoomness porque estamos utilizando espacio de la base de datos nos imaginéis la cantidad de cosas que hace WordPress simplemente por añadir un archivo máis muchísima muchísimas cosas e seguramente no sean necesarios igual que las categorías etiquetas que no utilizamos revisión de artículos que no vamos a utilizar imagínese zoomness comentari hay una gran cantidad de información que realmente no nos hace falta e podemos eliminar o prescindir incluso algo que supera arregado o log de servidor quantos habéis mirado este último mes os blogs de vuestro servidor o resto sabéis que tenéis blogs de servidor seguramente os podréis ahorrar e aplicar o sentido comum é o que menos solemos utilizar xeños sencillos estamos optimizando para procesos de compra o má sencillo posible o má sácil que o que queremos es la conversión que o tío dé al botón comprar por supuesto nas actualizaciones mantener vuestro HT ACES en forma não significa que entreis continuamente en ayuda a WordPress e todos e cada uno de los trucos que pone Fernando del HT ACES lo metáis primeiro mirar si va a vuestro proiecto no que es que a lo mejor no va en vuestro proiecto éso significa tenerlo en forma de carga sincrona o diferida de todos aquellos recursos estáticos o cargo quando puede o navegador o cargo má estarre o importante é cargarlo antes posible mas no mejor no todos os recursos sino a hacer ese efeito de prestidigitador que parece que a página va apareciendo porque xe non o usuario se cansa e dice bua esto tarde muchísimo a carga condicional de aquellos plugins que no sean necesarios no programar se os metéis en la parte de programación de datos no es óptimo éso é un pouco o sentido agomor que cosas podemos aplicar adicionales en casos concretos de comercio eléctronico huir de los famosos temas que se llaman por aí os temas desmultipropósito o multi despropósito utilizar temas ligeros e que estén optimizados para comercio eléctronico fundamental a memoria mínima que tenéis que utilizar se utilizáis bucomer 628 megas pero na recomendación un pico de tráfico concreto é que a memoria que tengáis disponible sea maior ao tamaño de la base de datos é sempre a recomendación e utilizar un SMTP externo sabéis que todos os procesores de compra conllevan notificaciones a través de e-mail e a lo mejor por tener ese servicio en la misma máquina não realiza convenientemente o WordPress o processo de compra é melhor que ese proceso sea asíncrono e que esté delegado en outra máquina se já tenéis megatiendas que supongo que é o caso de casi todos aqui pois oe establecer modelos en capas escalar os servicios como eu pudo crescer de que manera eu pudo aislar todos e cada uno dos servicios que corresponden e teniéndose modelo de capas poder escalar más fácilmente utilizar dominios o que se llama sin cookies para que a transmisión de datos sea muchísimo menor que os muchos de las grandes plataformas utilizar o cache de objetos graças a utilizando a plataforma de Redis desabilitar aquellos widgets de estado de bu porque não se imagináis lo que consume em grandes tiendas ese widget que tenéis a entrada do escritorio que os dice quánto has vendido, quántos produtos e demas não se imagináis a carga que meten na base de datos quando tenéis 100 mil, 200 mil 300 mil pedidos é muito custoso e vai ser de datos de escritura e vai ser de datos de lectura porque a veces só necessita consultar toda a generación de informes pero se vas a cambiar as opciones utilizas a parte de escritura essa estrategia es utilizar una base de datos como maestro e outra como esclavo desabilitar incluso o lo binario a nivel de base de datos que son operaciones de entrada a salida isto evidentemente es cuando hai mucho volumen transaccional nos tiendas utilizar incluso estrategias de elastic search para a busqueda de índices es decir ir creciendo e não utilizar a base de datos e é importantísimo não usar os informes por defecto de bucommerce además de que son malos e melhor que preparéis una plataforma específica com o informe que queréis obtener de vuestro comercio electrónico e extraiga os datos extraiga a la información e os datos de esa maneira unos pequenos tif seguir este proyecto o dejaré comprimido e demás este proyecto es super interesante porque o que están haciendo é cambiar o modelo de datos do actual bucommerce e empezar a separar todo o que son las tablas de las órdenes de pedido es muy importante porque van a liberar muchísima carga do actual base de datos e va a ser muchísimo máso óptimo quando estes desarrollando dos plugins indispensables o query monitor e este que lo que haces complementar com toda a información que va recogiendo sobre se habéis estado en la charla de Mauricio tolo relacionado com os hooks as acciones filtros e demás vai dar muchísima información de o que está pasando podéis hacer test de estrés importantísimo antes de subir una tienda ou en la fase de pruebas utilizar estas plataformas utilizar simuladores para ver como funciona mi tienda monitorizar dos herramientas indispensables para monitorizar tanto a nivel de navegador como este que nos da os reportes porque al final o que nos va a pasar é esto se tu sitio non é rápido para un usuario e os digo que non va a ser rápido ni para 100 ni para 100 éxo é a ideia me quedo con ésta não hai perguntas como só tenemos un micro não hai perguntas hola juan que tal como estás podrias recomendar algum programa de para monitorar o orpreso o servidor para monitorizar new relic indispensable es carillo pero queres vender o no se estou usando era por si había alguna alternativa ximas con a información o primeiro toda a información que te dei o proveedor de hosting por supuesto a nivel de desarrollo sutilizas éxos dos plugins sabes perfectamente o que va a estar pasando non recomiendo por éxo puesto desarrollo non recomiendo os plugins habilitarlos en entorno de producción porque meten una carga adicional importante pero éxos me parecem fundamenta o insight temo uma versión creo recordar premium perdón una versión free bastante reducida que te da uma gran cantidad de información si no não te convence o que te da información te da como o error o que sea não te da despues la raíz o información realmente útil está bajo pago en ese de tal maneira são os que utilizo recomiendo porque va muy bien porque realmente quando tienes problemas é muy difícil encontrar a posible raíz del problema sobretodo en WordPress pensar que a ejecución pode venir de cualquier sitio e pode saltar del problema de cualquier lado se en el proceso de desarrollo en el proceso de desarrollo, en los entornos de preproducción e demás o posible error éxos test de estrés são increíbles porque aí sí que te dan un montón de información respecto a eso montas tú un tienda en el entorno de preproducción cargas mil ordenes de perdido 10 mil produtos e le dices a mí un test de estrés de mil usuarios realmente están en el entorno de preproducción e empiezas a ver pero rápidamente donde tiene os errores donde cai e muchísima vez pode ser por algo rarísimo de no se que que me deja activa o no se cuánto que na cache non la tengo bien configurada todo o que podas hacer en paso previo evidentemente sempre es mejor que en producción pero es que en producción por suposto te podes encontrar este tipo de errores porque la gran maravilla de internet que cada usuario se comporta de maleña diferente aí me encantaria que todos se comportaran igual que en llegaran a la página desplazaran con la rueda, dieran al botón, metieran, pero non lo he conseguido, ni con videotutoriales. Aí, al centro. Ya vai que eu já estou traduciendo esta pregúna. Para que preguntan, sí, como hacer o performance para una tienda de bucomers que tiene a su vez varias tiendas. Muchas sites con un solo bucomers. Pero es un bucomers, o sea, un multisitio con muchas tiendas por debajo, pero el proceso es exactamente igual. O sea, no hay algo en especial porque sea un, dime. Porque cada site tiene 11 tablas. Si tienes 100, basicamente es lo mismo y tiene que serlo por cada una. Sí, el modelo es escalable. Es decir, todo o que hemos hablado, se es una tienda, el conceptor de multisite evidentemente escala. Es igual que quando tenemos, no es lo mismo, una tienda de 10 productos que una tienda de 100 productos, porque a cantidad de metadatos que se van añadiendo a base de datos se multiplican exponencialmente. A lo mejor, a primera recomendación que te diría de performance es no utilizar multisitio. Seguramente. Es má fácil de administrar, pero cuando quieres ir al ajuste fino, seguramente las 10 o 11 tiendas que haya por debajo no sean iguales. Seguramente no sean iguales e tengan ciertas particularidades. El ajuste fino en multisite es muy complicado porque normalmente afecta a todos mientras que si son instancias separadas de WordPress puedes hacer un ajuste fino de todo ese cada uno. Sí? Alguna pregunta vez? Hola, sí, mi pregunta está relacionada con UPML, este plugin que todos conocemos de multilenguaje. Es súper lento. Pero el plugin o la máquina que lo ejecuta? Pues no, no, es el plugin. Ya hemos hecho un montón de pruebas, la máquina está en... digital ocean... E... que podemos hacer con un plugin de esto que es... Ya, pero sí, la respuesta la tienes tú mismo. Se me está diciendo que el plugin va lento, la solución es gitar el plugin. No, está un fácil de una tienda que ya está bastante grande, es una empresa muy burocrática, hay un equipo de personas trabajando ya para cargar productos y tal. No es un opción de momento cambiar de plugin. O que es el plugin de Cache que podemos implementar en estos casos. Son plugins muy grandes que no es un opción que tarlo. O mejor performance que podes utilizar es la estrategia de Cache, es decir, con toda la estrategia de Cache o que hacemos es que no molestamos ni a WordPress ni a la base de datos. Si no molestamos a WordPress non utilizamos el UWPML. Sí que es cierto que UWPML e me meto ya... a fondo con ele, que podria quentar realmente en eso. Por exemplo, uno de los problemas que tiene UWPML es la cantidad de metadatos que añade. Entonces, todos esos metadatos hay que hacer eso que os ponía yo de mantenimiento de base de datos, que realmente no debería hacer el plugin. Se yo no necesito esta cantidad de traduciones porque me las estás cargando en la base de datos. Es parte del mantenimiento. Pero sí que es una tarea específica del plugin UWPML. Mi recomendación, la estrategia de Cache, siempre, para no tener que molestar al plugin e no tener que molestar a WordPress. Mejor que eso, se podes quitar-te o plugin porque ya no tienes detectado que da fallo pues blanco e en botella. No sé como se dicen Galicia, blanco e en botella. Igual, né? Nada más. Muchas gracias.