Cómo Medir el Rendimiento de manera Efectiva?

Y puedes obtener más información sobre el proyecto o darnos una estrella, porque somos de código abierto, revisando nuestro repositorio en GitHub. Es posible que también me conozcas por una serie muy conocida en ViewSchool, sobre la optimización de Vue.js performance. Y hoy hablaré sobre el tema, y para ser más preciso y preciso, hablaré sobre las herramientas de medición de performance. Así que hay muchas ideas equivocadas sobre el tema, porque la forma en que se mide el performance en estos días definitivamente no es fácil de entender. Sin embargo, las personas utilizan estas herramientas y, sin saber exactamente cómo funcionan, es muy fácil sacar información falsa de los resultados. Así que exploremos este tema en profundidad.

Créanme o no, hace apenas cuatro o cinco años, optimizar el performance de las aplicaciones web era algo muy exótico. Solo un pequeño grupo de desarrolladores realmente sabía cómo medirlo y solo los elegidos sabían cómo optimizarlo. Aunque ya teníamos algunas herramientas excelentes para medir el performance, la mayoría de nosotros no teníamos idea de su existencia. Y optimizar el performance generalmente significaba seguir un montón de mejores prácticas para la mayoría de nosotros, tal vez medir el evento de carga, pero eso era generalmente todo. Y solo los grandes jugadores y los gobiernos realmente se preocupaban por eso. Y creo que la razón de eso era simple, creo que era demasiado difícil para la mayoría de los desarrolladores medir eficazmente el performance. Y también, no había herramientas que proporcionaran información muy fácil de entender.

También el conocimiento sobre el impacto empresarial de un buen o mal performance, no era tan común en la industria, y no era tan común para los propietarios de negocios. Todo cambió en 2018 cuando Google introdujo Google Lighthouse. Fue la primera herramienta de medición de performance que básicamente tenía como objetivo simplificar algo que recientemente era complejo y muy, muy difícil de entender. Al mismo tiempo, se hizo evidente para todos que, ya sabes, la forma preferida de consumir la web para la mayoría de los usuarios es básicamente a través de dispositivos móviles como tabletas o teléfonos inteligentes, principalmente este último. Y esto aceleró la popularidad de un término, aplicación web progresiva, que se introdujo por primera vez, creo que en 2015. Y el objetivo de las PWAs era básicamente brindar una mejor experiencia de navegación móvil a todos los usuarios, independientemente de su conectividad de red o capacidades del dispositivo. Y una de las características clave promovidas por las PWAs era la velocidad. Por supuesto, todo esto fue seguido por una evangelización muy agresiva por parte de Google en eventos de todo el mundo, YouTube, etc. Pero esto es algo bueno porque el performance es súper importante. Y antes estábamos ciegos, ahora vemos todo.

Comencemos la charla de hoy con una inmersión profunda en Google Lighthouse. Estoy bastante seguro de que la mayoría de ustedes ha utilizado esta herramienta al menos una vez en su carrera profesional. Y no es sorprendente. Esta auditoría está disponible a través de extensiones del navegador y páginas externas. También se puede realizar directamente desde las Chrome DevTools. Simplemente haz clic en la pestaña de Auditoría, ejecuta la prueba en cualquier sitio web y voilà, te proporcionará información detallada sobre el rendimiento de tu página en relación con ciertas métricas, con el objetivo de describir la experiencia real de tus usuarios de la manera más precisa posible.

