Comparando el Rendimiento de los Frameworks de JavaScript Utilizando Datos del Mundo Real

Hola a todos, espero que estén disfrutando de la conferencia JS Nation. Hoy voy a hablar sobre el rendimiento web, y específicamente sobre cómo su elección de framework impacta en el rendimiento de los sitios web y las aplicaciones web que construyen. Para hacer esto, estaré utilizando datos del mundo real para comparar el impacto en el rendimiento de los principales marcos de trabajo y meta-marcos de trabajo de JavaScript.

Pero primero, unas palabras sobre mí. Mi nombre es Dan Shapir, y soy el Líder Técnico de Rendimiento en Next Insurance. Somos un unicornio InsurTech que busca revolucionar la forma en que las pequeñas empresas obtienen seguros. Y como todo se hace en línea, es crítico que el rendimiento sea lo más rápido posible. También soy anfitrión y panelista en el popular podcast semanal JavaScript Jabber. Soy un experto invitado en el Grupo de Trabajo de Rendimiento Web del W3C donde se discuten y estandarizan las métricas de rendimiento que describiré hoy. Si quieres contactarme sobre rendimiento web o desarrollo web en general, eres bienvenido a hacerlo en Twitter o Masterdon.

Hablando de rendimiento web, todos sabemos que construir sitios web rápidos puede ser difícil. Y no es solo difícil para ti o para mí, es difícil para todos. Y esa es la razón por la que, según Google, la mayoría de los sitios web que indexa no tienen un buen rendimiento. Por esta razón, cuando seleccionamos qué herramientas usar para construir sitios web, queremos elegir herramientas que nos preparen para el éxito en rendimiento. Ciertamente, no queremos elegir herramientas que nos preparen para fallar. Y probablemente la herramienta más importante que elegimos como desarrolladores web, el elemento más impactante en nuestro arsenal, es el marco de trabajo que usamos. La razón de esto es que cuando construimos un sitio web, es el marco de trabajo el que está en el asiento del conductor. Nuestro code está sentado en la parte de atrás, diciéndole al marco de trabajo a dónde ir y esperando que nos lleve allí. Es el marco de trabajo el que decide dónde y cuándo ejecutar nuestro code, qué parámetros y estado pasar a nuestro code, qué hacer con los valores que nuestro code le proporciona, cuándo actualizar la pantalla, cómo manejar las interacciones del usuario, etc. Por lo tanto, realmente no es sorprendente que nuestra elección de marco de trabajo pueda tener un gran impacto en el rendimiento de los sitios web que construimos con él.

Afortunadamente, en estos días tenemos muchas opciones cuando se trata de decidir qué marco de trabajo usar. De hecho, parece que se introduce un nuevo marco de trabajo casi a diario. Y lo que es más, una motivación principal para la creación de nuevos marcos de trabajo es a menudo el rendimiento web. Su objetivo es permitirnos construir sitios web más rápidos, de manera más fácil y consistente. Además, hay un montón de meta-marcos de trabajo implementados en la parte superior de estos marcos de trabajo. Por ejemplo, si quieres construir sitios web usando React, puedes hacerlo con Next.js o Emix o Gatsby o Astro y otros. Entonces la pregunta es, ¿qué marco de trabajo o meta-marco de trabajo deberíamos elegir? La respuesta a eso es que, con todo lo demás siendo igual, deberíamos preferir usar el marco de trabajo que es más probable que nos ayude a producir un sitio web rápido. Pero, ¿cómo podemos saber cuál es ese marco de trabajo? La respuesta a eso es que necesitamos medirlos y compararlos. Hay dos métodos principales para medir el rendimiento en la web. El primer método se conoce como pruebas de laboratorio.

Esto significa medir el rendimiento del sitio web en un entorno controlado. Idealmente, debería replicar los entornos en los que los usuarios reales acceden a nuestro sitio web. La principal ventaja de usar este método es que proporciona un control total sobre las pruebas y una visibilidad completa de los resultados. Podemos inspeccionar cada faceta y comportamiento de nuestro code y recrearlo según sea necesario.

Pero las pruebas de laboratorio también son difíciles de realizar porque configurar el entorno del laboratorio puede ser un desafío, y determinar exactamente qué escenarios deberíamos replicar también puede ser difícil. Las pruebas de laboratorio son especialmente problemáticas cuando queremos comparar el rendimiento de los diversos frameworks porque necesitamos construir exactamente las mismas aplicaciones utilizando cada framework que queremos probar. Hay algunas herramientas que pueden ayudarnos a automatizar este proceso, pero aún puede ser necesario un tiempo y esfuerzo significativos.

