Mejora la velocidad y eficiencia de tu sitio web con Partytown

Rate this content
Bookmark

¡Desata todo el potencial de tu sitio web con Partytown! Di adiós a las páginas lentas y a las bajas puntuaciones de Lighthouse causadas por scripts de terceros pesados. Con Partytown, tu hilo principal se dedica únicamente a tu código, liberándolo para que se ejecute de manera más suave, rápida y eficiente que nunca. Potencia tu sitio web con un rendimiento ultrarrápido moviendo todos los scripts no críticos a un web worker, donde se ejecutarán sin problemas en segundo plano. Prepárate para alcanzar el siguiente nivel de rendimiento web con Partytown.

20 min
06 Jun, 2023

Video Summary and Transcription

La charla de hoy trata sobre cómo mejorar la velocidad y eficiencia del sitio utilizando PartyTown, una herramienta que ejecuta scripts de terceros desde un web worker, minimizando su impacto en el hilo principal de la interfaz de usuario. La inclusión de scripts de terceros en las páginas web debe considerarse cuidadosamente debido a su posible impacto en el rendimiento. Las pruebas en el mundo real son cruciales para identificar problemas de rendimiento que pueden no aparecer durante el desarrollo. PartyTown ofrece funciones como la capacidad de incluir scripts en una lista blanca y es compatible con varios frameworks para una integración sencilla. Fue desarrollado por el equipo de builder.io para garantizar que los sitios web puedan escalar sin sacrificar el rendimiento.

Available in English

1. Introducción a la velocidad y eficiencia del sitio

Short description:

Hoy discutiremos cómo mejorar la velocidad y eficiencia del sitio utilizando PartyTown. JavaScript es un gran contribuyente a las páginas web lentas, causando problemas como mayor interactividad, carga de red, manipulación del DOM y bloqueo de hilos. Los sitios web más rápidos conducen a tasas de conversión más altas, respaldadas por estudios de casos. Si bien hay muchos consejos sobre cómo optimizar el código, los scripts de terceros suelen ser los principales culpables de los problemas de rendimiento. Estos scripts, como Google Analytics y Optimizely, pueden agregar solicitudes HTTP, bloquear la representación de la página y consumir recursos. Las organizaciones deben equilibrar los beneficios de los scripts de terceros con sus consecuencias en el rendimiento.

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

2. Impacto de los Scripts de Terceros

Short description:

Es importante considerar cuidadosamente la inclusión de scripts de terceros en tu página web. Estudios recientes muestran un aumento en el número de scripts de terceros cargados en dispositivos móviles. Cuantos más scripts de primera parte tenga un sitio web, es más probable que agreguen scripts de terceros para funcionalidad adicional y recopilación de datos. Los desarrolladores deben considerar el impacto de los scripts de terceros en el rendimiento y evaluar su uso.

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.

3. Medición de rendimiento y pruebas en el mundo real

Short description:

Lighthouse es una excelente herramienta para medir el rendimiento durante el desarrollo, pero se necesitan métricas de usuarios reales para entornos de producción. Herramientas como PageSpeed Insights, webpagetest.org y speedcurve.com brindan información valiosa sobre la experiencia del usuario y ayudan a optimizar el rendimiento. Probar sitios web en condiciones del mundo real es crucial para evitar problemas de rendimiento que pueden no aparecer durante el desarrollo.

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.

4. El impacto de los scripts de terceros en el rendimiento

Short description:

Los scripts de terceros compiten con tu código por recursos en el hilo principal, lo que resulta en un rendimiento más lento del sitio web. Los web workers proporcionan una posible solución, pero no pueden acceder a la ventana o al documento del hilo principal. La comunicación entre el hilo principal y el web worker es asíncrona, lo que dificulta el uso de los web workers para evitar problemas de rendimiento causados por los scripts de terceros. PartyTown resuelve este problema permitiendo que los scripts de terceros se ejecuten desde un web worker, minimizando su impacto en el hilo principal de la interfaz de usuario y mejorando el rendimiento de la interfaz de usuario.

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.

5. Mejorando el rendimiento con PartyTown

Short description:

Un web worker puede reducir el cuello de botella en el hilo principal al descargar los scripts de terceros para que se ejecuten en un hilo de fondo. PartyTown mejora el rendimiento de las páginas web ejecutando scripts de terceros desde un web worker, permitiendo que el hilo principal se enfoque en tu código. La mejora de rendimiento proporcionada por PartyTown varía según factores como el número de scripts de terceros y sus operaciones. Cambiar el atributo type del elemento script a 'text/PartyTown' permite que PartyTown omita la ejecución de scripts en el hilo principal y los ejecute en un web worker. Esta flexibilidad hace que PartyTown sea fácil de integrar en cualquier página web sin necesidad de herramientas adicionales o pasos de construcción. Sin embargo, es importante tener en cuenta que un web worker está aislado del hilo principal y no tiene acceso a los objetos window o document.

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.

6. Ejecución de scripts de terceros en un Web Worker

Short description:

Los scripts de terceros a menudo dependen de operaciones síncronas y acceden a objetos globales solo disponibles en el hilo principal. Python utiliza proxies para interceptar y reenviar las operaciones del DOM desde el Web Worker al hilo principal, permitiendo que los scripts de terceros se ejecuten sin problemas. La comunicación entre el hilo principal y el Web Worker es asíncrona, pero Python redirige las operaciones del DOM al hilo principal, asegurando una ejecución síncrona. Este enfoque resuelve el desafío de ejecutar scripts de terceros en el Web Worker y proporciona una experiencia consistente.

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.

7. Funciones de PartyTown y Problemas Comunes

Short description:

PartyTown permite la capacidad de agregar scripts a una lista blanca, ofrece una versión de depuración para una mejor inspección y admite átomos y búferes de matriz compartida para una comunicación más rápida. Sin embargo, el uso de búferes de matriz compartida puede causar problemas prácticos. Es importante probar los scripts de terceros para verificar su compatibilidad con PartyTown y colaborar con los proveedores para que funcione correctamente. El problema más común es la intermediación de las solicitudes HTTP, que puede requerir un proxy inverso para los encabezados correctos.

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.

8. Integrando PartyTown y Builder.io

Short description:

El sitio de PartyTown ofrece una integración fácil en proyectos existentes. Admite Next.js, Gatsby, React, Angular, Astro y más. Se anima a los usuarios a probar PartyTown, probarlo en sus sitios web y proporcionar comentarios. PartyTown es de código abierto y tiene licencia MIT. Fue creado por el equipo de builder.io mientras desarrollaban Qwik, un marco centrado en la capacidad de reanudación. El objetivo es garantizar que los sitios web puedan escalar sin sacrificar el rendimiento, ya sea utilizando scripts de primera o tercera parte. Echa un vistazo a Qwik y Builder, y explora el sitio web de PartyTown para obtener más información y opciones de integración.

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.

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 Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
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 Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
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

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 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
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