Entonces, Livehouse básicamente reduce el rendimiento de un sitio web a un número único, entre uno y cien. También se puede tratar como un porcentaje, donde una puntuación por debajo de 50 se considera mala y una puntuación por encima de 90 se considera buena. Volveré a este tema, porque podría resultar sorprendente que solo el 10% se considere bueno. Pero, volviendo al tema. ¿De dónde provienen estos números mágicos? Resulta que cada métrica tiene su propio peso que corresponde a su impacto en la experiencia general del usuario final. Como puedes ver aquí, si mejoramos el tiempo total de bloqueo, la pintura del contenido más grande o el desplazamiento de diseño acumulativo, mejoraremos nuestra puntuación en Livehouse mucho más rápido que optimizando otras métricas. Por supuesto, es importante centrarse en todas ellas, ya que cada una describe una pieza diferente que contribuye a la experiencia general de tus usuarios, pero hay algunas métricas que Google ha identificado como más importantes que otras, en el sentido de que su impacto en la experiencia del usuario, la experiencia percibida por el usuario, es mayor. Por supuesto, todo es subjetivo, pero esto es lo que dicen los datos, así que tenemos que creerlo.

De acuerdo, ahora sabemos cómo se calcula la puntuación de Google Livehouse en general, pero lo que no sabemos es básicamente cómo se calcula la puntuación de las métricas individuales. ¿Qué quiero decir con esto? Digamos que tenemos el tiempo total de bloqueo. ¿Cómo sabemos si un segundo es un resultado bueno o malo? ¿De dónde lo sabemos? Y Google utiliza datos del mundo real recopilados por HTTP Archive. Y si no sabes qué es HTTP Archive, te animo realmente a que lo revises, porque es simplemente impresionante. Contiene mucha información útil sobre la web en general y cómo se utiliza tanto por usuarios reales como por problemas. Y puede ayudarte a comprender qué es importante y cómo se desempeña tu sitio web en comparación con otros en tu campo o en diferentes campos. Y te advierto, parte de la información que encontrarás allí puede ser realmente, realmente deprimente o al menos sorprendente. Por ejemplo, mi ejemplo favorito, en realidad, puedes descubrir que en 2021, la cantidad promedio de datos comprimidos, repito, datos comprimidos de JavaScript enviados por un sitio web estadístico, es casi de 450 kilobytes en dispositivos móviles. 450 kilobytes de datos comprimidos en un dispositivo móvil. Eso son varios megabytes de JavaScript sin comprimir. Para dispositivos de gama media o baja, si obtienes una experiencia realmente, realmente mala y un tiempo de carga, ¡puf!, podrías hacer un café, volver y aún esperar hasta que tu sitio web esté listo. De verdad, hay muchos ejemplos donde puedes ver que alguna página se carga en 13, 14 o incluso 15 segundos en un dispositivo móvil. ¿Esperarías tanto tiempo? No creo. Bueno, volviendo al tema principal. Basándose en los datos de cada métrica de HTTP Archive, Google establece el rango para una puntuación buena, media o mala.

Y tu puntuación en Lighthouse para cada métrica individual se determina por tu posición en el gráfico. Si estás en la parte superior, obtienes el 100%, si estás en la parte inferior, obtienes el 0. Simple.

