Probablemente estás utilizando Lighthouse de forma incorrecta: Cómo nos engañó un único número mágico

Rate this content
Bookmark

En la actualidad, el rendimiento web es una de las cosas más importantes que todos quieren optimizar en sus aplicaciones, y está claro para todos cómo impacta dramáticamente un sitio web mal optimizado en los negocios. Sin embargo, como industria, fallamos completamente en reconocer su complejidad y mal utilizamos la herramienta más común para medirlo: Google Lighthouse. Si eres una de esas personas que piensa que un buen rendimiento equivale a una buena puntuación en Lighthouse, también has caído en esta trampa y esta charla es para ti.

29 min
12 May, 2023

Video Summary and Transcription

La charla aborda la importancia del rendimiento y el consumo móvil en el comercio electrónico, así como el uso y las limitaciones de Google Lighthouse para medir la calidad de las páginas. Destaca los desafíos y consideraciones al utilizar Lighthouse, incluida la diferencia entre los datos de laboratorio y los datos del mundo real, y la necesidad de comprender la experiencia del usuario más allá de una sola puntuación. La charla también menciona el posible uso de la inteligencia artificial para evaluar el rendimiento del sitio web, optimizar bibliotecas de terceros y establecer un presupuesto de JavaScript para mejorar el rendimiento.

Available in English

1. Introducción a la Charla

Short description:

Hola. Oye, oye, ¿cómo estás? ¿Te estás divirtiendo? Estoy feliz porque me estoy divirtiendo mucho. Es genial estar aquí de nuevo. El título de mi charla es, Probablemente estás usando Cloud House de forma incorrecta. Mi nombre es Filip Rakovski. Soy el jefe de experiencia de desarrollo y cofundador de Vue. También soy miembro del consejo tecnológico de Maha Alliance. Maha Alliance es una alianza de los mayores proveedores empresariales que están modernizando el panorama del comercio electrónico y estoy extremadamente orgulloso de representarlo. Trabajo en la industria del comercio electrónico. Construir una tienda en línea es más difícil de lo que parece. Y puedo garantizar que sentirás dolor físico una vez que aprendas qué es el faceting.

Oye, oye, ¿cómo estás? ¿Te estás divirtiendo? ¿Te estás divirtiendo? De acuerdo. Bien, bien. Estoy feliz porque me estoy divirtiendo mucho.

Es genial estar aquí de nuevo. Creo que es la primera vez que estoy aquí en Vue London, en Vue.js Live, esta vez. Y el título de mi charla es, Probablemente estás usando Cloud House de forma incorrecta. Y sé que suena un poco provocador. Esa era mi intención. Pero no asumo que lo estás usando de forma incorrecta. Realmente espero que lo estés usando de la manera correcta. Pero por si acaso lo estás usando de forma incorrecta, aquí está mi charla.

Mi nombre es Filip Rakovski. Soy el jefe de experiencia de desarrollo y cofundador de Vue. Me presentaron como CTO porque solía ser CTO, pero contratamos a un mejor CTO. Así que ahora puedo dedicarme a las cosas en las que soy mejor y que disfruto un poco más. Así que, sí. También soy miembro del consejo tecnológico de Maha Alliance. ¿Quién aquí ha oído hablar de Maha Alliance? De acuerdo. De acuerdo. Entonces, Maha Alliance es una alianza de los mayores proveedores empresariales que están modernizando el panorama del e-commerce y estoy extremadamente orgulloso de representarlo. ¿Quién ha oído hablar de Vue Storefront? Por favor, levanten la mano. Bien. Bien. Mejora cada año.

Así que, ya sabes, trabajo en la industria del e-commerce. Y trabajo en la industria del e-commerce literalmente toda mi vida. Y construir una tienda en línea es más difícil de lo que parece. Como si fueras poderoso después de mostrar, ya sabes, el primer producto, los primeros data en tu sitio web desde un punto de API, pero el camino desde ahí hasta la producción es muy largo y a menudo doloroso. Y puedo garantizar que sentirás dolor físico una vez que aprendas qué es el faceting.

2. Importancia del Rendimiento y Consumo Móvil

Short description:

El objetivo de Vue Storefront es proporcionar herramientas que te ahorren el dolor de construir tiendas en línea. El rendimiento es crucial en la industria del comercio electrónico, y incluso pequeños retrasos pueden costar millones de dólares. Consulta las estadísticas de WPO para obtener información sobre cómo la optimización del rendimiento puede aumentar los ingresos. Hace cinco años, el rendimiento del frontend no era una preocupación importante, pero con el surgimiento de los frameworks de JavaScript, la importancia del rendimiento se hizo evidente. El crecimiento del tamaño de los sitios web y el cambio al consumo móvil resaltaron la necesidad de un mejor rendimiento móvil.

