Ganando la Carrera de Rendimiento

Hola a todos. Gracias por unirse. Mi nombre es Gil. Soy un ingeniero de software en Wix, y hoy quiero contarles cómo mejoramos el performance de millones de sitios web de Wix.

Para aquellos de ustedes que no lo saben, Wix es una plataforma para crear sitios web y aplicaciones web, y dado que los sitios web de Wix pueden ser muy complejos con muchas características y componentes diferentes, performance siempre ha sido uno de nuestros mayores desafíos. En los últimos años, invertimos mucho en performance. Implementamos muchas soluciones para optimizar sitios web, pero hoy quiero centrarme en un gran proyecto que generó una mejora masiva en performance.

Pueden ver el impacto de performance aquí. Este es un gráfico basado en métricas de Core Web Vitals. Estoy seguro de que muchos de ustedes ya saben lo que es, para aquellos de ustedes que no lo saben. Core Web Vitals es una métrica que Google desarrolló para medir la user experience de los sitios web en internet, y podemos usar Core Web Vitals para medir nuestras aplicaciones web, las aplicaciones que renderizan los sitios web de Wix. Pueden ver a Wix en el gráfico naranja, se compara con otras plataformas web o competidores, y pueden ver cuánto hemos mejorado, desde tener resultados muy bajos de Core Web Vitals hace solo unos años, hasta tener uno de los mejores resultados de Core Web Vitals, relativamente en un corto período de tiempo, y por supuesto esos resultados reflejan la user experience en nuestros sitios web. Entonces, aunque muchas cosas sucedieron durante este tiempo, el proyecto que estoy a punto de presentar a ustedes fue uno de los mayores influenciadores para esta mejora.

Bien. Entonces, en primer lugar, mi nombre es Gil. Soy un ingeniero de software en Wix, y en Wix formo parte del equipo de visualización. En el equipo de visualización desarrollamos la aplicación que renderiza los sitios web de Wix. Así que cada vez que un usuario visita un sitio web de Wix, nuestra aplicación se ejecuta y renderiza el sitio web.

Así que en los últimos dos años estoy liderando el equipo de performance donde intentamos encontrar y también, por supuesto, resolver problemas de performance en los sitios web de Wix. Volviendo a este gráfico, hoy quiero hablar sobre el camino que recorrimos. Antes de sumergirme en el proyecto y las soluciones de cómo realmente mejoramos la performance de los sitios web de Wix, quiero comenzar explicando los problemas que nos hicieron tener resultados tan bajos y, por supuesto, la user experience, y luego también, por supuesto, explicar la solución que solucionó esos problemas.

Es importante para mí decirles que ninguno de esos problemas y soluciones de los que voy a hablar son específicos de Wix. Ninguno de ellos es realmente específico de Wix. Tal vez, al principio, comenzaré con un ejemplo de nuestra aplicación, pero muy rápido también hablaré de por qué creo que esos problemas y también esas soluciones se pueden encontrar e implementar en cualquier aplicación web. Hablaré más de esto más tarde. Entonces, como dije antes, hay muchas cosas que hicimos y también que cualquiera puede hacer para mejorar la performance de las aplicaciones web en general, pero hoy quiero centrarme en lo más importante e impactante que hicimos. Implementamos muchas, muchas, muchas soluciones diferentes, pero lo que voy a hablar es en realidad el proyecto más grande. Fue el proyecto más grande que implementamos. También, creo, el problema más difícil que resolvimos, porque no son algunas líneas de código que puedes agregar a tu aplicación. Al resolver este problema, en realidad requiere más de un cambio en la architecture de la aplicación. Tuvimos que reescribir muchas partes de nuestra aplicación para resolver este problema. No es algo que simplemente cambie unas pocas líneas de código y todo se resuelva. Requirió un gran cambio, y por lo general, la mayoría de las aplicaciones requieren un cambio mayor. Hoy, quiero contarles cómo disminuimos drásticamente la cantidad de JavaScript que enviamos a los sitios web de Wix. Esto es en lo que me voy a centrar hoy.

Para aquellos de ustedes que están menos familiarizados con este problema, pueden ver cuánto JavaScript está descargando y ejecutando una aplicación en el navegador yendo a la pestaña de red en las herramientas de desarrollo del navegador, y en la parte inferior, pueden ver que tienen el tamaño de transferencia del JavaScript. En la pestaña de JavaScript, pueden ver el tamaño de transferencia y el tamaño del recurso. Ambos son importantes, la diferencia entre ellos es la compresión del JavaScript, lo que se descarga está comprimido, y el navegador lo descomprime y lo ejecuta, por lo que generalmente el tamaño del recurso que el navegador está ejecutando es en la mayoría de los casos mayor que el tamaño de transferencia, alrededor de 3, 4, 5, realmente depende del código.