Hay una cosa importante que todos los que usan Lighthouse deben tener en cuenta. Tanto las métricas como sus pesos cambian con el tiempo. No son persistentes. ¿Por qué? Bueno, obviamente, con el tiempo Google aprende cosas nuevas. Aprenden cosas nuevas sobre el impacto de ciertas métricas y comportamientos en la experiencia del usuario y actualizan periódicamente el algoritmo de puntuación de Lighthouse para que sea más preciso. Y con cada versión, la puntuación es más precisa, mide y describe el impacto del mundo real de diferentes métricas en la experiencia del usuario. Y realmente no es fácil encontrar buenas métricas y pesos porque podemos medir el rendimiento desde muchas perspectivas diferentes y descubrir cómo cada una de ellas influye en la experiencia general es muy difícil. Por eso tenemos Lighthouse 7 y probablemente también tendremos Lighthouse 17. Aquí tienes un ejemplo de los cambios entre Lighthouse 5 y Lighthouse 6. Como puedes ver, no solo cambian los pesos de la caché, sino que también se reemplazan dos métricas de Lighthouse 5 en Lighthouse 6. Desde Lighthouse 7, parece que ya hemos establecido un buen conjunto de métricas para medir el rendimiento general, pero los pesos aún se están ajustando. Es importante tener en cuenta que la puntuación está cambiando porque, por ejemplo, si evalúas tu sitio web hoy y guardas tu puntuación de rendimiento, digamos que fue 60, y luego lo evalúas dentro de un año y será 70. ¿Significa que fue mejor? ¿Significa que fue peor? No significa nada porque el algoritmo podría haber cambiado durante ese tiempo. Podría haber mejorado o empeorado porque el algoritmo ha cambiado, no porque hayas mejorado algo o hayas fallado en algo más. Por eso este tipo de comparación solo tiene sentido cuando se comparan las métricas individuales. Realmente te animo a hacer eso, a guardar eso. También te contaré un poco sobre la herramienta que automatiza eso. Nunca, nunca compares la puntuación real porque es muy engañosa y con el tiempo también nos daremos cuenta de que de todas estas métricas que conocemos, hay tres que son una especie de conjunto mínimo de medidas que son vitales para el rendimiento del sitio web. Y las llaman Core Web Vitals, que es un nombre bastante preciso. Y Google las describe como señales de calidad, y creo que esa es la descripción perfecta en realidad, porque no hay métricas que te digan si el sitio web ofrece una experiencia buena o mala. Esto no es algo que puedas, ya sabes, simplemente medir. Y nunca debemos seguirlos ciegamente, esto es solo una señal.

Y cada métrica y herramienta de prueba siempre te proporciona solo una señal sobre la calidad de un sitio web, nada más. Volviendo a esto, tenemos tres Core Web Vitals. El primero se llama Largest Contentful Paint, que básicamente mide cuánto tiempo tarda el sitio web en mostrar el contenido más grande en la pantalla por encima del valor predeterminado. Puede ser una imagen, un enlace o un campo de texto, realmente no importa. Esta métrica describe el rendimiento de carga porque te dice cuánto tiempo necesita esperar hasta que aparezca la parte más grande de la interfaz de usuario. Si esta definición no te dice nada, veámoslo en el ejemplo. En la primera imagen vemos que LCP es la imagen en el medio, y aparece en el quinto fotograma. Suponiendo que cada fotograma es de un segundo, nuestro LCP es de cinco segundos. ¿Entendido? En la imagen de abajo, vemos que esto es básicamente esta imagen de Instagram, y nuestro LCP es después de tres segundos. Un buen LCP está por debajo de dos segundos y medio, y malo está por encima de cuatro segundos. Por lo tanto, podemos concluir rápidamente que no hubo un buen LCP en los ejemplos anteriores.

Otra métrica que mide la capacidad de respuesta del sitio web, además de la carga y la falta de capacidad de respuesta, es el First Input Delay. En pocas palabras, es el tiempo que el usuario necesita esperar hasta que vea la primera respuesta de su acción. Estoy seguro de que lo has visto muchas veces. Ingresas al sitio web, haces clic en el enlace que aparece en la ventana visible, pero el sitio web aún se está cargando, por lo que tienes que esperar un poco hasta que la navegación a otra página realmente ocurra, o se abra una ventana de modelo, o suceda alguna otra cosa . Esto es exactamente el First Input Delay.

Esto ocurre solo si tienes tareas largas que ocupan el hilo principal durante más de 100 milisegundos. Si no sabes qué es el hilo principal, comienza leyendo sobre cómo funcionan los bucles de eventos. Es realmente útil. Bueno, volviendo. Entonces, si el usuario hace clic en algo, debe esperar a que esa tarea termine y luego la acción ocurre. Un buen valor de First Input Delay está por debajo de 100 milisegundos. Esto se debe a que, según los estudios realizados, 100 milisegundos es en realidad un umbral para una respuesta instantánea percibida. Por lo tanto, después de 100 milisegundos, el usuario notará que la acción se retrasó y todo por debajo de 100 milisegundos se considera instantáneo. Es información muy útil.