El otro enfoque que podemos tomar es usar datos de campo. Eso significa recoger datos de rendimiento de sesiones reales de usuarios reales, preferiblemente tantos como sea posible. Las mediciones de usuarios aleatorios, o RUM por sus siglas en inglés, se trata de obtener datos de rendimiento de sesiones en vivo y usar esos datos para las comparaciones. De esta manera, podemos estar seguros de que lo que medimos realmente refleja lo que nuestros usuarios están experimentando. Pero, ¿cómo podemos acceder a los datos de rendimiento de todas esas sesiones? ¿Es posible instrumentar cada sitio web construido utilizando cualquier framework para que informe los datos de rendimiento de cada sesión, y luego recoger estos datos en algún tipo de base de datos para que podamos generar comparaciones?

Obviamente, no podemos hacer algo así. Pero resulta que alguien puede, y ese alguien es Google. Eso es porque en lugar de instrumentar los sitios web, instrumentaron la plataforma en la que se ejecutan estos sitios web, el propio navegador Chrome. A menos que opte por no participar, el navegador Chrome recopila información de rendimiento sobre cada sesión de cada sitio web que visita y la envía a la base de datos de Google en la nube. Esta base de datos es la Base de Datos de Experiencia de Usuario de Chrome, o CRUX por sus siglas en inglés. Google utiliza toda esta información de rendimiento que recopila como una señal de clasificación para su motor de búsqueda. Eso significa que cuando Google decide cómo ordenar los resultados en la página de resultados del motor de búsqueda da un impulso de clasificación a las páginas que tienen un mejor rendimiento según estos datos.

La información de performance principal que se almacena en CRUX son las mediciones de Core Web Vitals para cada visita a cada página. Supongo que muchos de ustedes ya están familiarizados con los Core Web Vitals, así que haré esta descripción breve. Hay tres métricas de Core Web Vitals. La primera es Largest Contentful Paint, también conocida como LCP. Mide el tiempo que transcurre desde el inicio de la navegación hasta una página hasta que se muestra su contenido más grande. First Input Delay, o FID para abreviar, mide el tiempo desde la primera interacción del usuario con una página hasta que la página puede responder a esa interacción. Y Community Layout Shift, o CLS, mide cuánto se desplaza el contenido en una página por sí mismo, no en respuesta a alguna interacción del usuario.

Para cada una de estas métricas, Google ha definido rangos, que especifican mediciones como buenas o verdes, necesitan mejora o amarillas, y pobres o rojas. Por ejemplo, para LCP, bueno significa cualquier medición inferior a 2.5 segundos, necesita mejora es cualquier cosa desde 2.5 segundos hasta 4 segundos, y cualquier cosa por encima de 4 segundos se considera pobre. Una sesión se considera de buen rendimiento si todas sus métricas son verdes, lo que significa que estas tres métricas medidas para ella están en el rango bueno.

Además de usar los data en Crux como una señal de clasificación, Google también nos proporciona, y por eso quiero decir a todos, acceso gratuito a estos data. Por ejemplo, en la console de búsqueda de Google, hay un panel que muestra los data de rendimiento de Crux para todas las páginas de un sitio web. De esta manera podemos saber en qué páginas necesitamos enfocarnos en términos de rendimiento. Del mismo modo, podemos usar el servicio Google PageSpeed Insights para obtener los data de rendimiento de Crux para cualquier URL además de algunos resultados sintéticos. Pero en este caso, lo que queremos hacer es algo diferente. Queremos agregar los data de rendimiento para todos los sitios web construidos con un framework específico.

¿Cómo podemos hacer algo así? Afortunadamente, Crux tiene algunos amigos que pueden ayudarlo a proporcionarnos esta información. El amigo número uno es el archivo HTTP. Cada vez que se agrega una URL a Crux, también se entrega al archivo HTTP, que realiza una colección de pruebas en él, extrayendo un montón de información sobre cómo esta página está construida y cómo opera. En particular, una de las herramientas que utiliza el archivo HTTP es un servicio llamado WAPLizr. Este servicio examina la página y determina qué tecnologías web están siendo utilizadas por ella, en particular qué frameworks y meta-frameworks usa o en los que se basa. Toda esta información se guarda en la database junto con los data de Crux. Esto nos permite realizar consultas y extraer, por ejemplo, los data de rendimiento agregados para todos los sitios web construidos usando React.

Pero para hacernos la vida aún más fácil, este increíble tipo que trabaja en Google, Rick Viscomi, creó algo llamado el Informe de Tecnología de Core Web Vitals, que es un panel interactivo que realiza las consultas por nosotros y luego grafica los data. Este panel está abierto a todos y es gratuito para usar, y puedes usarlo para graficar el rendimiento agregado para todos los sitios web que utilizan cualquier tecnología identificada por WebAnalyzer. Y esta es exactamente la herramienta que utilicé para analizar los data para esta presentación.

