Mejora la velocidad y eficiencia de tu sitio web con Partytown

♪♪ Hoy estoy muy emocionado de hablar sobre cómo mejorar la velocidad y eficiencia de tu sitio utilizando PartyTown. Mi nombre es Adam Bradley. Soy director de tecnología de código abierto en Build.io. Otros proyectos de código abierto en los que he participado incluyen Ionic y Stencil. Y me divierto mucho trabajando en otro proyecto de código abierto de Builder llamado Quick.

Así que primero sumerjámonos en cuál es el problema. La respuesta corta es, bueno, es JavaScript. JavaScript es uno de los mayores contribuyentes a las páginas web lentas. A menudo se puede generalizar que cuanto más JavaScript se agrega a una página, más lenta es para el usuario. Ahora, la razón por la que JavaScript puede ralentizar una página varía por muchas razones diferentes. Pero algunos de los problemas más comunes provienen de los scripts pesados y sobrecargados que incluyen la interactividad cronometrada aumentada, la carga de red aumentada, la manipulación excesiva del DOM que los archivos JavaScript pueden hacer, y también cómo JavaScript puede bloquear el hilo principal.

La investigación muestra que cuanto más rápido es el sitio web, más altas son las tasas de conversión, independientemente de cuál sea la métrica de conversión. Y hay muchos estudios de casos bien documentados que proporcionan evidencia para respaldar esta afirmación. Y esta es solo una pequeña muestra de estudios de casos que profundizan en por qué importa el rendimiento. Pero profundicemos un poco más en lo que podemos hacer para mejorar el rendimiento y, en última instancia, mejorar las tasas de conversión de tu sitio. Ahora la web está llena de todo tipo de consejos sobre cómo mejorar el rendimiento de JavaScript, lo que puede ser un poco abrumador. Las numerosas optimizaciones ponen presión en los desarrolladores, y se centra a menudo en cómo mejorar tu código. Sin embargo, incluso con un código óptimo, aún hay problemas de rendimiento que abordar. Así que como puedes ver aquí, esta es solo una pequeña lista de cosas que a menudo aparecen en los resultados de búsqueda, como esto es lo que debes hacer con tu código. Así que recuerda esa parte.

Sin embargo, el mayor culpable del rendimiento del sitio web a menudo proviene de los scripts de terceros. Los scripts de primera parte son tu código, el código sobre el que tienes control y puedes mejorar. Sin embargo, los scripts de terceros se refieren a código externo que un sitio web carga desde un dominio y servidor diferente, sobre los cuales el propietario del sitio web no tiene control, o acceso directo para mejorar. Es código que se ejecuta en tu sitio, en la misma ventana y documento, pero no tienes control sobre él. Un ejemplo común de scripts de terceros incluye Google Analytics, Google Tag Manager, Optimizely, Hotjar y muchos otros. Si bien los scripts de terceros se utilizan a menudo para proporcionar funcionalidad valiosa y recopilación de datos, también tienen muchos problemas. Pueden agregar solicitudes HTTP adicionales que pueden llevar a tiempos de carga de página más largos, o bloquear la representación de la página principal, lo que puede resultar en una mala experiencia de usuario. Los scripts de terceros también pueden ser intensivos en recursos, utilizando valiosos recursos de CPU y memoria, lo que también puede llevar a tiempos de carga de página más lentos, especialmente en dispositivos móviles. A pesar de todos estos problemas, las organizaciones a menudo tienen razones válidas para incluir scripts de terceros, ya que los datos que proporcionan ayudan a tomar decisiones comerciales en toda la organización. Sin embargo, es importante sopesar los beneficios frente a las posibles consecuencias de rendimiento al cargar demasiados scripts de terceros.

Por lo tanto, es importante considerar cuidadosamente cuáles debes y no debes incluir en tu página web. Ahora, estudios recientes han demostrado que el número de scripts de terceros cargados en un dispositivo móvil está aumentando. Según el HTTP Archive, un dispositivo móvil solicita 10 scripts de terceros y 9 scripts de primera parte, lo cual es un aumento significativo con respecto a años anteriores, y la tendencia solo se espera que continúe. Y cuando llegamos al percentil 90, las páginas móviles solicitan 34 scripts de terceros y 33 scripts de primera parte. Por lo tanto, cuantos más scripts de primera parte tenga un sitio web, es más probable que agreguen scripts de terceros para proporcionar funcionalidad adicional y recopilar más data. Por lo tanto, es importante que los desarrolladores consideren el impacto de los scripts de terceros en el rendimiento de una página webperformance y evalúen cuidadosamente su uso.