Y por último, pero no menos importante, el cumulative layout shift mide la estabilidad visual. Básicamente te dice si hay cambios en el diseño durante el proceso. Por ejemplo, si la imagen se ha movido o el texto se ha movido. Y el CLS generalmente ocurre cuando no tienes marcadores de posición para la parte de la interfaz de usuario que se carga dinámicamente, como imágenes en la pila de imágenes, por ejemplo. Y aquí vemos un ejemplo del cambio de diseño. Entonces, el botón Haz clic en mí ha aparecido y debido a eso tuvimos que desplazar toda la caja verde. El buen puntaje para CLS es cuando menos del 10% de tu diseño cambia durante el proceso de carga y el malo es cuando más del 25% cambia. E intuitivamente, creo que es correcto. Por lo tanto, los Core Web Vitals son un conjunto mínimo de señales de calidad para un buen rendimiento percibido, midiendo la cargaperformance, la interactividad de la página y la estabilidad visual.

Y creo que ya es un gran paso adelante desde Lighthouse 1, donde en realidad cada página tenía una puntuación de 100 y había muchas métricas extrañas, y teníamos una comprensión muy ingenua de lo que más importa en una buena user experience. Pero, sabes, todavía hay margen de mejora, y también quiero que estés consciente de eso. Por ejemplo, la auditoría de Lighthouse no mostrará ninguna diferencia entre una aplicación de una sola página y una aplicación de varias páginas, aunque la primera tiene una navegación en la aplicación mucho más rápida. Entonces, aunque ambas tendrán la misma puntuación, la experiencia percibida de tus usuarios siempre será mejor en la aplicación de una sola página, porque la navegación en la aplicación es mucho más rápida. Además, la puntuación de Lighthouse no te dirá nada sobre qué tan bien o qué tan mal funciona tu sitio web bajo cargas pesadas, o qué tan bien se está almacenando en caché del cliente, es decir, qué tan bien se están gestionando las visitas posteriores. Solo te dirá si se almacenó en caché o no. Pero, sabes, eso es todo lo que tenemos en este momento, y creo que definitivamente es mejor que nada, y es bastante preciso, no me malinterpretes.

Solo hay un problema. Si ejecutas una auditoría de Lighthouse localmente en diferentes dispositivos, casi siempre obtendrás diferentes puntuaciones porque está influenciado por muchos factores, como la potencia de tu computadora, tu conectividad de red, tus extensiones de navegador. Por supuesto, puedes aplicar trucos, navegar en modo incógnito, pero no eliminará el problema por completo. Si deseas medir continuamente el rendimiento para cada lanzamiento o con cada solicitud de extracción, te sugiero encarecidamente que alojes el entorno de Lighthouse localmente y utilices herramientas como Lighthouse CI, que está disponible como una acción de GitHub. Es una gran herramienta y ejecutará automáticamente una auditoría de Lighthouse en cada solicitud de extracción con solo unas pocas líneas de código.

Si ejecutas Lighthouse CI, te proporcionará una vista detallada de la puntuación. Por ejemplo, cómo ha cambiado con el tiempo desde la versión anterior, cómo han cambiado las métricas. Verás de inmediato si una determinada versión de la solicitud de extracción contribuye a un mejor o peor rendimiento. Eso es lo más importante. Esta es la razón principal por la que vale la pena introducir Lighthouse CI en tus flujos de trabajo.