Entonces, el objetivo de Vue Storefront es proporcionar herramientas que te ahorren este dolor.
Y Vue Storefront es de código abierto, así que puedes consultarlo en GitHub y darle una estrella si te gusta. No lo estoy fomentando, pero, ya sabes, sería agradable.

Y en la industria del comercio electrónico, el rendimiento es una de las cosas más importantes a tener en cuenta realmente. El hecho de que la forma en que las personas lo ven a menudo sea completamente incorrecta es otro tema, pero eso es lo que voy a abordar en esta charla. Entonces, Amazon realizó un estudio sobre ese tema. Y lo que aprendieron es que cada 100 milisegundos de carga de página adicional cuesta un 1% de los ingresos. Para Amazon, son millones de dólares, en serio. 100 milisegundos.

Y hablando de números, si necesitas una buena fuente de argumentos para convencer a tu jefe, por ejemplo, de que se preocupe por el rendimiento porque sabes que es importante pero necesitas el argumento, echa un vistazo a este sitio web, WPO stats, que significa estadísticas de optimización del rendimiento. Y te dará grandes, grandes ideas sobre cómo optimizar el rendimiento ayuda a otras empresas a aumentar sus ingresos.

Y parece bastante loco desde la perspectiva actual, pero hace cinco años, cuando estábamos escribiendo las primeras líneas de código para Vue Storefront, el tema del rendimiento del frontend era casi inexistente en el espacio de los desarrolladores web. En ese momento, los frameworks de JavaScript estaban empezando a ganar tracción. Angular, JS, React. Ya eran herramientas bien establecidas, ganando popularidad cada día. Vue, recién estaba llamando la atención de la comunidad de desarrolladores en general, luchando con frameworks como este.

¿Conoces esos frameworks? Levanta la mano si conoces todos los frameworks, todos los logotipos de esta imagen. ¿Oh, de verdad? Podría haber sido Vue, pero por suerte, Vue llegó al tercer lugar. Casi nadie se preocupaba por lo rápido que se construía el sitio web con esos frameworks. Y, por supuesto, ahora todos dicen que, ya sabes, poner tanto JavaScript en el frontend fue una idea terrible. Pero honestamente, no estaba tan claro en ese momento. No estaba tan claro porque la razón por la que tenemos problemas de rendimiento con las aplicaciones de una sola página en estos días es por el ecosistema y la cantidad de JavaScript que estás agregando a través del ecosistema, no los frameworks en sí.

Y, ya sabes, mientras sigamos usando PC o portátiles como nuestras máquinas principales, lo cual, créeme, hace siete años era algo normal para consumir la web, nadie parecía preocuparse por el crecimiento del tamaño de los sitios web. Tanto la CPU como el ancho de banda de Internet estaban creciendo rápidamente y los sitios web estaban creciendo en tamaño. Todo cambió cuando los teléfonos móviles comenzaron a convertirse en la forma preferida de consumir la web. Según la investigación de Google en 2017, en promedio, se tardaba 15 segundos en cargar completamente una página web en un teléfono móvil. Imagina 15 segundos. Si no tuviera solo 20 minutos, esperaría para darte, ya sabes, esta percepción. En ese momento, comenzó a surgir la conciencia sobre el impacto de este pobre rendimiento móvil en los negocios. Pero todavía nos falta una forma fácil de vincular realmente esos dos componentes.

3. Understanding Google Lighthouse Metrics

Short description:

Métricas de rendimiento y de negocio. Google Lighthouse, introducido en 2018, ganó rápidamente popularidad junto con las aplicaciones web progresivas. Sin embargo, la comprensión de estos conceptos se limitaba al marketing de Google. La simplicidad de Lighthouse, representada por un solo número, es tanto su fortaleza como su debilidad. El rendimiento web y la experiencia del usuario no se pueden reducir a un solo número. Hay muchos matices en torno a Lighthouse, y esta charla tiene como objetivo explorarlos. Lighthouse mide la calidad de la página en términos de rendimiento, accesibilidad, mejores prácticas y SEO. Si bien proporciona información valiosa, no puede determinar definitivamente la experiencia del usuario. Eso lo determinan en última instancia tus usuarios.