Pero antes de finalmente mirar estos data, hay un punto importante que debo hacer. Siempre debemos recordar que la correlación no es lo mismo que la causalidad. En nuestro caso, significa que cuando vemos un patrón de rendimiento particular para un framework, no significa que por definición es el framework en sí el que es la causa principal de este patrón. Por ejemplo, un framework líder que tiene muchos sitios web implementados con él es probable que tenga una larga cola de sitios web que todavía están usando versiones antiguas y no están siendo actualizados o optimizados.

A la inversa, un nuevo framework que promueve la velocidad probablemente atraerá a desarrolladores orientados al rendimiento que optimizarán al máximo los relativamente pocos sitios web que construyeron utilizando este. Dicho esto, a pesar de la diferencia entre correlación y causalidad, no volvería a usar Internet Explorer. Y del mismo modo, todo lo demás siendo igual, tendería a preferir un framework que tenga un mejor perfil de performance, suponiendo que no soy realmente mucho mejor que todos los otros desarrolladores web que están utilizando esos frameworks.

Bueno, entonces, habiendo dicho todo eso, finalmente entremos en los data. En este primer gráfico vemos dos líneas. La línea más oscura representa la proporción de sitios web con buen rendimiento de todos los sitios web en la base de datos de CrUX que utilizan cualquier tecnología. ¿Recuerdas cómo dije que la mayoría de los sitios web no tienen un buen rendimiento? Bueno, ahora podemos verlo claramente. Solo aproximadamente el 40% de todos los sitios web tienen un buen rendimiento según los Core Web Vitals. El resto no. Al menos podemos ver que la situación está mejorando y el gráfico está en tendencia ascendente. También puse los data para WordPress en el gráfico, la línea azul más clara, porque los sitios de WordPress representan aproximadamente un tercio de todos los sitios web. Mucho más que cualquier framework. De hecho, más que todos los frameworks combinados. Podemos ver una fuerte correlación entre WordPress y todos los sitios en general, pero WordPress es notablemente más bajo, lo que significa que algo más está elevando la línea general. ¿Qué crees que es? ¿Son los frameworks? Lo veremos.

Una cosa más, todos los gráficos que estoy mostrando son para móviles. Hice esto porque vivimos en un mundo móvil primero y la mayoría de las sesiones web son en móviles y también los móviles suelen ser más desafiantes en términos de rendimiento. Entonces, finalmente, aquí están los resultados para los principales frameworks. Y cuando digo los principales frameworks, no estoy haciendo un juicio de valor. Simplemente estoy mirando los frameworks que tienen el mayor número de sitios web construidos utilizando ellos en la base de datos de crux. Como podemos ver claramente, no son los frameworks los que están mejorando el rendimiento de la web. De todos los principales frameworks, solo React y Preact tienen un rendimiento mejor que WordPress. Y todos ellos tienen un rendimiento peor que la web en general. Pero sabemos que se han introducido un montón de nuevos frameworks en los últimos años, y que estos frameworks a menudo se centran en el rendimiento. Veamos también esos. Qwik es un nuevo framework que se centra especialmente en el rendimiento, pero parece estar en todas partes. Y no es que se haya vuelto realmente bueno, y luego realmente malo, y luego realmente bueno de nuevo. Es solo que todavía hay muy pocos sitios web que se construyen utilizando Qwik, porque es tan nuevo. El número es tan bajo, de hecho, que apenas es estadísticamente significativo, pero parece que se dirige en una buena dirección. También podrías estar preguntándote sobre el bache en los datos de Preact.

No es que Preact empezó rápido y luego se volvió más lento. Más bien, hubo un error en cómo Apple ISR identificó el uso de Preact en los sitios web. Como resultado, los datos para Preact anteriores a noviembre de 2021, cuando se corrigió ese error, son irrelevantes y deben ser ignorados.

Otra cosa que es bastante sorprendente es lo mal que parece estar funcionando Svelte en comparación con los otros frameworks. Sabemos que Svelte se supone que es realmente bueno en términos de rendimiento, pero parece ser peor que los demás. Y eso nos lleva de nuevo a la cuestión de la correlación frente a la causalidad, y cuán cuidadosos necesitamos ser al sacar conclusiones de estos datos.

