El Impacto en el Rendimiento del JavaScript Generado

♪ Hola a todos. Bienvenidos. Hoy, vamos a hablar sobre el impacto en el rendimiento del JavaScript generado. Mi nombre es Abhijit. Actualmente trabajo en Sentry, manteniendo nuestros SDKs de JavaScript de código abierto con licencia MIT. Y estos son algunos de los SDKs más utilizados en el mundo, y tenemos un poco de experiencia sobre cómo las personas están construyendo aplicaciones y usando JavaScript.

Una de las cosas más importantes que la gente nos menciona todo el tiempo es que el SDK de JavaScript que les damos, especialmente el de nuestro navegador front-end, es simplemente demasiado grande. Y lo que quiero decir con grande es por el tamaño del paquete. Es tan grande que dudan en cargarlo en su aplicación. Así que, ahora, esta es realmente una preocupación válida y algo que estamos buscando solucionar todo el tiempo, pero es importante pensar, bien, ¿por qué la gente sigue viniendo a nosotros por esto? Esto es realmente porque el tamaño del paquete es bastante importante.

Entonces, tiene una correlación directa con la rapidez con la que se carga una página. Y, por lo tanto, también está directamente correlacionado con la experiencia del usuario. Así que, quieres tener sitios web que tengan menos indicadores de carga, que carguen más rápido, que se sientan más ágiles. Todo eso afecta directamente cómo un usuario percibe y usa tu sitio. Y así, gestionar el tamaño de tu paquete, tener menos JavaScript cargado es realmente importante. Ahora, sabemos que, bien, esto es algo que la gente quiere reducir. Entonces, ¿cómo reduce típicamente la gente su tamaño de paquete? Bueno, generalmente, echas un vistazo al código que escribes y usas. Esto significa que estás analizando lo que estás agregando a tu aplicación y estás determinando si es importante o no.

Entonces, típicamente, esto será como usar bibliotecas alternativas más pequeñas. Por ejemplo, cambiar de React a Preact, carga diferida de tu JavaScript para que solo cargues exactamente lo que necesitas. Y cada vez que uses un componente u otra lógica, lo cargas de manera diferida. O eliminas JavaScript por completo e intentas eliminar su uso de tu aplicación. El escenario más común para esto es, por ejemplo, pasar de renderizar tu aplicación del lado del cliente a renderizarla del lado del servidor. Pero un tema importante aquí es que estas son todas estrategias para el código que escribes. Pero el código que escribes no es realmente el código que se ejecuta en el navegador, ¿verdad?

En las aplicaciones modernas de JavaScript, esto es completamente diferente. En las aplicaciones modernas de JavaScript, el usuario ejecuta JavaScript generado. Esto significa que necesitas mirar y entender el JavaScript generado para mejorar el tamaño de tu paquete, no solo el JavaScript que escribiste. Ahora, ¿qué quiero decir con JavaScript generado? Lo he mencionado un par de veces ahora mientras hemos hablado juntos. Me refiero a través de un proceso de construcción. Hemos hablado juntos. Me refiero a través de un proceso de construcción. Para la mayoría de las pilas modernas de JavaScript, ya sea que estés renderizando del lado del cliente o del lado del servidor con un framework como Next.js, Nuxt o SvelteKit, tomas algún JavaScript y TypeScript de entrada, lo pasas a un empaquetador como Veet, Webpack, Rollup, y obtienes algo de JavaScript al final. Usar un proceso de construcción es realmente útil. Puedes hacer tree shaking de JavaScript no utilizado, transpilar de TypeScript a JavaScript, soportar navegadores más antiguos inyectando polyfills o compilando hacia abajo APIs de navegadores más antiguos, y puedes inyectar lógica en tiempo de construcción, lo cual es súper útil para sitios construidos estáticamente. Prácticamente todo el mundo usa un proceso de construcción en este punto. Probablemente estés usando Veet o Webpack o una de esas cosas bajo el capó ahora. Así que con eso en mente, todos están usando un proceso de construcción. Puedes ir sin construcción, pero todos los que ejecutan aplicaciones grandes y enormes están ejecutando procesos de construcción. Y así hay muchas mejoras que podemos tomar con cómo las construcciones generan JavaScript. Aquí tenemos cinco áreas principales de mejora. Minificación, compilación hacia abajo, transpilar, compresión y tree shaking. Vamos a omitir el tree shaking esta vez, pero lo tocaré brevemente al final. Así que primero es la minificación, que es un proceso de hacer que tus activos de JavaScript sean lo más pequeños posible, típicamente eliminando tokens innecesarios y acortando nombres de variables o funciones. Así que puedes ver aquí un ejemplo. A la izquierda, pasamos de una función de JavaScript que tiene un objeto dentro de ella, y la minificamos, eliminando comentarios, espacios en blanco, acortando nombres siempre que sea posible. Lo complicado con la minificación y donde entra la parte de optimización es que no todo puede ser minificado o acortado. No puedes minificar palabras clave reservadas como typeof, function, return. No puedes minificar claves de objetos porque son necesarias para hacer búsquedas en nuestro objeto.