Vale, pero la solución no es perfecta, porque el hecho de que tu sitio web funcione muy bien en tu entorno controlado solo significa que funciona muy bien en tu entorno controlado. Porque si estás probando en iPhones o MacBooks de alta gama, generalmente puedes esperar buenos resultados. Pero no todos tus usuarios tendrán dispositivos de alta gama y buen acceso a Internet. Entonces, básicamente, hay dos tipos de datos. Uno se llama LabData, y esto es lo que te proporciona Lighthouse, y de lo que hemos estado discutiendo hasta ahora. Básicamente son los datos que siempre provienen de un entorno controlado, como tu computadora. Pero también hay otro tipo de datos llamado FieldData que, como su nombre indica, proviene del mundo real. También lo sugiere la imagen. Y es proporcionado por usuarios del mundo real. Y en realidad necesitas ambos. Entonces, LabData es principalmente útil para la depuración, y como vimos anteriormente, podemos ver allí resultados y mejoras o regresiones en ciertas métricas después de cada lanzamiento o después de cada solicitud de extracción. Y también podemos reproducir esos resultados muy fácilmente. El problema es que no nos proporciona información real sobre los cuellos de botella del mundo real de nuestro sitio web. Y aquí es donde brilla FieldData.

Para ilustrar también por qué necesitamos tanto LabData como FieldData, quiero mostrarte dos ejemplos del mundo real. Entonces, aunque la puntuación de Latke aquí arriba es terrible, alrededor del 80-90% de los usuarios experimenta un gran rendimiento. Entonces, las barras que vemos en el medio, eso es FieldData. Otro ejemplo, un caso opuesto real. Entonces, aunque tenemos una puntuación de Lighthouse bastante decente arriba, 73 para un sitio web de comercio electrónico es muy decente, la mayoría de los usuarios experimentan un mal rendimiento para un sitio web médico. Entonces, esto realmente es solo un indicador, y LabData no es suficiente información para determinar si nuestro sitio web está funcionando bien o mal. Entonces, ¿dónde podemos encontrar los FieldData entonces? Google lanzó algo llamado Chrome User Experience Report, y eso es exactamente lo que sugiere el nombre. Así que debemos admitir que son buenos para nombrar, como Hurley Pytel's, Chrome User Experience Report, todas esas cosas. Es un informe de la experiencia del usuario real entre los usuarios de Chrome, y Google recopila cuatro métricas de rendimiento cada vez que visita un sitio web y las envía a la base de datos de CrUX. Por cierto, puedes desactivarlo en Chrome si quieres, pero de forma predeterminada, está activado. Y para que estos datos estén disponibles para tu página o sitio web, debe ser rastreable, así que tenlo en cuenta.

Y estos datos del Informe de Experiencia del Usuario de Chrome están disponibles en PageSpeed Insights, Google BigQuery, y el Panel de Experiencia del Usuario de Chrome en Data Studio. Y no hablaré sobre este último, pero simplemente te animo, te animo mucho a que lo revises, porque el Panel de Experiencia del Usuario de Chrome en Data Studio es increíble. Te permite crear informes muy detallados y puedes especificar qué métricas te gustaría ver, cómo han cambiado con el tiempo, qué dispositivos para qué tipos de usuarios. Es súper, súper útil.

Y hoy hablaremos sobre el primero, que es PageSpeed Insights. Entonces, PageSpeed Insights. PageSpeed Insights es una herramienta de medición de rendimiento que ejecuta la Auditoría de Rendimiento de Lighthouse en tu sitio web, pero también muestra los datos de campo recopilados del Informe de Experiencia del Usuario de Chrome. Entonces, PageSpeed Insights combina de alguna manera las dos formas de obtener los datos que hemos visto. Utiliza tanto Lighthouse como el Informe de Experiencia del Usuario de Chrome. Esencialmente, es una auditoría que nos brinda toda la información que necesitaríamos.

