 Hola a todos. Mi nombre es Mariano Álvarez y para mí es un placer estar acá. Le agradezco muchísimo a la organización de WorkCamp. El día de hoy, vengo a hablarles de Core Biles, que es, y poder descubrir un poco más cómo nos pueden ayudar a las herramientas de Core Biles. Les hablo un poquito de mí. Trabajo como full start developer en la compañía Telescope. Soy Google Developer Expert y por acá también les dejo mis redes sociales y Mariano Codes, donde en realidad siempre estoy compartiendo contenido y me encanta conectar con personas, así que mandenme ese connect y estamos conversando. Demos inicio. ¿Qué es rendimiento? Bueno, pues rendimiento es interesante porque pongámonos este ejemplo. Tenemos una página web en la que la cargamos, ¿cierto? Y si la página carga rápido, si sus imágenes se escargan rápido, si vemos texto rápido, pues percibimos o pensamos que es una web que está optimizada, ¿cierto? Pero pareciera que nos estamos enfocando solo en el contexto de nosotros y no en el contexto de otras personas, pues estamos corriendo esta página, tal vez en unas condiciones que no todas la tienen. Entonces, pues pareciera ser que el o es más bien que el rendimiento es un tema de relativo. Y les pongo estos dos ejemplos. Tenemos una persona a la que le ponemos dos páginas web que son exactamente igual con la única diferencia que una de ellas carga un elemento un tanto antes o muestra o cambia un color, se aparece un texto, un imagen, pero la página es funcional exactamente al mismo tiempo que el otro. Si le preguntamos a esta persona cuál página es más óptima o cuál percibe que es un mejor rendimiento, pues va a decir que la página que tal vez le mostró, la aplicación que le mostró, un elemento antes. Pero la realidad es que no es así. Lo único que cambió es que se le mostró algo antes de que la página fuera completamente funcional. Entonces, estamos viendo que es un tema relativo. El segundo tema o el segundo ejemplo es no todas las personas cuentan con los mismos dispositivos. Entonces, supongamos que una persona tiene un dispositivo de alta gama con unos specs altos en una geografía buena con una conectividad buena para esta persona. Es probable que su aplicación cargue rápido. Pero qué pasa para todas aquellas personas que tienen un dispositivo que no es tan bueno. Sus specs son bajos y se encuentra una geografía en el que la conectividad no es buena, no es tan cerca de un data center. Y la página pues no carga tan rápido. Entonces, ¿cómo podemos decir o no nos podemos basar en el hecho que porque a la persona que tiene un teléfono con specs buenos y conectividad buena y se le carga rápido no es, no podemos afirmar de que la página es óptima. Hay que ser justos con todos porque no todos tenemos todos los dispositivos iguales y pues vamos a tener un comportamiento diferente. Entonces, debemos encontrar como un balance y a cada donde entran los webpiles, ¿cierto? Entonces, ¿qué son los webpiles? Básicamente, los webpiles específicos específicamente es una iniciativa de Google para poder definir guías para nosotros desarrolladores para crear excelentes experiencias para los usuarios. Ahora, dentro de los corepiles vienen los, perdón, dentro de los webpiles vienen los corepiles. Estos corepiles es un subconjunto también de elementos que vienen listados en las guías que son medidos por todas las aplicaciones de Google de rendimiento y es aplicado a todas las páginas. No hay diferencia. Entonces, es como un pequeño subconjunto necesario y que Google especifica que toda página de cumplir para que sea una página óptima. Ahora, también los webpiles es importante saber de que están completamente enfocados en las experiencias del usuario y también que evolucionan en el tiempo. De hecho, los últimos tres corepiles fueron definidos en el 2020. Entonces, Google, lo que quiere es asegurarse que con estos indicadores que vamos a ver más adelante y métricas, lo que quiere Google asegurarse es que se enfoque en la parte de la experiencia en sí del usuario. Ahora, cómo se definen estos webpiles? Bueno, el equipo de Chrome junto al W3C Web Performance Group han venido trabajando desde hace tiempo en primero en APIs para poder estandarización y capturar la información para poder hacer este tipo de mediciones. Y luego también han trabajado y desarrollado las métricas basados y intentando responder estas preguntas. Entonces, si la primera pregunta que ellos se hacen al evaluar una métrica o al enfocarse en la parte de métricas es qué es lo que está sucediendo en la página. Y con esto hace referencia. La página ya inició o ya respondió el servidor, ¿verdad? La segunda es útil. Tiene suficiente información para el usuario, pues para ser utilizado, para ser atractiva para el usuario. Es utilizable. Y con esto nos referimos, ya puedo dar clics, ya puedo interactuar con ella. Y por último, es atractiva. Si las animaciones se ven bien, si no hay un lax, se mueven lento, ¿verdad? Entonces, los corepiles y los webpiles en general intentan responder a estas preguntas con el objetivo de enfocarse en la experiencia de usuario. Ahora, pero ¿cuáles métricas existen? Tenemos la primera que es el Largest Content Paint. Y esta métrica, básicamente lo que hace es poder determinar cuál es el elemento más grande dentro de la pantalla, en la parte visible, y cuánto tiempo está durando a encargar. Ahora, si ustedes ven, hay un abajo en esta barbita de verde, amarillo y rojo, pues estos son los indicadores que nos dicen si el elemento está cargando de la manera correcta o a qué velocidad de cargar para pues estar bien, estar más o menos, o estar mal. Entonces, este indicador lo que nos dice es si este elemento carga de 0 a 2.5 segundos entre ese tiempo, pues estamos bien. Es lo aceptado por las métricas. Si es de 2.5 a 4, pues hay un espacio mejor, y si es más abajo de ello, pues estamos mal, ese elemento está tomando muchísimo tiempo encargar. Ahora, tenemos también el First Input Delay, que de nuevo lo que nos dice es cuánto tiempo dura la aplicación en reaccionar a un evento. Y esto es importante. Más que todo, no es en el momento que se le hace trigger al evento, no importa lo que esa función o ese evento llame a esa función, no importa lo que dure esa función llamarse, sino que la página escuche y el evento al que le damos. Por ejemplo, si le damos click, lo que importa y lo que mide de esto es cuánto tiempo duró la página en escuchar o escuchar. Si hubo un click, después, si la función a la que llama dura 10 minutos, eso realmente no nos importa lo que le importa a Google. Y a las métricas en sí es saber el tiempo de reacción. Y esto es lo que se enfoca en interactividad. Entonces, si es de 0 a 100 milisegundos, pues estamos bien. Si es de 100 a 300, hay espacio mejora. Y si es menos, pues de nuevo, estamos mal. Y por último, en el caso de los Core Battles, tenemos el cumulative layout shift, que esto básicamente lo que nos dice es si hay, existen elementos que a la obra de la carga se están moviendo, ¿cierto? Entonces, creo que esto es un error común que los desarrolladores enfrentamos y el ejemplo más claro es cuando tenemos un texto y hay una imagen que no ha cargado y el momento que carga, pues hace hacia abajo el contenido. Esto crea visualmente, pues no se ve visualmente tan atractiva una página y pues es evaluado. Entonces, en la métrica, lo que dice es si está entre 0 y 0.1, estamos bien, que está entre 0.1 y 0.25, hay espacio mejora. Y de nuevo, si no, tenemos que aún meternos más y ver cuál es el problema. Ahora, estas tres que les acabo de decir son los Core Battles en general. Son métricas que van a ser siempre importantes al tema de medición, pero no son las únicas. Ahora, estas otras que tenemos por acá son métricas que se leen, pero no son necesarias, son importantes e inclusive más adelante vamos a ver que algunas de estas reemplazan unas de ellas al momento de la medición utilizando las herramientas. Entonces, no dejan de ser menos importantes, pero las tres más importantes son las que les acabo de mostrar y que son las que definitivamente siempre se deben de medir. Ahora, ¿de dónde salen las referencias o los indicadores para cada métrica? Bueno, lo que pasa es que lo que se intenta hacer es que cada métrica se base en un estudio real. Entonces, en el caso de el Largest Contentful Paint, se basa de hecho en un estudio que es el Human Computer Interacted Interactation y que básicamente lo que hace el estudio es verificar o entender mejor el comportamiento entre las personas y las computadoras y cómo percibe en verdad la velocidad una persona con respecto a una animación o una ejecución dentro de la computadora. Entonces, basado en lo que el estudio habla y en los indicadores que se lanzan, pues se utilizan primero como referencia para definir como indicador hacia una métrica, ¿cierto? Como en el caso del Largest Contentful Paint, que lo que decía era de 0 a 2 segundos, estamos en el estado más óptimo de 2 a 3, pues está espacio mejora y si no, pues hay que ver qué hacer, ¿verdad? Pues estos indicadores pues normalmente vienen del estudio. Ahora, ¿qué pasa si no existe un estudio de estos? Entonces, lo que se hace es agarrar de la teoría de la métrica, ¿verdad? Lo que se anda buscando y probarla en sitios web que son muy utilizados y básicamente la manera en la que se lo hace es agarrando el 10% de un dataset que se llama el Chrome User Experience Report. Entonces, y más adelante le va a explicar un poquito más la profundidad de ello, pero lo que básicamente se hace es agarrar esa teoría de la métrica, aplicarla con datos reales y ver si es, si tiene sentido o no. Esta parte es importante porque inclusive hasta si existe un estudio es necesario hacerlo, porque imagínense que digamos, pues jugamos este ejemplo, pues obviamente para nosotros como desarrolladores nos interesaría que la página cargara en cero segundos, pero la realidad es que no es así, ¿cierto? Ni siquiera en local hosts podemos hacer eso. Entonces, tenemos que utilizar información real para saber si es posible que alguien pueda cumplir con esa métrica. Ahí es donde entra el 10% de la información que se utiliza para probar la métrica, decir, ok, a pesar de que el estudio dice que, por ejemplo, fuera un segundo, pues tiene más sentido que fueran dos segundos en el caso de Largest Contentful Paint, pues porque es una métrica que las personas van a poder cumplir. Y por último, ¿cómo es que mi sitio llega y cumple con la métrica en el sentido si está en verde, si está en amarillo, o si está en rojo? Bueno, pues aquí lo que se hace es utilizar la regla de presentar el 75, que lo que dice es de todas mis visitas, si el 75% de las visitas cumplen con el indicador de la métrica, pues perfecto. Tienes un sitio web óptimo para la métrica, pero si más del 25% de las visitas de este sitio no lo cumple, pues estamos hablando que es un sitio deficiente o con espacio a mejora. Este percentile es el que se utiliza para todas las métricas en el caso de las herramientas de Google, pero no es un percentile definitivo. Realmente eso depende dentro de nuestros KPIs o objetivos que tengamos como compañía en términos de optimización y pueden ir cambiando. Y más adelante, les voy a explicar cómo pueden ir analizando esta data y tomando ustedes sus decisiones. Ahora, ¿cómo pueden hacer ustedes para medir pues la optimización que tiene su página o medir su rendimiento? Existen dos herramientas y dos tipos, perdón, dos herramientas no, sino que existen dos tipos de herramientas. Entonces la primera es la herramienta de laboratorio, que básicamente lo que hace es una herramienta que corre en un ambiente controlado en términos de geografía, dispositivo y velocidad. Generalmente estas herramientas pues son muy estables en términos de que podemos correr y correr la aplicación atrás de la herramienta y nos va a devolver números siempre muy similares y es por el punto anterior, están en condiciones controladas. También es importante saber que este tipo de herramientas no considera el cache, ni el vfcache, ni frameworks como AMP, que son para la optimización de algunas páginas para que carguen aún más rápido. Y es muy importante saber que este tipo de herramientas de laboratorio son herramientas que se usan al momento de la etapa de desarrollo antes de hacer un paso de producción o al momento que se está devolviendo un problema. Y la razón es porque solo estamos probando un tipo de condiciones y todos sabemos de que no sabemos si existen, si nuestra aplicación está perfecta para todos nuestros usuarios, hasta que la aplicación realmente interactúe con ellos. A todos nos ha pasado que hemos tenido nuestro ambiente de staging, por ejemplo, de pruebas que funciona perfecta la aplicación, pero al momento de pasar a producción, un montón de cosas de dejan funcionar. Y bueno, tenemos el segundo tipo de herramienta, que es la de campo en la que se utilizan datos reales y aquí es donde viene el Chrome User Experience Report, que como les mencionaba es un database de una base de datos de información real con dispositivos reales, con condiciones reales, que básicamente la herramienta lo utiliza para poder comparar pues el el performance que tiene la aplicación versus lo lo que realmente las personas están reportando, o más bien utilizando los criterios anteriores que les mencionaba con estos datos. No solo se tiene que utilizar el Chrome User Experience Report, también nosotros podemos obtener nuestros datos utilizando APIs que tenemos disponibles. Ahora importante y quisiera explicarles un poquito más de este crux, lo que les venía hablando del Chrome User Experience Report, porque es utilizado en todas las herramientas de campo de Google, pero es importante que sepan estas cosas. La primera es información que se recolecta de manera anónima. Por ejemplo, cuando ustedes han entrado a Chrome o cuando lo instalan, siempre se les pregunta que si desean entregar información de manera anónima con tal de ayudar y esto justamente lo que hace Chrome es enviar su información a esta base de datos y es la que alimenta estas herramientas. Solo se utilizan datos de Chrome, no se utilizan datos de ningún otro navegador, de nuevo específicamente en el crux, ¿cierto? Entonces solo se recopila información de Chrome y en iOS no se recopila ninguna información. Primero en el caso de Chrome iOS no se hace porque en realidad Chrome en iOS es Safari por detrás y segundo porque en lo que se dice es que generalmente los personas que tienen dispositivos, usuarios que tienen dispositivos de iOS se encuentran en condiciones más óptimas en geografías mejores y además son teléfonos que tienen pues specs altos. Entonces pues pueden afectar un poco el estudio y esa es la razón por la que no se toma en cuenta. Y por último, bueno tampoco se toman en cuenta los navegadores basados en Chrome y por último para que el sitio de nosotros esté dentro de esta base de datos pues debe contar con una cantidad de visitas o tráfico considerable para ser tomada en cuenta. De nuevo si no se pueden, si no estamos en esa base de datos ahí es donde nosotros entramos y tenemos que recopilar la información para nosotros analizarla. Ahora, ¿cuál herramienta es más importante en sí o más valiosa? La realidad es que las dos son necesarias porque son para etapas diferentes. Una, la primera laboratorio es necesaria para el momento de desarrollo, para encontrar errores, para hacer antes de hacer un pase a producción, ¿cierto? Y la otra es para poder analizar los datos reales. Entonces en realidad los dos son necesarios, no podemos solo utilizar una. En términos de cuáles herramientas puedo utilizar para hacer los dos tipos de análisis, en el caso de la laboratorio podemos utilizar Lighthouse, podemos utilizar PageSpeed, PageSpeedInserts y los DevTools que ya los conocen. Y en caso de campo pues PageSpeed de nuevo nos entrega las dos, las dos tipos de información. Podemos utilizar el Performance API, podemos utilizar Crocs y la recolección de datos que nosotros hagamos. Ok, listo. Entonces saltemos al demo. Por acá tenemos la página de PageSpeedInserts que lo que hice fue agarrar y correr este test utilizando Web.dev. Esta página Web.dev es un sitio donde se listan las mejores prácticas y se habla toda la información que hoy les estoy compartiendo. Entonces en teoría debería ser un sitio bastante óptimo con métricas o indicadores muy buenos. Entonces pues como les comento yo ya la corrí y si empezamos a hacer análisis de lo que la información que nos lanza, pues si ven por acá dice que pasamos los corbados que es perfecto. Ahora analicemos un poquito más la información. Voy a hacerle aquí ExpandView y si ustedes ven estos primeros tres que están acá son las métricas de corbados. Aquí ustedes ven donde dice que son corbados. Entonces si nos lanzamos un poco dice que este sitio pues sí cargó en menos de dos segundos para el 83 por ciento de las visitas. El 11 por ciento pues no le funcionó tan bien y para el 7 pues el rendimiento fue peor. Ahora si ustedes recuerdan se utiliza el Presentil 75 para hacer este tipo de mediciones y saber si nuestro indicador está óptimo o no. Entonces en este caso estamos viendo que sí estamos cumpliendo el objetivo porque más del 75 por ciento de nuestros usuarios están teniendo una buena experiencia y de igual manera con los otros indicadores. Inclusive aquí habla sobre el precisio de 75. Entonces en el caso de los webpiles para esta página estamos súper bien. Si bajamos un poquito más van a ver que aquí habla que tenemos otras métricas y las que yo se las listaba. Entonces estas métricas de nuevo no es que no son importantes pero no son parte del conjunto de corbados. Sí es importante ponerles atención y en general vemos que pues tienen un buen aspecto pero hay algunos espacios de mejora. Inclusive es importante ver que aquí estas son métricas que están en experimental. Ahora esta es una herramienta de laboratorio o de campo. Bueno claramente es una herramienta de campo porque va a ser un poquito más distinto todavía. Si ustedes ven acá dicen y creo que no menciona esto pero el crumb user experience report de hecho utiliza los últimos 28 días como base de información para poder determinar estos indicadores. Entonces esto claramente aquí nos está diciendo que se corrió la herramienta en diferentes dispositivos, se corrió en diferentes networks o conexiones, se utilizaron muchos ejemplos y se corrió en todas las versiones de crumb. Entonces evidentemente aquí estos primeros resultados pues nos está hablando de resultados relacionados a experiencia de usuario completamente lo cual es bueno. Ahora interesantemente si bajamos un poco más vemos que la parte de performance pues trae un número un poco más bajo y aquí vienen de nuevo otra de estas métricas y como sabrán en realidad estas son las métricas pero utilizando o no están de información de laboratorio en sí y como lo sé bueno pues si viene acá lo que dice es que se corrió estas métricas en un Moto G4 y utilizando Lighthouse. Importante todas las herramientas de Google que analizan información de laboratorio y por detrás utilizan Lighthouse. Entonces si utilizan ésta o utilizan Lighthouse para obtener información de laboratorio debería ser similar. De nuevo la condición fue pues 4G lento solo se usa una carga y se corrió en crumb. Entonces si ustedes ven pues se puede existir una pequeña diferencia aquí de los 2.1 y por acá bueno no tenemos exacto pero asumo que sí es 2. Hay una pequeña diferencia en términos de resultados y eso está bien o mal está bien puede puede dar diferencia en resultados por lo que hemos mencionado hay datos reales de usuarios reales y están los datos de que son controlados de ambientes controlados como esto entonces está bien que haya una diferencia entonces a pesar de que vemos este 79 en amarillo realmente no es que esto no nos importe pero realmente estamos cumpliendo con los core virus que son estos tres entonces podemos decir que pues nuestro sitio es un sitio bueno y atractivo y está dando una buena experiencia a nuestros usuarios. Ahora bueno acá yo les trae las imágenes rápidamente. Les traigo este ejemplo de código rápidamente y de hecho tengo un ejemplo corriendo que solo quiero quiero enseñarles la información que muestra este paquete que es web es web dash battles que es un paquete que pesa menos de un K un KB y carga super rápido entonces acá lo que tengo es una un sitio super sencillo que lo único que tiene es una imagen un texto y el momento que yo le de refresh pues se me van a lanzar las métricas a veces es difícil capturar la el cumulative shift la esta métrica que pues mide el movimiento de los elementos porque es difícil para capturar para navegador pero bueno aquí ustedes pueden ver que estas dos métricas que está el el cp que es el largest content full paint pues aquí nos entrega alguna información inclusive nos dice cuál es ese elemento nos dice cuál es el url la imagen que se está cargando y por acá viene el elemento específico el alt todo cierto de igual manera con el resto de métricas esta información la idea es que en el momento que nosotros pues se creamos un sitio y tal vez este sitio pues no es parte del crux y pues nosotros lo que tenemos que hacer es hacer nuestra propia implementación y almacenar esta información para poder hacer el análisis entonces puedes utilizar por ejemplo google analytics para poder enviar esta información y hacer análisis de ahí el caso de google analytics es necesario porque no lo soporta por por difu entonces es necesario pues hacer una estructuración de la información para poder enviarlo pero no es nada imposible de hecho en la página de web punto de puedes encontrar pues cuál es el paso paso para poder enviar esta información ahora me devuelvo a la presentación y ahora como inicio yo a empezar a trabajar con los web virus bueno es importante y esto es una regla en general de cuando se va a trabajar en optimización es nunca empezar a optimizar si no tengo datos del estado actual de mi sitio y por qué porque puede que la supuesta optimización que está haciendo más bien esté afectando lo que es hacer es primero capturar tener información para poder después de que se hagan las mejoras poder comparar y decir ok si se hace mejoras o no a bien dañé mi sitio no quiero vertirlo por el otro lado pues es normal que pase que las métricas no estén en su mejor estado y que tenga más de una que tengas que mejorar mi consejo es mejor enfocate en una y empieza a mejorar la poco a poco hay hay situaciones en las que puede llegar a ser fácil reparar las métricas pero hay otras que puede ser complejo entonces tal vez lo mejor sea enfocarse en una y empezar a mejorar la e iterar sobre ello y luego saltar a la otra y por último pues implementar herramientas de monitoreo que nos eviten tener regresión nada nada más doloroso que hacer un cambios mejoras estar seguro que está funcionando y después hice un cambio nuevo y dañó todo entonces debemos capturar esto antes de que llegue a producción entonces lo mejor es implementar pues herramientas de de medición en la tapa en con los encontramos en el desarrollo y ahora por último y esta parte es importante porque la que les va a permitir era como es era su negocio empresa jefe de porque es importante medir el performance y pues implementar y gastar dinero en ello pues les traigo el caso de podafón que es una empresa de comunicaciones en los que realmente ellos creen en todo el tema de trabajar en un sitio sano con con buen performance con buen rendimiento y lo que hicieron fue que agarraron esta esta página que tienen al lado derecho esas dos páginas exactamente lo mismo y crearon dos versiones y lo que hicieron fue hacer ab test y entonces una versión es la versión que ellos ya tenían y la otra versión es optimiza aplicando técnicas para poder mejorar y básicamente dijeron dividieron su tráfico 50 50 y después de un tiempo pues hicieron análisis de los datos ahora qué modificaciones hicieron bueno hicieron cybercite rendering hicieron imágenes mejoras en las imágenes para que cargaras más rápido aplazaron cargas de recursos que no eran necesarios para el inicio como resultados le dio un lcp muchísimo mejor y considerable como se dio esto al final representado pues después de hacer el estudio se dieron cuenta que obtuvieron 15 por ciento más de visitas obtuvieron 11 por ciento más de visitas al carrito de compras y además se reflejó en un 8 por ciento más en ventas entonces el el poder creer y invertir en la mejora rendimiento de nuestro sitio web no solo impacta la experiencia de los usuarios sino y también impacta al negocio de una manera positiva con esto les agradezco muchísimo ha sido un placer para mí ser parte de este evento mi nuevo mi nombre es mariano alvarez le dejo mi red social mariano codes y muchísimas gracias