Rendimiento y métricas de negocio. Y todo cambió cuando Google Lighthouse comenzó a ganar popularidad. Recuerdo cuando se introdujo por primera vez en 2018. Se volvió súper popular, adoptado rápidamente. De la misma manera que las aplicaciones web progresivas y en ese momento, todos comenzaron a obsesionarse con el rendimiento. Todos comenzaron a obsesionarse con las aplicaciones web progresivas. Pero ¿sabes qué? Realmente no sabían mucho sobre eso. Todo era marketing de Google. Y desafortunadamente, no ha cambiado mucho desde entonces. Entonces, ¿qué hace que Lighthouse sea tan ampliamente adoptado? Creo que es su simplicidad. Ejecutas una prueba, obtienes un número entre 100 y 1. Eso te dice qué tan bueno o qué tan malo es el rendimiento de tu sitio web. Todos, incluso aquellos sin ningún conocimiento técnico, pueden entender eso. Y honestamente, ahí radica el problema. Porque la realidad no es tan simple. En el rendimiento web o la experiencia del usuario, no se puede representar con un solo número en la pantalla. Además, hay muchos matices en torno a Lighthouse. Entonces, cómo funciona, de dónde vienen los números, etcétera, etcétera. Y navegaremos a través de todos estos matices y al final de esta charla espero que sientas que sabes cómo funciona Lighthouse, de dónde vienen estos números, cuándo confiar en él y cuándo no confiar en él. Pero empecemos con una pregunta sencilla. ¿Qué mide realmente Google Lighthouse? ¿Alguien puede decírmelo? ¿Qué mide Google Lighthouse?

De acuerdo. Tengo la sensación de que mucha gente no intenta responder esta pregunta. Asumen que el número tiene que ser alto para ser correcto y cuando es bajo, es malo y ya está. Eso es todo lo que necesitan saber. Y como podemos leer en el sitio web de Google Lighthouse, el objetivo de Lighthouse es medir la calidad de la página. Por lo tanto, la auditoría divide la calidad en cuatro métricas diferentes. Rendimiento, accesibilidad, mejores prácticas y SEO. Todas estas métricas combinadas deberían darte una perspectiva muy buena sobre la calidad del sitio web y, por ende, tratar de predecir con precisión la experiencia del usuario en este sitio web. Y tratar de predecir es muy importante aquí porque ninguna auditoría te dará información y respuestas definitivas sobre si tu experiencia del usuario es buena o mala. ¿Adivina qué? Tus usuarios lo harán.

4. Understanding Google Lighthouse Score Calculation

Short description:

Google siempre ha promovido el rendimiento como el factor más importante, pero hay muchos otros factores que influyen en la experiencia del usuario. El ejemplo del IMC ilustra cómo depender de una sola métrica puede llevar a conclusiones incorrectas. El puntaje de Google Lighthouse se calcula a partir de varias métricas, cada una con su propio peso. Es importante optimizar las métricas de alto peso, pero el algoritmo cambia con cada versión, por lo que comparar puntajes de diferentes versiones no es preciso.

Entonces, Google siempre ha promovido este núcleo de performance como el más importante. Y creo que en la mente del público en general y de todos nosotros, realmente, ese núcleo es igual al núcleo de performance. Entonces, una página de calidad significa una página con un alto núcleo de performance. Y no me malinterpreten aquí, el performance definitivamente es un factor importante que influye en la experiencia del usuario, pero la verdad es que incluso las cuatro métricas de Google Lighthouse no te dirán si es bueno o malo. En realidad, hay tantos factores que influyen en una buena experiencia del usuario que es imposible determinarlo solo usando cualquier herramienta.

Entonces, sin conocer el contexto, es muy fácil tomar decisiones equivocadas. Pero lógicamente, podría parecer correcto. Permítanme darles un ejemplo. IMC. ¿Quién conoce el IMC? ¿Saben qué significa? Índice de masa corporal. Y creo que el índice de masa corporal es exactamente como Google Lighthouse, y les diré por qué. ¿Significa que si tienes un IMC de 30 eres obeso? Si miras la tabla, puedes decir que sí, con total confianza, ¿verdad? Pero cuando profundizas un poco en los detalles de cómo se deben interpretar los resultados, aprendemos que esta escala no funciona para una gran cantidad de personas. Los adultos mayores, las mujeres, las personas musculosas, la interpretación para ellos es diferente. Pero la lista no termina aquí. La interpretación para los niños y adolescentes también es diferente. Así que en realidad, el único grupo que me viene a la mente que encaja en el IMC son, no sé, hombres de mediana edad no musculosos. Eso es todo. Entonces, los resultados iniciales podrían llevarte a tomar decisiones equivocadas. Y si no profundizas en esos detalles específicos, simplemente tomarás malas decisiones. Este tipo de pensamiento podría llevarnos a verdaderos desastres. Por ejemplo, aquí en el gráfico, puedes ver que podríamos llegar rápidamente a la conclusión de que podríamos poner fin a cosas realmente horribles simplemente prohibiendo el consumo mundial de queso.