Entonces, en primer lugar quiero hablar de por qué el tamaño de JavaScript es en realidad un problema, qué nos causó tener una cantidad tan grande de JavaScript que en realidad nos causó tener muchos problemas de performance, así que quiero tocar exactamente qué en nuestro código era en realidad el problema. Y voy a dar un ejemplo de una característica en un componente para demostrar este problema, pero luego por supuesto explicaré por qué este problema ocurrió en todo nuestro código. Y también por supuesto cómo es un problema muy común en muchas aplicaciones. Entonces, voy a comenzar con un ejemplo simple, es el ejemplo de una característica que tenemos en un componente de botón, y es la característica que permite a nuestros usuarios cuando agregan botones, como dije Wix es una plataforma para crear sitios web, o puedes agregar componentes y puedes agregar características a esos componentes, así que en este ejemplo es la característica de enlace del componente de botón, puedes definir a dónde quieres que vaya la página, qué página, o lo que quieras que suceda cuando el usuario haga clic en el botón, en realidad el usuario del sitio web. Entonces, como puedes ver en este panel, puedes elegir qué hacer cuando se hace clic en el botón, en caso de enlace, por supuesto, quieres enlazar a algún lugar, puedes enlazar a una página, puedes enlazar a una dirección web externa, puedes enlazar a un correo electrónico, un número de teléfono, abrir un lightbox, puedes hacer muchas cosas, en caso de un enlace de página, puedes elegir a qué página navegar y también cómo abrirla, tantas opciones, puedes elegir configurar este objeto de enlace.

Y pensemos en cómo alguien implementaría esta característica. Por supuesto, tendrías que guardar los data del panel, ¿verdad? Quiero decir, el desarrollador probablemente tomó todos los data del panel, los guardó en una database. Echemos un vistazo a los data guardados de nuevo.

Ejemplo simple de los data que se guardaron basándose en el panel. Así que tenemos los data del patrón. Por supuesto que tiene un ID y un tipo pero también dentro de la propiedad data puedes ver el objeto link. El objeto link incluye el tipo de enlace que el usuario eligió. En este caso era un enlace, un enlace de página. Significa que quieres navegar a una página diferente. Y también el ID de la página de este enlace, de la página que el usuario eligió. Así que por ejemplo, en este ejemplo, simplemente otra página en nuestra aplicación, en nuestro sitio web. Así que estos son los data guardados de este panel.

Y luego por supuesto, los data guardados necesitan ser pasados al componente de botón para crear el enlace en sí. Así que cuando el usuario haga clic, haremos la navegación. Así que de nuevo, quiero mostrarles cómo se vería un simple componente de React implementando esta lógica exacta. Así que un componente de React muy simple tomando las props. Por supuesto las props incluyen los data que acabamos de ver. Puedes ver el objeto link. Puedes ver la función calculate link en este código. Nos adentraremos en ella en un segundo. Pero puedes ver, devuelve un href, y luego tomamos el href y lo ponemos en la etiqueta anchor. Así que cada vez que el usuario haga clic en el botón, se realizará la navegación. Puedes ver que hay otro caso en caso de que el usuario no añada un enlace porque no tienes que añadir un enlace. No todos los botones tienen enlaces. Simplemente renderizamos un HTML diferente y usamos un botón, y tal vez en casos más complicados añadiremos una función onClick. Es muy importante diferenciar entre esas etiquetas. Para SEO es muy importante si tienes un href poner una etiqueta de anclaje, y si tienes un botón regular, no añadirlo. Es muy importante por razones de SEO. Este es un simple componente de React que implementa la característica que acabamos de presentar. Esta es solo una arquitectura general de nuestra solución desde el panel.

Guardamos los data en nuestros servidores, y luego cuando el usuario va al sitio web enviamos al lado del cliente, y por supuesto acabamos de ver el JavaScript del componente React que se envían al lado del cliente para crear el HTML que luego, por supuesto, mostramos el sitio web con.

Entonces, es una característica muy simple, pero hablemos un poco sobre algunos problemas que vemos con este código. El problema más grande está realmente en la función calculate link. Ahora vamos a profundizar en esta función, la función calculate link.

Así es como se ve la función calculate link. Obtiene algunos parámetros, pero luego puedes ver todos esos casos que, recuerda, vimos desde el panel. Firmamos el panel, esos casos, y ahora podemos ver todos esos casos en nuestro código. Entonces, si es un enlace de página, necesito calcular el enlace a la página. Podría ser un enlace externo. Probablemente también lo tenga en los data. Podría ser cualquier otro caso. Si quiero abrir un popup, probablemente necesitaré más información aquí. Entonces puedes ver que esta función tiene muchas, muchas opciones del panel. Entonces, repasemos los problemas que vemos aquí.