Y los datos de laboratorio son los que se utilizan para calcular la puntuación de Lighthouse. Por eso no deberías centrarte tanto en mejorar esta parte. Es solo un indicador. Pero podrías preguntar, ¿cuál es la diferencia entre los datos de laboratorio de PageSpeed Insights y los datos de laboratorio que obtengo al ejecutar la puntuación de Lighthouse en mi propio dispositivo? ¿Verdad? Los datos de la Auditoría de Lighthouse de PageSpeed Insights provienen del centro de datos de Google. Básicamente, están ejecutando la prueba, la auditoría, en uno de los centros de datos de Google en lugar de una computadora. Y el sitio web generalmente utiliza el centro de datos más cercano a tu ubicación. Pero a veces, en mi experiencia, muchas más veces de lo habitual, podrías usar otro si el más cercano está bajo una carga pesada. Y por eso, a veces puedo obtener resultados completamente diferentes en la misma página si ejecutas la prueba una tras otra. Realmente podrían ser completamente diferentes. Y esa es otra razón para no poner demasiado énfasis en los datos de laboratorio. Tratémoslo como un indicador. Además, para dar un poco más de detalle, todas las pruebas se ejecutan en este centro de datos, pero también en el emulador Motorola Moto G4, que es un dispositivo móvil típico de gama media. Entonces, siempre y cuando tus usuarios no estén utilizando esto, esta puntuación no será una simulación realista. Lo que realmente importa son los datos de campo y se recopilan de los últimos 28 días en este ejemplo en particular. Pero quiero decir, en cada auditoría de PageSpeed Insights, se recopilan de 28 días. Entonces, si hiciste una actualización, deberás esperar todo un mes para ver si hubo una mejora o no. Y los datos de laboratorio muestran qué tan bien funciona tu sitio web en relación con los vitales coloreados y la primera entrada, la primera pintura de concentración. El porcentaje de cada color muestra cuántos usuarios experimentan resultados buenos, medianos o malos. Por ejemplo, si vemos una barra verde completa. Eso significa que todos los usuarios experimentan buenos resultados.

Escenario perfecto. Entonces, para resumir, al utilizar PageSpeed Insights, siempre debes mirar los data de campo cuando busques información significativa del mundo real. Y puedes utilizar los datos de laboratorio para verificar si hubo una mejora inmediatamente después de realizar los cambios. Pero la parte más importante aquí son los datos de laboratorio, punto.

Ahora algo que todos hemos estado esperando y algo con lo que mucha gente lucha. También yo, tuve muchos problemas para encontrar la información correcta porque estaba cambiando con el tiempo. Entonces, ¿cuál es el impacto de los Core Web Vitals y básicamente del rendimiento en el SEO? Es algo nuevo que se introdujo este año y la respuesta corta es sí. El rendimiento afecta al SEO, pero en este momento solo influye en los resultados de búsqueda móviles y solo tiene en cuenta los datos recopilados de dispositivos móviles. Por lo tanto, el tema móvil es algo en lo que deberías fijarte, me refiero a los datos de campo móviles. Es muy probable que también sea relevante para los dispositivos de escritorio en algún momento, pero aún no lo es. Además, solo importan los datos de campo, por lo que eso es lo que debes optimizar, los datos de laboratorio no tienen ninguna influencia en el SEO. Entonces, si quieres obtener un impulso en el SEO, verifica tus datos de campo en PageSpeed Insights y optimízalos.

Veamos un ejemplo del mundo real y cómo funciona en Dev. Google analiza cada una de las cuatro métricas recopiladas por separado y si el percentil 75 de una métrica determinada es bueno, obtendrás un impulso en el SEO de esa métrica en particular. Si no es así, no obtendrás un impulso en el SEO. Solo eso. Eso es todo. Entonces, en este ejemplo, obtendremos un impulso en el SEO del Retraso de la Primera Entrada, LCP y CLS, y no lo obtendremos de FCP. Eso es todo. Y eso es todo lo que tengo para ustedes hoy. Espero que esta charla les haya ayudado a comprender mejor este salvaje mundo de las herramientas de medición del rendimiento y realmente les animo a profundizar un poco más por su cuenta, porque es un tema súper fascinante. Disfruten el resto del evento. Muchas gracias por recibirme y ¡salud!