Ahora, Lighthouse mide el rendimiento utilizando datos de laboratorio de redes y dispositivos predefinidos, lo que lo convierte en una excelente herramienta para medir el rendimiento durante el desarrollo. Sin embargo, cuando se trata de medir el rendimiento del sitio web en un entorno de producción, se recomienda utilizar herramientas que incorporen métricas de usuarios reales. Estas herramientas proporcionan una representación más precisa de cómo los usuarios experimentan su sitio web y pueden ayudar a identificar problemas de rendimiento que pueden no ser visibles en pruebas de laboratorio.

Una de estas herramientas que utiliza tanto datos de laboratorio como datos del mundo real recopilados de los usuarios es PageSpeed Insights. Y otras herramientas excelentes incluyen webpagetest.org y speedcurve.com. Al utilizar estas herramientas, los desarrolladores pueden obtener información valiosa sobre cómo los usuarios experimentan su sitio web y tomar decisiones informadas sobre cómo optimizar el rendimiento.

Uno de los problemas más comunes en la medición del rendimiento del sitio web es que los problemas pueden no aparecer durante el desarrollo. Esto se debe a que los desarrolladores suelen probar los sitios web en dispositivos de alta gama con conexiones a Internet de alta gama, lo cual puede no ser representativo de los usuarios finales que accederán a su sitio web en producción. Por ejemplo, durante el desarrollo, el rendimiento de un sitio web puede parecer extremadamente rápido cuando se prueba en un MacBook Pro con una red local. Pero esto no se traduce en usuarios finales reales que probablemente accederán a su sitio desde teléfonos de gama media mientras están en movimiento y en diferentes lugares. Esto puede resultar en un sitio web de menor rendimiento que es muy diferente al que se probó durante el desarrollo. Para evitar este problema, es importante probar los sitios web en una variedad de condiciones que se asemejen más al mundo real.

Ahora, los scripts de terceros pueden tener un impacto negativo en el rendimiento del sitio web de varias formas. Uno de los problemas más significativos es que compiten con tu código por recursos en el hilo principal. Estos scripts tienen la misma prioridad de ejecución que tu código, y debes compartir el acceso a los objetos de la ventana y el documento de manera equitativa. Esto significa que cuando tu código se está ejecutando, está compitiendo con los otros scripts de terceros por los mismos recursos. Desafortunadamente, tu código no tiene ninguna prioridad sobre los scripts de terceros, lo que lleva a una situación en la que los scripts están luchando de manera equitativa en el hilo principal, lo que resulta en un rendimiento más lento del sitio web.

Además, la competencia por recursos a menudo contribuye a la fragmentación del diseño, lo que ralentiza aún más el sitio web. Al ejecutar herramientas de análisis de rendimiento, es evidente que los scripts de terceros suelen ser los que más impacto tienen en el rendimiento en general de la experiencia del usuario. Pero esta es la situación en la que nos encontramos. No es tan simple como optar por no ejecutar scripts de terceros porque en muchos casos, es un requisito de tu organización. Y recuerda, no tienes control sobre estos scripts de terceros, no puedes modificarlos. Y además, no puedes darle prioridad a tu código para que se ejecute más rápido que su código, ya que todos compiten por los mismos recursos en el mismo hilo principal.

Ahora, una solución posible y poderosa podría ser utilizar los web workers para ayudar a mejorar los problemas de rendimiento causados por los scripts de terceros. Como sabemos, los scripts de terceros compiten por recursos en el hilo principal con tu código y pueden ralentizar todo el sitio web. Entonces, si ejecutáramos el código en un hilo de fondo separado, podríamos desbloquear el hilo principal y ayudar a mejorar el rendimiento. Pero aunque parezca una solución sencilla, no siempre es tan práctica. El desafío es que no podemos modificar ni mejorar el código de otro servicio. Uno de los desafíos al usar los web workers para ejecutar scripts de terceros es que los workers no pueden acceder a la ventana o al documento del hilo principal. Esto se debe a que estas variables globales no están presentes en el entorno del worker, lo que puede ser problemático ya que muchos scripts de terceros dependen de la ventana y el documento para ejecutar numerosas operaciones en el DOM. Aunque es posible comunicarse entre el hilo principal y el hilo del worker, la transferencia de data a menudo es, o es, asíncrona. E incluso si crearas una capa de abstracción para la comunicación, aún necesitarías una promesa o una devolución de llamada para enviar los data. Además, dado que no se puede modificar el código de los scripts de terceros, no es factible pedirle al proveedor del servicio que reescriba su código para permitir operaciones asincrónicas en el DOM.