Probablemente puedes empezar a imaginar los problemas que tenemos aquí. Damos a nuestros usuarios muchas opciones para configurar los componentes, ¿verdad? Por supuesto, los componentes pueden hacer muchas cosas, especialmente los botones y especialmente las opciones de enlace. Entonces les damos muchas opciones y luego escribimos código para implementar esas opciones. Pero dado que el usuario solo puede elegir una opción, escribimos mucho código que en realidad no se utiliza en muchos casos, porque dado que el usuario solo puede usar una opción, la mayoría de los otros casos no se utilizan, por lo que este es mucho código JavaScript no utilizado que descargamos al cliente. Y por supuesto también, lo vimos también dentro de la función calculate link, pero también podemos verlo en el componente de botón. Porque también este código puede, solo hay un componente que, solo un HTML que podemos enviar. Entonces, pero también necesitamos implementar en el componente de botón, dos opciones en este caso, y probablemente más opciones, por lo que más código no utilizado. Entonces este es el primer problema. Muchas opciones hacen que los componentes descarguen mucho código no utilizado. Pero en realidad hay otro problema. Y en realidad es más difícil de ver en este ejemplo porque es un ejemplo muy pequeño. Puedes verlo aquí. Resolviendo el código que tomó los data guardados y en realidad creó el HTML. Y miremos el código, lo siento. Estoy hablando de este código. El código que realmente obtiene los data de nuestra estructura, de nuestros data guardados, y crea HTML.

En nuestro caso, es básicamente esta función calculate link. Ahora en nuestro caso, ejemplo simple, es solo una línea de código. Pero en casos más complejos, es en realidad más código que realmente tenemos que ejecutar. Tenemos que ejecutar este código. Así que incluso lleva más tiempo.

En este ejemplo, simplemente toma el objeto de la página y mapea el ID para obtener la URL de la página. Entonces probablemente estás pensando, ¿por qué necesito calcular estos data en lugar de guardarlos? Supongo que una solución aún más simple sería simplemente guardar los data como quieres verlos en lugar de calcular todas estas transformaciones en el lado del cliente. Entonces digamos que puedo guardar los data con el age ref en lugar de guardar lo que el usuario eligió aquí. Pero entonces si lo hago, si guardo el age ref, por ejemplo, esta URL que tengo aquí, realmente moveré el problema al lado del editor donde configuro el botón, porque entonces necesito tratar de averiguar qué sucede, ¿cómo transformo una URL a este panel? Básicamente va a ser muy difícil entender qué tipo de navegación eligió el usuario basándose en esta URL. Así que no quiero guardarlo para calcularlo cuando el usuario crea este panel, pero entonces si quiero calcularlo en el lado del cliente, necesito enviar todo este JavaScript.

Entonces, ¿qué hacemos? Antes de saltar a la solución, quiero hablar un poco sobre si es un problema específico de la semana. Y no lo creo. Creo que este problema de guardar data y luego enviarlo al lado del cliente y calcular el HTML a partir de los data guardados también es muy pesado en muchas aplicaciones. Normalmente no pensamos realmente cuando guardamos data, cómo vamos a presentarlo. Por ejemplo, como página de producto, no pensamos realmente, vale, cómo voy a mostrar esto página de producto. Normalmente pienso en lo que tiene este producto, pero cómo lo muestro, en muchos casos es completamente diferente, entonces necesito descargar JavaScript y descargar los data, tratando de calcular cómo quiero crear HTML. Además, tener muchas opciones para los componentes tampoco es un problema específico de Wix. Desarrollamos muchos, digo desarrolladores frontend, en React generalmente, creamos componentes complejos con muchas opciones que requieren mucho JavaScript, y a veces, solo usamos algunos de ellos en nuestro código. Entonces, de nuevo, mucho JavaScript que en realidad no se utiliza. Así que creo que cualquier aplicación web puede tener este problema, y estoy seguro de que muchas aplicaciones con problemas de performance tienen este problema.

