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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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á.

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.