Entonces, para resumir, los web workers serían una solución ideal para ejecutar scripts de terceros. Sin embargo, es importante tener en cuenta que no es posible modificar su código. Además, cualquier interacción entre el hilo principal y el web worker es asíncrona. Por lo tanto, en realidad, es un desafío utilizar los web workers como una forma de evitar problemas de rendimiento causados por los scripts de terceros. Aquí es donde entra en juego PartyTown. Aborda el problema de los scripts de terceros que afectan el rendimiento del hilo principal de la interfaz de usuario. Permite que estos scripts se ejecuten desde un web worker, dejando el hilo principal libre para manejar tu código. Al hacerlo, PartyTown minimiza las posibilidades de que los scripts de terceros bloqueen el hilo principal y afecten el rendimiento de la interfaz de usuario. Ahora, con PartyTown, puedes escribir scripts de terceros desde un web worker y asegurarte de que el hilo principal se dedique a tu código y minimizar cualquier impacto negativo en los scripts de terceros en el rendimiento de la interfaz de usuario.

Aquí tienes un diagrama generalizado de cómo un web worker puede reducir el cuello de botella en el hilo principal. A la izquierda, tanto tu código como su código compiten por los mismos recursos. A la derecha, tu código puede utilizar libremente el hilo principal y su código se descarga para ejecutarse en un hilo de fondo. Al ejecutar scripts de terceros en un hilo de fondo, el hilo principal ahora puede dedicarse por completo a tu código.

Ahora determinar la mejora de rendimiento proporcionada por PartyTown no es sencillo ya que varía según varios factores. En resumen, depende del número de scripts de terceros utilizados en el sitio y las operaciones que realizan. No hay una respuesta única para todos los casos. Por ejemplo, en un ejemplo de prueba donde esta página en sí no hace nada, obtiene una puntuación de 100 sin problemas. Sin embargo, si agregamos algunos scripts de terceros, el rendimiento de la página baja a 77. Nuevamente, esta página no hace absolutamente nada y debería obtener fácilmente una puntuación de 100. Pero cuando esos mismos scripts se ejecutan desde PartyTown, el rendimiento de la página vuelve a ser 100. Esto demuestra la diferencia que PartyTown puede hacer para mejorar una página web simple. Así que imagina el impacto que puede tener cuando se utiliza una gran cantidad de JavaScript en un sitio web promedio.

Entonces, ¿cómo funciona PartyTown en realidad? Bueno, todo comienza con el elemento script común y su uso del atributo type. Por ejemplo, si el atributo type se establece en text JavaScript o en el nuevo tipo de módulo, el navegador ejecutará el script en el hilo principal. Además, la etiqueta script también ejecutará el código si no tiene ningún atributo type en absoluto. Así que nada de esto es demasiado sorprendente, ¿verdad? Es el elemento script normal. Sin el atributo type, sabe que debe ejecutar el código. Si usas un atributo type reconocible, nuevamente, ejecutará el código en el hilo principal. Pero, ¿qué sucede si cambiamos el atributo type a un valor que el navegador no reconoce, como, digamos, text slash PartyTown? Entonces, el navegador simplemente omitirá por completo el script y no lo ejecutará. Según el navegador, es solo otro div vacío que no hace absolutamente nada. Luego, PartyTown puede usar un selector de consulta para encontrar todos los scripts que el navegador ya omitió y no ejecutó, pero en cambio, queremos ejecutar esos scripts dentro de un web worker. El primer ejemplo muestra un elemento script común que se ejecuta en el hilo principal. El segundo ejemplo muestra cómo agregar text slash PartyTown moverá el mismo código para que se ejecute desde un web worker. Esto también permite al desarrollador elegir qué scripts deben y no deben ejecutarse dentro del web worker. No se requiere ningún cargador, preprocesador o paso de construcción para que el sistema funcione. Y como solo estamos cambiando un atributo HTML, no está vinculado a una tecnología específica como Webpack, React, PHP o cualquier otra. Y debido a que no está diseñado para una herramienta específica, también es fácil de integrar en cualquier página web. Ahora es importante recordar que un web worker está aislado del hilo principal y no tiene acceso a los objetos window o document. Si intentamos ejecutar código que depende de estos objetos, como Document.title, desde un web worker, se producirá un error ya que un web worker no tiene conocimiento de estos objetos.

Si ejecutáramos este código, el navegador estaría como, ¿qué diablos es esta cosa llamada Document? No tengo idea de qué es eso. Y los scripts de terceros a menudo se cargan con operaciones del DOM justo como esta. Estas operaciones deben poder funcionar sin problemas, ya que no podemos modificar cómo se escribieron inicialmente los scripts de terceros. Por lo tanto, es necesario encontrar una solución que permita que los scripts se ejecuten sin problemas sin interferir con el rendimiento del hilo principal de la interfaz de usuario.