Permítanme explicar rápidamente cómo se calcula el puntaje de Google Lighthouse para asegurarnos de que todos estemos en la misma página. El puntaje de Lighthouse se calcula a partir de varias métricas. Cada una de ellas tiene su propio peso. Algunas son más importantes, otras menos importantes, y es importante saberlo porque cuando quieres optimizar el puntaje, debes comenzar optimizando las cosas que tienen mayor peso, pero no porque te darán los mejores resultados, sino simplemente porque son las más importantes. Y el algoritmo cambia con cada versión. Es algo muy importante de tener en cuenta porque si estás optimizando un sitio web o si estás haciendo, no sé, una migración o algo así, nunca compares el puntaje anterior de Lighthouse con el nuevo puntaje de Lighthouse. Eso no es lo correcto para comparar porque lo más probable es que el algoritmo de puntuación haya cambiado durante ese tiempo. Y saben, el puntaje podría disminuir, aumentar principalmente porque el algoritmo ha cambiado, no porque hayas cambiado algo. De acuerdo.

5. Understanding Lighthouse Score Calculation

Short description:

Sabemos cómo se calcula el puntaje de Lighthouse, pero el entorno en el que se ejecuta la prueba es extremadamente importante. El uso de herramientas de desarrollo en el hogar es la forma menos confiable de medir el rendimiento, ya que factores externos como la red, la CPU y las extensiones pueden influir en el puntaje. Ejecutar Lighthouse en modo cognitivo y utilizar una limitación adecuada puede mitigar su impacto, pero los resultados aún variarán en diferentes dispositivos. Implementar Lighthouse CI o utilizar PageSpeed Insights, un sitio web de Google, puede proporcionar resultados más consistentes. PageSpeed Insights realiza auditorías rápidas de Lighthouse de forma remota en los centros de datos de Google, generalmente utilizando el más cercano a su ubicación. Tenga en cuenta que los sitios web con múltiples API pueden tener resultados ligeramente diferentes.

Entonces, ya sabemos cómo se calcula este puntaje. Esto es como el 50% de la verdad. Pero lo que aún no sabemos es de dónde exactamente proviene este número. Sabemos cómo se calcula. No conocemos el entorno. Y el entorno en el que ejecutas la prueba es extremadamente, extremadamente importante.

La mayoría de las personas utilizan herramientas de desarrollo en el hogar para medir el performance, para ejecutar las auditorías de Lighthouse, y les diré esto. Esta es la forma menos confiable de hacerlo. Entonces, levanten la mano si lo están haciendo. Por favor, no lo hagan. Porque hay múltiples factores externos que realmente están influyendo en su puntaje. Uno de ellos es su red. Otro es su CPU. Otro son las extensiones. Sí, si tienes alguna extensión, también se incluye en esta auditoría de Lighthouse. Por ejemplo, si tienes Grammarly, puedes echar un vistazo, está agregando algo en la parte inferior de tu página. Podemos disminuir el impacto de estos ejecutándolo en modo cognitivo, aplicando una limitación adecuada, etc. Pero esto seguirá siendo diferente en diferentes dispositivos.

Entonces, digamos que tenemos 20 personas en la empresa, todos ejecutarían la auditoría de Lighthouse, los resultados serían completamente diferentes. Y tienes mucho más, puedes obtener resultados mucho más consistentes si implementas algo como Lighthouse CI, que se ejecuta en cada solicitud de extracción. O utiliza PageSpeed Insights. ¿Qué es PageSpeed Insights, quién ha escuchado? Bien, bien. Bien. Porque esa sería mi recomendación. Este es un sitio web creado por Google mismo y puedes usarlo para realizar auditorías rápidas de Lighthouse en un sitio web de forma remota en uno de los centros de datos de Google. PageSpeed Insights generalmente utiliza el centro de datos que está más cerca de tu ubicación. A veces puedes usar uno diferente. Por ejemplo, si el que quieres usar está bajo una carga pesada. Entonces podrías tener resultados ligeramente diferentes entre ejecuciones. Además, ten en cuenta que cuando tienes un sitio web, en este sitio web probablemente tengas múltiples API.

6. Challenges with Lighthouse Usage

Short description:

Centrarse en el puntaje de Lighthouse no es el objetivo porque siempre será diferente. El puntaje de PageSpeed Insights no representa adecuadamente cómo los usuarios experimentan su sitio web. Las Core Web Vitals son importantes para el SEO. Lighthouse es solo un algoritmo y se puede engañar. Engañar los puntajes de Lighthouse no tiene sentido y es engañoso. Lighthouse es una herramienta maravillosa, pero se puede utilizar de manera incorrecta.

También pueden haber inconsistencias. Así que realmente, centrarse en el puntaje de Lighthouse no es el objetivo porque siempre será diferente. Siempre habrá algunas diferencias entre las ejecuciones y esas diferencias provienen de las dependencias, por ejemplo.

Aunque el puntaje de PageSpeed Insights será más consistente, aún está lejos de ser una buena representación de cómo los usuarios realmente están experimentando su sitio web. Porque este puntaje se ejecuta en el presupuesto emulado de Motorola. Entonces, a menos que todos sus usuarios estén utilizando un Motorola de presupuesto, no es una muy buena representación de cómo están experimentando realmente su sitio web.

La buena noticia es que PageSpeed Insights también le dirá cómo se desempeña su sitio web en el mundo real. Entonces, en la parte superior de cada auditoría, verá tres métricas llamadas Core Web Vitals. Estas deben estar en verde para tener un impacto positivo en sus resultados de SEO. Sí, puede obtener un impulso en el SEO si tiene Core Web Vitals en verde y el impulso es individual para cada una de las métricas. Y las otras tres en la parte inferior también son bastante importantes, especialmente la interacción con Next Paint, que se convertirá en una nueva Core Web Vital en marzo del próximo año.

Otro problema con Lighthouse es que es solo un algoritmo. Entonces, simplemente aprendes cómo funciona, ¿verdad? Y si sabes cómo funciona algo, entonces puedes engañarlo. Recibe una entrada, da una salida, ¿verdad? Y puedes encontrar fácilmente muchos artículos que muestran cómo puedes construir el sitio web menos accesible del mundo con un puntaje de Lighthouse de 100. Pero puedes hacer aún más. También es igualmente fácil engañar el puntaje de performance. Puedes detectar el agente de usuario de Lighthouse y servir una versión completamente diferente de tu sitio web o herramienta de auditoría.

Entonces, lo que he visto, y lo he visto desafortunadamente más de una vez, es que lo que hacen las personas es eliminar las etiquetas de script de la aplicación renderizada en el servidor y servir esto para la auditoría de Lighthouse. Y como JavaScript suele ser el principal cuello de botella, la principal razón por la que tenemos malos puntajes de performance, entonces mágicamente es muy alto. Pero no tiene nada que ver con una experiencia de usuario real, y si lo piensas, es simplemente estúpido. Porque Lighthouse se ha vuelto tan importante que lo estamos engañando sin ninguna razón real. No hay beneficio en eso, excepto mentirle a tu cliente, por ejemplo.

Entonces, después de escuchar mi presentación, puedes tener la impresión de que, en mi opinión, Lighthouse es completamente inútil. Y definitivamente ese no es mi punto de vista. Creo que Lighthouse es una herramienta maravillosa, realmente. Una herramienta maravillosa. Y, ya sabes, contribuye mucho a una web más rápida. Pero el problema no está en la herramienta en sí, sino más en la forma en que la estamos utilizando. O mal utilizando.

7. Using Lighthouse and Understanding User Experience

Short description:

Lighthouse es una herramienta que te guía para mejorar la calidad de la página, pero no proporciona respuestas definitivas. Un buen rendimiento implica hacer sacrificios y puede ser necesario sacrificar ciertos elementos. Lighthouse es útil para comparar diferentes versiones de un sitio web y auditar a la competencia. Si bien una puntuación por debajo de 100 puede ser una vergüenza para un blog, una puntuación de 60 se considera buena para un sitio web de comercio electrónico. Sin embargo, Lighthouse no es una herramienta confiable para medir la experiencia real del usuario. Para comprender cómo los usuarios experimentan su sitio web, hable directamente con ellos.

Su objetivo es guiarte para mejorar la calidad de la página, no para darte respuestas definitivas sobre si es bueno o malo. Y he visto sitios web con una gran user experience y una baja puntuación en Lighthouse, y viceversa. Un buen performance implica hacer sacrificios. Siempre debes tener eso en cuenta. Así que 100 nunca es una meta. Porque siempre tienes que sacrificar algo para mejorar el performance. A veces es un script analítico, a veces es una función. Y no siempre es una buena decisión comercial deshacerse de algunos de ellos. Así que recuerda que es un intercambio. No trates el performance como la respuesta. Trata el performance como la meta final porque podrías terminar con un sitio web que solo muestra texto sin CSS porque ese sería el sitio web perfecto para Lighthouse, ¿verdad?