De lo contrario, no puedes hacer búsquedas. Y no puedes minificar métodos de clase porque tienes que llamar a los métodos por su nombre. Y así, si los acortas, ya no funcionan. Esto realmente significa que el diseño de la API importa mucho, y cómo diseñas tus programas para que puedan ser minificados más fácilmente puede afectar mucho el tamaño de tu paquete.

Aquí hay un ejemplo de los métodos de clase. A la izquierda hay una clase API de ejemplo, algo que solíamos usar en el Sentry SDK, pero lo des-Sentryfiqué mucho. Y a la derecha aquí hay una versión minificada. Lo embellecí para que mantuviéramos el espacio en blanco para que sea más fácil de leer. Y puedes ver que en la versión minificada, muchos de los nombres aún se mantienen porque todos estos métodos de clase no pueden ser minificados. Son parte de la API pública de esta clase API. Incluso cosas que consideramos privadas como encoded auth aún no se minimizan debido a cómo funciona JavaScript.

Entonces, ¿cuáles son algunas estrategias para que podamos escribir código más amigable con la minificación? Bueno, en primer lugar, intenta evitar búsquedas de objetos profundamente anidadas y patrones de constructor. A la izquierda aquí, puedes ver que tenemos esta búsqueda complicada en event.exception.values.type. Y queremos asegurarnos de que todo exista correctamente así que hacemos esta operación booleana. Pero todos estos valores, exception.values.type, y por supuesto el SentryError aquí, son completamente inminificables. Y así terminamos con mucha información redundante en nuestro paquete. Dado que ya estamos usando un try catch, podemos simplemente acortar esto a una sola línea. Y si encontramos un error de tipo, irá al bloque catch en su lugar.

Otra forma de escribir código más amigable con la minificación es usar config para modificar basado en regex. Entonces, por ejemplo, si volvemos al ejemplo de los métodos de clase aquí, si decimos, oye, todo lo que comience con el guion bajo debería ser minificado, ahora podemos minificar encoded auth y todos sus usos aquí. La mayoría de los empaquetadores tienen config que te permiten configurar modificaciones personalizadas basadas en alguna expresión regular. Por último, y aquí es donde entra el componente de diseño de la API, puedes usar funciones y objetos en lugar de clases. Y esto significa que las clases, por supuesto, tienen toda su API pública y cada método, método público, no puede ser minificado. Pero si usas funciones y objetos, los nombres de las funciones pueden ser minificados porque son simplemente métodos de nivel superior y todo lo que les importa es dónde se llaman y con qué se llaman. Incluso mejor que los objetos, porque, de nuevo, las claves de los objetos no pueden ser minificadas, es realmente usar arrays. Así que si tienes alguna estructura de datos interna que sabes que se usa comúnmente, entonces quizás hacer un array en lugar de un objeto. Los hooks de React realmente hacen esto muy bien. Cosas como useState y useReducer devuelven un array. Así que estos argumentos de array estructurados pueden ser realmente minificados por un empaquetador. Un gran ejemplo de comparar bibliotecas amigables con la minificación es Zod versus ValleyBot.

Entonces Zod es una biblioteca de validación de esquemas muy popular. ValleyBot es una especie de competidor para esto. Y puedes ver realmente los dos enfoques diferentes en el diseño de API. Para Zod, tienes este patrón de constructor donde puedes notar aquí que string, email, y endsWith están encadenados desde este zexport, y estos métodos encadenados no pueden ser minificados. Y así terminas con todos estos en tu paquete. Y si estás usando Zod mucho y está distribuido por todas partes, entonces eso se acumula con el tiempo. Mientras tanto, para ValleyBot, estas son solo funciones de nivel superior exportadas. Y por lo tanto, todas estas funciones, string, email, y endsWith en el ejemplo de ValleyBot serán minificadas. Requiere este tipo de cambio de diseño de API de nivel superior, pero de repente tienes una biblioteca mucho más amigable con la minificación, y con el tamaño del paquete.

A continuación, pensemos en la down-compilation. La down-compilation es un proceso de conversión de código fuente a una versión más compatible hacia atrás de ese código fuente. Desafortunadamente, el JavaScript más compatible hacia atrás puede ser más grande. Digamos que necesitas apuntar a IE11. Y así estás emitiendo JavaScript compatible con ES5. Esto significa que en realidad no hay clases porque ES5 aún no tenía clases. Esa es una característica de ES6. Y así podrías tener que polyfillearlas o down-compilarlas para tener JavaScript alternativo. Un gran ejemplo de esto es el encadenamiento opcional. Así que en la parte muy izquierda aquí, puedes ver la característica de encadenamiento opcional, que te permite hacer búsquedas profundamente anidadas en objetos. Pero si apuntas a algo más antiguo que ES2020, que es cuando salió el encadenamiento opcional, y quieres soportar más navegadores que eso, terminarás down-compilando tu JavaScript y tu encadenamiento opcional a algo que se ve así. Esto es súper costoso. Y puedes imaginar si usas mucho el encadenamiento opcional, especialmente si esto fuera una gran declaración anidada, tendrías un montón de condicionales aquí. En su lugar, especialmente si usas TypeScript, probablemente puedas simplemente reemplazar esto con una simple afirmación booleana, que es lo que hacemos en nuestro código base del Sentry SDK. De hecho, hacemos lint contra el uso de encadenamiento opcional y obligamos a todos a usar condiciones booleanas en su lugar. Así que lo más importante para esto es realmente mirar cómo se está generando tu JavaScript y asegurarte de que nada se vea extraño, nada se vea mal, y desautorizar patrones que no se down-compilan bien porque necesitas soportar más navegadores. Para los polyfills, porque a veces mucha gente simplemente comienza a inyectarlos innecesariamente, solo echa un vistazo y ve lo que estás empaquetando y actualiza tu lista de navegadores o usa empaquetadores modernos. Por favor, no uses más Webpack 4.

A continuación, tenemos la transpilation. Este es el proceso de convertir código fuente de un lenguaje a otro. Solíamos tener muchos de estos, CoffeeScript, BuckleScript, ReasonML, cosas así.

Pero hoy en día, esto prácticamente significa TypeScript y JavaScript para el desarrollador promedio de front-end. Por lo que vale, el transpiler de TypeScript es bastante bueno. Pero una cosa a tener en cuenta es que los enums de TypeScript son bastante costosos, y recomiendo no usarlos. A la izquierda, tenemos un enum. Parece bastante simple, pero a la derecha, podemos ver lo que esto genera. Y esto se debe a que los enums permiten búsquedas inversas. Esto es realmente costoso, y a menudo, los valores del enum no pueden ser minificados en absoluto, tampoco. Y así hay un doble problema allí. Es mucho más fácil simplemente no usarlos, usar constantes de cadena y hacer enums de esa manera. Las cadenas también tienen el beneficio de comprimirse muy bien.

La compresión es lo último de lo que podemos hablar aquí. El navegador descomprime automáticamente los activos JavaScript comprimidos, también CSS y otras fuentes, que están comprimidos con gzip, Brotli o deflate. Y por lo tanto, siempre deberías, junto con minificar tu código, comprimirlo para grandes ahorros mientras los usuarios tienen que cargar tus recursos a través de la red. Lo que termina sucediendo es, sin embargo, que las cadenas repetidas o el código se comprimen muy bien porque la similitud aumentada ayuda con los algoritmos de gzip y Brotli. Así que, por ejemplo aquí, si tuviéramos que cambiar este enum a constantes de cadena repetidas, eso realmente mejoraría su capacidad de gzip. gzip y los otros algoritmos de compresión, sin embargo, pueden ser un poco una caja negra. Es confuso. Y así, la mayor recomendación aquí es, mientras examinas tu paquete y tratas de arreglar tus polyfills, tu down compilation, y tus estrategias de minificación, prueba tus cambios contra lo que esté comprimido con gzip. Y si aún no lo estás haciendo, por favor comprime tu JavaScript antes de enviarlo a tus usuarios.

Así que cubrimos mucho terreno, pero hay mucho más que ver. Realmente la mejor manera de comenzar a explorar y comenzar a investigar es leer más JavaScript generado. Familiarízate con la lectura de código minificado y ve lo que realmente se emite desde tus procesos de construcción. A veces, si echas un vistazo, puedes encontrar algunas victorias rápidas realmente geniales. En general, sin embargo, por favor comienza a rastrear el tamaño de tu paquete. He estado en muchas conferencias diferentes hasta ahora y siempre hago esta pregunta. ¿Cuántos de ustedes están rastreando el tamaño de su paquete? Y la respuesta es decepcionantemente baja. Recomiendo usar CodeCub bundle size. Puedes rastrearlo a lo largo del tiempo. También te dará un comentario en el PR. Pero soy un poco parcial porque ayudé a construirlo.

Una gran alternativa es la acción de size limit. Esto es lo que usamos en el Sentry SDK. Dejará un comentario en el PR en GitHub que básicamente dice, oh, este era el tamaño del bundle anterior y este es el nuevo tamaño del bundle y esto es lo que ha cambiado. Si quieres profundizar y simplemente no quieres solo leer el JavaScript generado, entonces te recomiendo que uses analizadores de bundles para tus bundlers. Hay uno de Webpack, el de Rollup, que también funciona para Vite. Estas son formas realmente geniales de ver visualmente cómo tus bundles, qué hay en tu bundle y las conexiones entre diferentes componentes.