Reconocemos que los scripts de terceros acceden a objetos globales solo disponibles en el hilo principal, pero no están disponibles en el hilo del trabajador. Como resultado, Python utiliza proxies para interceptar y reenviar cualquier operación del DOM desde el Web Worker al hilo principal. Al hacerlo, Python permite que un Web Worker acceda indirectamente a los objetos window y document del hilo principal. Ahora, el proxy actúa como un middleware que intercepta las solicitudes relacionadas con el DOM realizadas por los scripts de terceros que se ejecutan en el Web Worker y las reenvía al hilo principal. El hilo principal procesa estas solicitudes y devuelve los valores correspondientes al hilo del trabajador. Este enfoque asegura que Python pueda mantener una experiencia fluida y consistente para el código de los scripts de terceros, independientemente de si se ejecuta en el hilo principal o en el hilo del trabajador.

Ahora, como se mencionó anteriormente, la comunicación entre el hilo principal y el Web Worker es asíncrona. Esto se debe a que los hilos se ejecutan en contextos de ejecución separados. Sin embargo, esto plantea un desafío para Python, especialmente cuando se trata de ejecutar scripts de terceros. Ahora, los scripts de terceros a menudo se escriben asumiendo que se están ejecutando en el hilo principal y, como tal, dependen en gran medida de operaciones síncronas. Estas operaciones pueden incluir el acceso al DOM, la modificación de estilos, la lectura de cookies, entre muchas otras cosas. Para que Python funcione de manera efectiva, debe poder garantizar que estas operaciones funcionen exactamente de la misma manera que lo harían si se ejecutaran en el hilo principal. Ahora, en lugar de intentar replicar todo el DOM en el Web Worker, Python redirigirá cualquier operación del DOM al hilo principal, ejecutará el comando allí, y devolverá el valor al Web Worker. Esto permite que los scripts de terceros se ejecuten normalmente sin ninguna modificación y con el mismo nivel de rendimiento que si se ejecutaran en el hilo principal. De esta manera, Python garantiza que los scripts de terceros puedan funcionar a pesar de la naturaleza asíncrona de la comunicación entre los hilos.

Aquí tienes un ejemplo sencillo de código de un script de terceros que ejecuta document.title. Cuando su script llama a document.title, es una llamada de bloqueo y el getter espera un valor. No espera que el getter devuelva una promesa. Espera un valor de cadena de document.title. Este es en realidad el mayor desafío que Python tiene que resolver. Como mencionamos anteriormente, sin importar lo que hagamos, enviar mensajes entre el hilo principal y el hilo del trabajador requiere una tarea asíncrona. Básicamente, tenemos que usar una API de PostMessage y escuchar esos mensajes desde el hilo opuesto, lo cual es completamente asíncrono. Esta es la otra pieza importante del rompecabezas, que permite que el Web Worker se comunique con el hilo principal de manera síncrona. En este diagrama, el hilo del trabajador llama a un getter esperando un valor, pero nuestro proxy enviará una solicitud XHR síncrona, que es interceptada por el service worker para que pueda comunicarse con el hilo principal. Y al final, la solicitud XHR síncrona devuelve el valor del getter. Y según el script de terceros que se ejecuta desde el Web Worker, esta fue una tarea de bloqueo síncrona.

Y debido a esta arquitectura, también podemos hacer algunas cosas interesantes. Nos permite agregar a una lista blanca lo que un script puede y no puede hacer. Por ejemplo, leer navigator.userAgent o leer document.cookies podría devolver una cadena vacía. O podría usarse para llamadas de eventos como la temida llamada a la función document.write. Y otra característica interesante de esto es que PartyTown también viene con una versión de depuración, que ayuda a los desarrolladores a inspeccionar mejor lo que hacen los scripts de terceros. Ahora, según tu configuración, puedes decidir qué tipos de llamadas se deben registrar para que puedas ver mejor lo que está sucediendo. Y puedes ver los valores pasados a y recibidos de cada comando de cada script de terceros, lo cual tradicionalmente es bastante difícil de hacer.

Hasta ahora hemos hablado de cómo PartyTown utiliza los service workers para interceptar las solicitudes, pero esto es en realidad el último recurso. Por defecto, utiliza átomos y búferes de matriz compartida cuando están disponibles, lo cual también tiene beneficios de ofrecer una comunicación 10 veces más rápida entre los diferentes hilos. Sin embargo, la desventaja es que el documento debe optar por utilizar búferes de matriz compartida mediante los encabezados de respuesta HTTP del servidor. Por lo tanto, esto puede ser un poco difícil de implementar, pero una vez implementado, una vez que estos encabezados de respuesta entren en vigor, no es práctico para la mayoría de los sitios tener esta configuración activada ya que muchas cosas como imágenes y scripts podrían dejar de funcionar. Dado que solo hemos tenido poco tiempo para revisar todo esto, te animo a que consultes la documentación de PartyTown para obtener más información sobre los átomos y cómo usarlos en tu sitio.

También vale la pena señalar que nada es perfecto y PartyTown no es una excepción. Estos son solo algunos de los problemas comunes que ocurren y que vemos con frecuencia en PartyTown. Algunos de ellos son la confusión sobre cómo enviar eventos desde el hilo principal al web worker o problemas de cores que ocurren cuando ciertos scripts de terceros no proporcionan un encabezado cores correcto que necesitas configurar para intermediar las respuestas. Otros problemas pueden ser que las actualizaciones de la interfaz de usuario de los scripts de terceros son demasiado intensivas y la comunicación entre dos hilos diferentes no puede mantenerse al día. Y se puede observar un poco de tartamudeo entre los dos. Entonces, básicamente, lo que estoy diciendo es que no todos los scripts de terceros funcionan correctamente. Realmente depende de lo que haga ese script y depende de los desarrolladores probar si es un buen candidato para PartyTown o no. Y también necesitamos mucha ayuda de los proveedores. Entonces, si estás intentando que tu sitio o tu servicio funcione con PartyTown, nos encantaría tener más interacción con o trabajar con los diferentes servicios para que esto funcione en su servicio.

Aquí, me gustaría hablar sobre el problema más común que vemos en PartyTown y eso sería la intermediación de las solicitudes HTTP. A menudo, los scripts de terceros se agregan a una página incluyendo la etiqueta de script en el cuerpo. Al usar este enfoque tradicional, la respuesta HTTP del script no requiere encabezados cores. Sin embargo, debido a que PartyTown solicita los scripts desde un web worker, tiene que usar Fetch, no la etiqueta de script. Por lo tanto, la respuesta del script requiere los encabezados cores correctos. Ahora, muchos scripts de terceros proporcionan los encabezados cores correctos, pero no todos lo hacen. Para los servicios que no agregan los encabezados correctos, se debe utilizar un proxy inverso a otro dominio para proporcionar los encabezados cores. Entonces, a continuación, te animo a que consultes el sitio web de la documentación. Nuevamente, PartyTown no está vinculado a un marco de trabajo específico, por lo que se puede utilizar desde cualquiera de ellos o incluso sin ningún marco de trabajo.

Pero el sitio de PartyTown también documenta la forma más fácil de integrarlo en tus proyectos existentes. Esto incluye tanto Next.js como Gatsby, que tienen una forma de ejecutar sus scripts utilizando una solución de estrategia de trabajador, que, como puedes imaginar, es simplemente PartyTown. Pero también hay integraciones para cualquier aplicación React, Angular, Astro y muchos más. Y si no ves tu marco favorito allí, entonces, por favor, a nuestro sitio de documentación le encantaría recibir una solicitud de extracción de tu parte para agregarlo allí.

Así que por favor, prueba PartyTown, pruébalo en tu sitio web y avísanos cómo va. Es de código abierto y tiene licencia MIT, pero también nos encantaría contar con tu ayuda para probar los diferentes escenarios de scripts de terceros que existen en la naturaleza. Y PartyTown en sí mismo está construido y mantenido por nuestro equipo en builder.io. En realidad, todo el proyecto surgió mientras construíamos Qwik, que es un marco basado en la idea de utilizar la capacidad de reanudación en lugar de la hidratación. Qwik merece muchas presentaciones propias, pero en resumen, no importa lo rápido que hagamos Qwik, los sitios web aún tienen un problema sin resolver de uso de scripts de terceros. Y es por eso que builder.io ha invertido en proyectos de código abierto como estos. Queremos asegurarnos de que nuestros sitios puedan construirse y seguir escalando sin sacrificar el rendimiento, ya sea código de script de primera o tercera parte.

Así que te animo a que eches un vistazo tanto a Qwik como a Builder. Eso es todo por ahora. Hay mucho, mucho más de qué hablar sobre PartyTown, así que te animo a que vayas al sitio web, aprendas más al respecto y veas cómo puedes integrarlo en tu sitio web tú mismo. Avísanos si surgen problemas y por favor, pruébalo. Avísanos cómo te va. Gracias de nuevo por tu tiempo.