Y ahora, ¿cuándo vale la pena usar Lighthouse? Para mí, Lighthouse brilla más cuando queremos comparar rápidamente diferentes versiones de nuestro sitio web para ver si hubo alguna mejora o tal vez una disminución en su performance. Entonces definitivamente vale la pena implementar Lighthouse en tus tuberías de CI-CD utilizando Lighthouse CI. Y también debes auditar sitios web con una complejidad similar o tus competidores para obtener una perspectiva realista de lo que es una buena puntuación y lo que es una mala puntuación. Porque para un blog, todo por debajo de 100 es una vergüenza. Realmente, es una lástima. Pero para el sitio web de e-commerce, ¿60? Es una buena puntuación. Es mucho más complejo. Requiere mucho más análisis. Es simplemente este tipo de sitio web donde el performance no debería ser la máxima prioridad. Debe ser extremadamente alto, porque como aprendimos, estamos perdiendo dinero. Pero al mismo tiempo, la user experience no es solo el performance. Y Lighthouse definitivamente no es una buena herramienta para medir la experiencia real del usuario. Porque es data sintético. No tiene nada que ver con cómo tus usuarios están experimentando eso.

Para comprender cómo tus usuarios experimentan tus sitios web, bueno, intenta hablar con tus usuarios. Podrías sorprenderte de cómo lo están experimentando. Y realmente no tienes que configurar herramientas de monitoreo adicionales para verificar eso. Si colocas la página en PageSpeed Insights, en la parte superior, verás cómo se puntúa en relación con esas cuatro métricas más importantes, tres. Entonces podrías pensar, ¿de dónde proviene realmente esta data? Esta es una imagen antigua de los resultados anteriores de PageSpeed Insights. Ahora tenemos tres en la parte superior, pero creo que es irrelevante.

8. Data Collection and Lab Data vs Real-World Data

Short description:

Estos datos provienen de los últimos 30 días y se recopilan en dispositivos que utilizan Chrome. Si tu sitio web es desplazable, verás los datos del mundo real. Los datos provienen del informe de experiencia del usuario de Chrome (CRUX), que recopila métricas de rendimiento de dispositivos que utilizan Google Chrome. Puedes acceder al historial de métricas en el panel de control de CRUX en Google Data Studio. Los datos de laboratorio medidos en un entorno específico no deben optimizarse en lugar de los datos del mundo real. Una puntuación sintética alta no necesariamente indica una buena experiencia de usuario. Eso es todo por hoy. Si estás interesado en comercio electrónico, echa un vistazo a mi boletín informativo.

Entonces, ¿de dónde provienen los data? Estos datos provienen de los últimos 30 días y se recopilan en dispositivos que utilizan Chrome. Es una tecnología muy importante. Por lo tanto, no incluye otros navegadores. Y si estás utilizando Chrome, en realidad, estás enviando automáticamente estos datos a Google. Así es como saben cómo se utiliza el sitio web. El único requisito para recopilar estos datos de cualquier sitio web es hacerlo desplazable. Entonces, si tu sitio web es desplazable, verás los datos del mundo real. No tienes que configurar nada más.

Y estos datos, si profundizamos un poco, provienen de algo llamado informe de experiencia del usuario de Chrome, CRUX, en resumen, que recopila métricas de rendimiento de todos esos dispositivos que utilizan Google Chrome. También puedes acceder al historial de tus métricas en el panel de control de CRUX en Google Data Studio. Es completamente gratuito. Puede generar un informe muy completo que te mostrará cómo ha ido cambiando tu rendimiento con el tiempo, cómo está cambiando según el dispositivo, etc. Es extremadamente útil. Y nuevamente, lo único que necesitas hacer es hacer que tu sitio web sea desplazable, y los datos se recopilan.

Ahora, antes de terminar, sigo hablando de esta diferencia entre los llamados datos de laboratorio que se miden en un entorno específico y los datos del mundo real de tus usuarios, y es importante no optimizar los primeros. Y aquí está la razón. Si haces una prueba de PSI en algunos sitios web, a menudo puedes ver esta imagen. ¿Qué está mal aquí? ¿Quién puede decirme? ¿Alguien? De acuerdo. Este es un sitio web de comercio electrónico. Y vemos que la puntuación sintética es 81. Dije que 60 es bueno para un sitio web de comercio electrónico. 81 es increíble, ¿verdad? Pero si observamos cómo se traduce en la experiencia de usuario real, vemos que es terrible. Como, los Core Web Vitals no se cumplen. Y si observamos cosas como la interacción hasta cierto punto, es terrible. Esto es solo un ejemplo de lo que podría suceder si solo optimizas la puntuación de salud del diseño. Podría pasar por alto por completo cómo tus usuarios están experimentando tu sitio web. Y eso es todo lo que tengo preparado para hoy. Espero que hayas aprendido algo. Si hay algún fanático del comercio electrónico aquí, tengo un boletín informativo sobre esto. Puedes echarle un vistazo.