Entonces, hablemos de la solución. Entonces, ¿cómo resolvemos no descargar mucho código no utilizado? En realidad reescribimos nuestros componentes en pequeños componentes específicos de la característica. Entonces, en lugar de tener este gran componente de botón que también podría tener un botón de enlace pero también botón regular en diferentes casos, botones de dirección web y muchos botones diferentes, ya sabes, simplemente tratando de implementar lo que el usuario quería, en realidad cortamos esos componentes en pequeños componentes específicos de la característica. Entonces, en lugar de tener este gran componente de botón, lo reescribimos en pequeños componentes específicos de la característica. Este es el primer paso, pero puedes ver que el href ya pasó de las props aquí, entonces ¿cómo calculamos el href? En realidad pasó, el href ahora se pasa desde el servidor. Entonces el segundo paso de la solución es calcular los data de la vista, que en nuestro caso es el href, lo calculamos en un servidor, pero no en el mismo servidor de donde provienen los data guardados. En realidad creamos un servidor frontend, que es algo entre el servidor backend y nuestra aplicación cliente. Así que toda esta función se ha movido completamente al backend, a nuestro servidor frontend, porque no tiene nada que ver con el navegador. Todos los data que utiliza esta función básicamente toman data guardados y calculan la vista data. Entonces, y por supuesto en este caso tenemos la URL basada en XML y por supuesto podemos enviarla a este servidor frontend.

Entonces, echemos un vistazo a la architecture. Si antes, antes de la solución, los datos guardados se enviaban al cliente junto con el JavaScript, ahora tenemos algo en medio que llamamos servidores frontend, básicamente es solo un servidor Node.js que está como en medio del servidor backend y una aplicación cliente. Y la mayoría del JavaScript ahora se pasa al servidor frontend. No tienes que descargarlo, simplemente se guarda allí. Y calculamos todos los datos de la vista dentro de este servidor, y luego enviamos solo los datos de la vista. Y cuando decimos datos de la vista, ahora mapearlo a HTML, calcular el HTML a partir de los datos de la vista es muy fácil. Necesitas muy poco JavaScript también para descargar y también para ejecutar. La aplicación cliente se vuelve mucho, mucho más pequeña, pero también, por supuesto, más rápida. Y también puedes ahora, si calculas los datos de la vista en el servidor frontend, puedes añadir caché en CDN, y entonces también no ejecutas este código JavaScript en muchos de los casos. Todo es desde la caché de CDN. Lo ejecutas una vez, lo calculas una vez, pero luego lo guardas en la CDN. Así que la próxima vez es aún más rápido. Así que ahora obtener estos datos es ahora rápido. Parece un cambio pequeño, pero en realidad fue un gran cambio tomar los datos guardados, tomar la función calculate delete, moverla al lado del servidor que crea solo los datos de la vista. Y puedes ver que solo los datos de la vista se mueven a los pequeños componentes de react que escribimos que solo crean el HTML. Un pequeño ejemplo de una característica en un componente, pero en realidad tenemos muchos componentes y muchas características. Y tuvimos este problema en casi todos los componentes y todas las características. Así que tuvimos que hacer una gran refactorización para implementar la solución en toda nuestra aplicación. Eso es lo que nos hizo tener esta mejora masiva. Lo hicimos en todas nuestras aplicaciones, en todas nuestras características, rediseñamos completamente nuestra aplicación, y movimos mucho código al servidor, lo almacenamos en caché, y ahora una aplicación cliente es muy, muy pequeña, solo recibe los datos de la vista, los transforma a HTML. Y eso es todo en el lado del cliente. ¿Puedes hacerlo en cualquier aplicación? Por supuesto, creo que tiene sentido hacerlo. Creo que tiene sentido hacerlo en muchas aplicaciones. Solo necesitas entender cuáles son tus datos que estás enviando al lado del cliente. Y luego necesitas entender qué código puedes mover realmente al lado del servidor para calcular los datos guardados en datos de la vista. Luego envías, luego tus componentes solo recibirán datos de la vista, que son muy similares a los HTML, por lo que no necesitarás ningún cálculo para mapear estos datos a HTML.

Para resumir, esto es, como dije al principio, hicimos muchas cosas para mejorar el rendimiento, y por supuesto no fue lo único, pero creo que este proyecto fue la principal razón por la que mejoramos tanto en los últimos años. Gradualmente movimos más y más componentes y características a esta architecture, y con eso mejoramos los revivals de código, y por supuesto en la user experience. Así que las conclusiones de hoy son que creo que la mejor manera de mejorar el tiempo de carga es disminuir la cantidad de descarga de JavaScript al lado del cliente. Puedes hacerlo moviendo la lógica del lado del cliente al lado del servidor, como hemos hablado. Puedes escribir componentes específicos de la característica, por lo que solo estás descargando los componentes que realmente necesitas, y no grandes componentes con muchas opciones, y por supuesto almacenando en caché las respuestas del servidor, ahora eso incluye los datos de Vue y la CDN, en realidad creará tu aplicación de una manera que es muy, muy rápida. Muchas gracias. Si tienes alguna pregunta, por supuesto, estoy aquí y puedes preguntarme.