Los datos que estamos viendo son para todo el mundo, y como sabemos, algunos países tienen internet mucho más lento que otros. Del mismo modo, en algunos países, los dispositivos móviles lentos son más comunes que en otros. Es muy posible que cuando se desarrollan sitios web para su uso en dichos países, las personas se inclinen hacia frameworks que son más ligeros. Y al hacerlo, en realidad afectan negativamente la puntuación global de estos frameworks, haciéndolos parecer más lentos de lo que realmente son.

Para comprobar si este es realmente el caso para Svelt, podemos limitar el gráfico a una ubicación geográfica específica. Elegí los Estados Unidos simplemente porque tiene la mayor cantidad de sesiones en Crux. De hecho, ahora vemos que Svelt salta a la cima, por encima de todos los frameworks líderes, y solo un poco peor que la web en general. React sigue en una buena posición, y sorprendentemente, por encima de Preact, que se supone que es una alternativa más ligera. Veremos por qué podría ser así más adelante.

Otro filtro interesante que podemos aplicar es que en lugar de mirar todos los sitios web en crux, podemos mirar los 100k sitios web principales en términos de tráfico. Eso significa filtrar los sitios web menos populares. ¿Por qué es esto interesante? Bueno, porque podemos suponer que los sitios web más exitosos pueden permitirse los mejores desarrolladores, y también pueden permitirse invertir más en su infraestructura, y su caché CDN es más probable que esté caliente y preparada. Dado todo eso, podemos suponer que los sitios web más importantes probablemente tendrán un mejor rendimiento. ¿Es realmente así? Así que aquí estamos mirando los 100k sitios web principales, pero no espero que recuerdes los números, así que simplemente los compararemos lado a lado. WordPress de hecho sube un 18%, lo que parece corroborar mis suposiciones. Angular también sube y por un significativo 22%, lo que demuestra que aparentemente necesitas ser un experto para construir sitios web rápidos usando Angular. Pero su proporción sigue siendo bastante mala. Vue es esencialmente lo mismo, lo que parece indicar que realmente no necesitas ser un experto para sacar tanto de Vue como probablemente vayas a obtener. Y lo mismo ocurre con Preact. Sorprendentemente, Svelte baja un 8%, y realmente no sé por qué es así. Pero aún más significativamente, React baja un impresionante 16%, lo que parece indicar que cuanto mejor desarrollador de React seas, peor serás en términos de rendimiento. Algo sorprendente. Para tratar de entender estos resultados sorprendentes, decidí mirar el rendimiento de los MetaFrameworks, ya que así es como se suelen usar los frameworks hoy en día.

Además, los MetaFrameworks están especialmente destinados a mejorar el performance. Por ejemplo, al habilitar la renderización en el lado del servidor, conocida como SSR, y la generación en el lado estático, conocida como SSG.

Primero, veamos los MetaFrameworks en general en los Estados Unidos. Debido a cómo funciona, estoy contando a QUIC como un MetaFramework también. Y porque estoy filtrando por los Estados Unidos, el número de sitios web construidos usando QUIC es aún menor. De hecho, son solo 8, lo que significa que es realmente prematuro hablar de ello, pero de nuevo, parece prometedor.

Lo mismo ocurre con SolidStart, que solo tiene 9 sitios web construidos con él. Está menos enfocado en el performance que QUIC, pero Ryan Corneato, el creador de Solid, está haciendo algunas cosas muy interesantes. De nuevo, el tiempo lo dirá. Astro es otro recién llegado que muestra promesa. Tiene un poco más de uso con 186 sitios web, pero aún son los primeros días. En la parte inferior tenemos a Nuxt, ligeramente por debajo de Next.js. Lo bueno que puedo decir de él es que en los últimos dos años, ha mejorado en más del triple. Eso es mucho, pero todavía tiene un largo camino por recorrer.

Ahora, centrémonos en los frameworks de React. He eliminado la antigua línea de tiempo y WordPress, y en su lugar he añadido React en sí mismo para referencia. Tanto Gatsby como Remix están funcionando bien, y están por encima de la línea agregada de React. Basándonos en lo que hemos visto antes, la forma en que Remix fluctúa indica que hay sólo unos pocos sitios web que lo utilizan, y eso es efectivamente el caso con 254. Gatsby coincide con el rendimiento de Remix, pero tiene muchos más sitios web, alrededor de 5,000.

Una cosa que es sorprendente es que Next.js tiene un rendimiento peor que React en general. Es sorprendente porque, como mencioné antes, al igual que otros meta-frameworks, Next.js habilita SSR, que se supone que mejora el rendimiento, y también tiene algunas otras optimizaciones de rendimiento, por ejemplo, para imágenes. Dado que Next.js es ahora el 8% de todos los sitios web de React, esto es realmente desafortunado. Por el lado positivo, parece que está mejorando y sabemos que está haciendo cosas adicionales para mejorar el rendimiento en el futuro, así que hay esperanza.

También puede sorprenderte por qué incluí a Wix en este gráfico. Después de todo, Wix no es un meta-framework de React. ¿O sí? Resulta que en cierto modo lo es. Por cierto, para aquellos de ustedes que no saben qué es Wix, es una popular herramienta de arrastrar y soltar Y solía trabajar allí antes de ir a Next Insurance. Y la razón por la que es una especie de meta-framework de React es que Wix utiliza React para mostrar los sitios web construidos con él. Así que cada sitio web de Wix es también un sitio web de React, y así es como es identificado por crux. Y resulta que Wix tiene un rendimiento mucho mejor que todos estos meta-frameworks de React. Interesante. Así que, resulta que las personas que arrastran y sueltan su camino hacia un sitio web están obteniendo un mejor rendimiento que los sitios web personalizados construidos manualmente con React o uno de estos meta-frameworks. Piensa en eso.

Además, resulta que casi el 20% de todos los sitios web de React son en realidad sitios web de Wix. Mucho más que cualquier meta-framework de React. Como resultado, Wix tiene un impacto significativo en el rendimiento general de React. De hecho, parece que Wix está elevando a React. Así que la razón por la que React tiene un mejor rendimiento agregado que todos los otros frameworks principales es porque Wix está construido con él. Cuando cambio el filtro para ver sólo los 100K sitios web más importantes, podemos ver que la cantidad de sitios web de Wix disminuye significativamente. Esto se debe a que Wix se centra en las pequeñas empresas. En consecuencia, Wix tiene muy poco impacto en React en este escenario. Esto explica por qué vimos una gran caída en el rendimiento de React del 16% cuando miramos los sitios más importantes, porque al hacerlo sacamos a Wix de la ecuación. Esto significa que los números que vemos para React en ese escenario, que están a la par con View y Preact, son mucho más representativos de ese framework cuando es utilizado por desarrolladores web usando MetaFramework o manualmente en lugar de por Wix. Así que, para resumir las cosas.

En primer lugar, Crux es una gran fuente de información. Creo que todos podemos estar de acuerdo en eso. Claro, podemos tener diversos sentimientos acerca del hecho de que Google está recopilando tanta información sobre nosotros y nuestras sesiones, pero el hecho de que también nos proporciona acceso a esta información es muy útil.

La segunda cosa es que, aunque vimos que la buena proporción de performance de algunos sitios web era bastante baja, ninguno de ellos tenía una proporción de cero. Esto significa que puedes construir un sitio web rápido utilizando cualquier framework, incluso Angular. Por el contrario, vimos que ningún framework tiene una buena proporción de performance del 100%, lo que significa que puedes construir un sitio web lento utilizando cualquier framework, incluso Quick.

Pero habiendo dicho eso, vimos que hay diferencias en las buenas proporciones de performance entre los diversos frameworks y meta-frameworks. Esto significa que la probabilidad de que construyas un sitio web rápido varía entre ellos, dependiendo de qué framework y meta-framework elijas utilizar. Tu elección de un framework o meta-framework puede tener, de hecho, un impacto significativo en la probabilidad de que construyas un sitio web rápido y la cantidad de conocimientos y esfuerzo que se requerirá para hacerlo.

También vimos que, desafortunadamente, los principales frameworks tienen peor performance que la web en general. ¿Así que todos esos grandes sitios web que estamos construyendo usando React o Vue o lo que sea? Bueno, ¿adivina qué? Muchos de ellos están haciendo la web más lenta y peor. Y eso, si tienes un vecino que no sabe nada sobre web development y está usando Wix para arrastrar y soltar su camino hacia un sitio web funcional, ese sitio web que tu vecino construye probablemente será más rápido que si tú construyes el mismo sitio web usando tu framework favorito. De nuevo, piensa en eso.

Esto significa que definitivamente necesitamos hacerlo mejor, porque actualmente para la mayoría de los desarrolladores web los frameworks y metaframeworks no están entregando éxito en performance, al menos no para la mayoría de ellos. Realmente espero que los nuevos frameworks que están saliendo y las mejoras que están introduciendo los principales frameworks cambien esta desafortunada situación. El tiempo lo dirá.

Gracias por asistir a mi masterclass sobre la comparación del performance de los framework utilizando datos del mundo real. Si quieres contactarme acerca de esta presentación, acerca de estos data, o acerca del performance web en general, por favor hazlo en Twitter o Mastodon donde mi nombre de usuario es Dan Shapir. Gracias y adiós.