QnA

AI and Measuring Performance

Short description:

Y si tenemos a algún fanático del rendimiento web, estoy publicando muchos tweets en Twitter si estás interesado. Gracias por tu tiempo y por recibirme. Hoy he aprendido mucho sobre The House. La pregunta principal en este momento es ¿qué hay de un enfoque de aprendizaje automático para evaluar un sitio web? Los algoritmos de IA se pueden utilizar para pruebas A-B y para correlacionar métricas comerciales y de rendimiento. Puede haber más herramientas en el futuro. Medir el rendimiento de las páginas que requieren autenticación es un desafío, pero es menos importante en paneles de control o aplicaciones B2B.

Y si tenemos a algún fanático del rendimiento web, estoy publicando muchos tweets en Twitter si estás interesado. Así que, muchas gracias. Gracias por tu tiempo. Gracias por recibirme. Muchas gracias. Por favor, pasa a mi oficina. Realmente disfruté mucho la charla. También he aprendido mucho sobre The House hoy. Es realmente gracioso, de hecho, porque pensé que podríamos pasar el resto, todo el día, sin hablar realmente de IA. Sé que hicimos copilot. Pero la pregunta principal en este momento es ¿qué hay de un enfoque de aprendizaje automático para evaluar un sitio web? Esa es una pregunta amplia. ¿Ves tal vez algún uso para... Aquí está la cosa. No es que esté muy relacionado con el rendimiento, pero está conectado con las cosas en las que están trabajando en el espacio del comercio electrónico. Por ejemplo, podrías usar algoritmos de IA para las pruebas A-B. Podrías usar IA, por ejemplo, para ver cómo se correlacionan tus métricas comerciales y tus métricas de rendimiento. Y al hacer eso, puedes predecir que, OK, tal vez debería aumentar un poco el rendimiento porque históricamente me dio un mejor aumento de ingresos, o cosas así. Pero sí, eso es todo lo que puedo decir al respecto.

Estoy de acuerdo. Siento que probablemente habrá más herramientas que saldrán a medida que pase el tiempo. Ya veremos. Y esta es otra buena pregunta que llegó de Alvaro, que es, ¿cómo puedes medir el rendimiento de las páginas que requieren autenticación primero? Actualmente confiamos en Lighthouse de DevTools porque Page Speed Insights no admite este caso. Sí. Y para eso, sugeriría tener una versión separada del sitio web que se pueda medir de forma sintética. Y desafortunadamente, si tienes páginas que requieren autenticación, simplemente no se pueden medir tanto. Pero al mismo tiempo, si tienes sitios web que requieren autenticación, probablemente sean paneles de control o aplicaciones B2B. Y para esos, el rendimiento generalmente no es tan importante. Quiero decir, es mucho menos importante que, por ejemplo, en el comercio electrónico. Pero sí, es un problema. Es un problema.

Alternative Website Version and JavaScript Budget

Short description:

Puedes configurar una versión alternativa de tu sitio web, incluso tener algo de tráfico en él, como tráfico sintético, pero es difícil. Mi herramienta preferida para medir el rendimiento es web page test. Yellow Lab es otra herramienta que recomiendo. En cuanto a la automatización de la medición sintética de la experiencia del usuario, no tengo idea, pero para el rendimiento, Lighthouse CI es una gran herramienta. El JavaScript idealmente debería tener un presupuesto de cero, ya que es el mayor cuello de botella de rendimiento. Los frameworks están evolucionando hacia la ejecución en el lado del servidor. Para un sitio web de comercio electrónico, apunta a un tamaño de JavaScript de 70-80 kilobytes o idealmente cero, y carga perezosamente los elementos interactivos.

Puedes hacer algunas cosas al respecto. Puedes configurar una versión alternativa de tu sitio web, incluso tener algo de tráfico en él, como tráfico sintético, pero es difícil.

Genial, genial. También tenemos otra pregunta, que es ¿qué hay del uso de webpagetest.org y el papel que podría desempeñar para las pruebas de rendimiento en el mundo real? Soy absolutamente fan de web page test. Así que estaba hablando de Lighthouse, pero esta no es mi herramienta preferida para medir el rendimiento. Mi herramienta preferida es en realidad web page test, simplemente pruébala. Verás cuántos conocimientos obtienes, cuántos consejos muy prácticos obtienes de ella. También recomendaría Yellow Labs. Búscalo en Google, Yellow Lab, Yellow Lab, en realidad. Yellow Lab, creo que es el más práctico. Si ejecutas una auditoría, rápidamente verás por qué lo digo.

Así que sí, genial, genial. Otro también es, ¿alguna idea de cómo automatizar la medición sintética de la experiencia del usuario? De la experiencia del usuario, no tengo idea de cómo medimos la experiencia del usuario sintética, pero si te refieres al rendimiento, mencioné dos veces una herramienta llamada Lighthouse CI. Básicamente, esta es una acción de GitHub muy sencilla. Implementarla no es realmente difícil. Además, Jakub Andrzejewski, que estaba hablando hace unos 30 minutos, tiene un artículo muy bueno sobre cómo agregar eso a tus tuberías de CI/CD. Échale un vistazo. Y esto es realmente genial para comparar cómo cambió el rendimiento de una implementación a otra. Pero nuevamente, los números que obtienen las personas, como los usuarios reales, podrían ser completamente diferentes.

Genial, gracias. Y otra pregunta que nos llega, ¿qué dirías que es un buen presupuesto desde la perspectiva del tamaño de JavaScript para un sitio web en la actualidad? Wow, solía ser de 170 kilobytes, que para los estándares de hoy... quiero decir, el presupuesto de JavaScript. Oh, idealmente cero. Honestamente, el mayor costo de todos los cuellos de botella de rendimiento en estos días es JavaScript. Y si observas cómo están evolucionando los frameworks, verás que todos están evolucionando hacia la ejecución en el lado del servidor. Hay una razón para eso. Diría que el presupuesto, bueno, también depende de lo que estés construyendo, ¿verdad? Para un sitio web de comercio electrónico, diría que no deberías exceder los 70-80 kilobytes comprimidos, idealmente cero, y cargar perezosamente todo lo que sea interactivo. Pero realmente, no pienses en esas cosas como un presupuesto que debes llenar. Intenta tener la menor cantidad de JavaScript posible, intenta cargar perezosamente, intenta ejecutar cosas en un servidor y simplemente coloca los archivos estáticos en el frontend. Ahí está.

Optimización de bibliotecas de terceros para el rendimiento

Short description:

Google Tag Manager, Analytics y otras bibliotecas de terceros pueden afectar el rendimiento. Para mitigar esto, considera utilizar herramientas como Party Town o NextScript para cargar scripts analíticos de forma asíncrona o en paralelo, separados del hilo principal. Evita cargar scripts analíticos junto con otros elementos en el hilo principal para mejorar la experiencia del usuario.

Genial. Vamos a pasar a la última pregunta. Sé que hay un par más. Así que recuerda, si estás en línea, hay una sala de preguntas y respuestas para el orador y si estás aquí, puedes subir y hablar con Philipp también. Pero para la última pregunta, Google nos dio Lighthouse, pero tal vez si no están optimizando Google Tag Manager, Analytics y algunas de sus otras bibliotecas de terceros y cosas así, ¿tienes algún consejo para las bibliotecas de terceros y el rendimiento y cómo aumentar el rendimiento cuando dependes de estas otras bibliotecas?

Sí, en primer lugar, hay una herramienta muy útil llamada Party Town. ¿Quién ha oído hablar de Party Town? Sí, de builder.io. Lo que hace Party Town es permitirte ejecutar esos scripts analíticos en un Web Worker. De esta manera, no afectas al hilo principal. Simplemente se cargan en paralelo. Pero a veces, también podría afectar tus datos de análisis, así que asegúrate de que la herramienta de análisis que estás utilizando esté en la lista de Party Town. Y también, hoy hemos escuchado que Daniel propondrá un RC de NextScript. NextScript, como NextScript, es una forma de cargar tus scripts, ya sea en un Web Worker o de forma asíncrona. Echa un vistazo a eso. Básicamente, lo peor que puedes hacer es cargar tus scripts analíticos junto con todo lo que está en el hilo principal. Porque afectarán la experiencia del usuario. Intenta tenerlos de forma asíncrona. Intenta tenerlos en paralelo, pero nunca en el hilo principal.

Eso es increíble. Me encanta cuando las charlas se conectan entre sí. Muchas gracias por sentarte y hablar con nosotros hoy. Y muchas gracias. Denle un aplauso. Gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion