Comparación del rendimiento de los frameworks de JavaScript utilizando datos del mundo real

Pero antes, 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 tiene como objetivo revolucionar la forma en que las pequeñas empresas obtienen seguros. Y como todo se hace en línea, es fundamental 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, puedes hacerlo en Twitter o Masterdon.

Hablando de rendimiento web, todos sabemos que construir sitios web rápidos puede ser difícil. Y no solo es 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 cuanto al rendimiento. Ciertamente, no queremos elegir herramientas que nos preparen para el fracaso. Y probablemente la herramienta más importante que elegimos como desarrolladores web, el elemento más impactante en nuestro arsenal, es el framework que usamos. La razón de esto es que cuando construimos un sitio web, es el framework el que está al mando. Nuestro código está en la parte de atrás, diciéndole al framework a dónde ir y esperando que nos lleve allí. Es el framework el que decide dónde y cuándo ejecutar nuestro código, qué parámetros y estado pasar a nuestro código, qué hacer con los valores que nuestro código le proporciona, cuándo actualizar la visualización, cómo manejar las interacciones del usuario, etc. Por lo tanto, no es sorprendente que nuestra elección de framework 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é framework usar. De hecho, parece que se introduce un nuevo framework casi a diario. Y además, una motivación principal para la creación de nuevos frameworks 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-frameworks implementados sobre estos frameworks. 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é framework o meta-framework deberíamos elegir? La respuesta a eso es que, con todo lo demás siendo igual, deberíamos preferir usar el framework que tenga más probabilidades de ayudarnos a producir un sitio web rápido. Pero, ¿cómo podemos saber qué framework es ese? 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 utilizar este método es que proporciona un control total sobre las pruebas y una visibilidad completa de los resultados. Podemos inspeccionar cada aspecto y comportamiento de nuestro código y recrearlo según sea necesario.

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

El otro enfoque que podemos tomar es utilizar datos en campo. Eso significa recopilar datos de rendimiento de sesiones reales de usuarios, preferiblemente tantas como sea posible. Las mediciones de usuarios aleatorios, o RUM por sus siglas en inglés, consisten en obtener datos de rendimiento de sesiones en vivo y utilizar 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 con cualquier framework para que informe los datos de rendimiento de cada sesión y luego recopilar estos datos en algún tipo de base de datos para generar comparaciones?

Obviamente, no podemos hacer algo así. Pero resulta que alguien puede hacerlo, y ese alguien es Google. Eso se debe a que en lugar de instrumentar los sitios web, ellos instrumentaron la plataforma en la que se ejecutan estos sitios web, el propio navegador Chrome. A menos que optes por no hacerlo, el navegador Chrome recopila información de rendimiento sobre cada sesión de cada sitio web que visitas 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 del Usuario de Chrome, o CRUX. 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, otorga un impulso de clasificación a las páginas que tienen un mejor rendimiento según estos datos.

La información principal de rendimiento 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 que se muestra el contenido más grande de la página. First Input Delay, o FID, mide el tiempo desde la primera interacción del usuario con la página hasta que la página puede responder a esa interacción. Y Cumulative Layout Shift, o CLS, mide cuánto se desplaza el contenido en una página por sí mismo, sin respuesta a alguna interacción del usuario.

Para cada una de estas métricas, Google ha definido rangos que especifican si las mediciones son buenas o verdes, si necesitan mejorar o amarillas y si son pobres o rojas. Por ejemplo, para LCP, bueno significa cualquier medición por debajo de 2.5 segundos, necesita mejorar es cualquier cosa entre 2.5 segundos y 4 segundos, y cualquier cosa por encima de 4 segundos se considera pobre. Una sesión se considera que tiene un rendimiento bueno si todas sus métricas están en verde, lo que significa que las tres métricas medidas para ella están dentro del rango bueno.

Además de utilizar los datos en CRUX como una señal de clasificación, Google también nos proporciona, y cuando digo a todos, me refiero a todos, acceso gratuito a estos datos. Por ejemplo, en la Consola de Búsqueda de Google, hay un panel que muestra los datos de rendimiento de CRUX para todas las páginas de un sitio web. De esta manera, podemos saber en qué páginas debemos enfocarnos en términos de rendimiento. Del mismo modo, podemos utilizar el servicio Google PageSpeed Insights para obtener los datos 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 recopilar los datos 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 ayudarnos a proporcionar 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 serie de pruebas en ella, extrayendo una gran cantidad de información sobre cómo se construye y opera esta página. 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 se están utilizando en ella, en particular qué frameworks y meta-frameworks se utilizan o se construyen en ella. Toda esta información se guarda en la base de datos junto con los datos de CRUX. Esto nos permite realizar consultas y extraer, por ejemplo, los datos de rendimiento agregados para todos los sitios web construidos con React.

Pero para facilitarnos aún más la vida, este increíble tipo que trabaja en Google, Rick Viscomi, creó algo llamado Informe de Tecnología de Core Web Vitals, que es un panel interactivo que realiza las consultas por nosotros y luego grafica los datos. Este panel está abierto para todos y es gratuito, y se puede utilizar 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 datos para esta presentación.

Pero antes de ver finalmente estos datos, hay un punto importante que debo mencionar. Siempre debemos recordar que la correlación no es lo mismo que la causalidad. En nuestro caso, esto significa que cuando vemos un patrón de rendimiento particular para un framework, no significa que por definición sea el framework en sí mismo la causa principal de este patrón. Por ejemplo, un framework líder que tiene muchos sitios web implementados con él probablemente tendrá una larga lista de sitios web que aún utilizan versiones antiguas y no se están actualizando ni optimizando.

Por el contrario, es probable que un nuevo framework que promueva la velocidad atraiga a desarrolladores orientados al rendimiento que optimizarán al máximo los relativamente pocos sitios web que construyan utilizando dicho framework. Dicho esto, a pesar de la diferencia entre correlación y causalidad, no volvería a usar Internet Explorer. Y de la misma manera, si todo lo demás es igual, tiendo a preferir un framework que tenga un mejor perfil de rendimiento, asumiendo que no soy mucho mejor que todos los demás desarrolladores web que utilizan esos frameworks.

Bien, dicho esto, finalmente vamos a ver los datos. 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. ¿Recuerdan 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 lo tiene. Al menos podemos ver que la situación está mejorando y el gráfico muestra una tendencia al alza. También agregué los datos de 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 está notablemente más bajo, lo que significa que algo más está impulsando la línea general hacia arriba. ¿Qué creen que es? ¿Son los frameworks? Lo veremos.

Una cosa más, todos los gráficos que estoy mostrando son para dispositivos móviles. Hice esto porque vivimos en un mundo centrado en los dispositivos móviles y la mayoría de las sesiones web se realizan en dispositivos móviles, y además, los dispositivos móviles suelen ser más desafiantes en términos de rendimiento. Entonces, aquí finalmente 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 la mayor cantidad de sitios web construidos con ellos en la base de datos de CrUX. Como podemos ver claramente, no son los frameworks los que están impulsando el rendimiento de la web hacia arriba. De todos los principales frameworks, solo React y Preact tienen un mejor rendimiento que WordPress. Y todos ellos tienen un rendimiento deficiente en comparación con la web en general. Pero sabemos que se han introducido muchos 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 enfoca especialmente en el rendimiento, pero parece estar en todas partes. Y no es que haya tenido un rendimiento realmente bueno, y luego realmente malo, y luego realmente bueno de nuevo. Es solo que todavía hay muy pocos sitios web construidos con Qwik, porque es tan nuevo. El número es tan bajo, de hecho, que apenas es estadísticamente significativo, pero parece que va en una buena dirección. También podrían preguntarse sobre la curva en los datos de Preact.

No es que Preact haya comenzado rápido y luego se haya vuelto 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 de Preact anteriores a noviembre de 2021, cuando se corrigió ese error, son irrelevantes y deben ignorarse.

Otra cosa sorprendente es lo mal que parece estar haciendo Svelte en comparación con los otros frameworks. Sabemos que se supone que Svelte es muy bueno en términos de rendimiento, pero parece ser peor que los demás. Y esto nos lleva nuevamente al tema de la correlación versus causalidad, y lo cuidadosos que debemos ser al sacar conclusiones de estos datos.

Los datos que estamos viendo son para todo el mundo, y como sabemos, algunos países tienen una conexión a Internet mucho más lenta 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 al desarrollar sitios web para usar en dichos países, las personas se inclinen hacia frameworks más livianos. Al hacerlo, afectan negativamente la puntuación global de estos frameworks, lo que hace que parezcan más lentos de lo que realmente son.

Para comprobar si esto es realmente cierto para Svelt, podemos limitar el gráfico a una ubicación geográfica específica. Elegí Estados Unidos simplemente porque tiene la mayor cantidad de sesiones en Crux. De hecho, ahora vemos que Svelt se sitúa en la parte superior, por encima de todos los principales frameworks, y solo ligeramente peor que la web en general. React se mantiene en una buena posición y sorprendentemente, por encima de Preact, que se supone que es una alternativa más liviana. Veremos por qué podría ser más adelante.

Otro filtro interesante que podemos aplicar es, en lugar de mirar todos los sitios web en Crux, mirar los 100.000 principales sitios web en términos de tráfico. Esto significa filtrar los sitios web menos populares. ¿Por qué es interesante esto? 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 es más probable que su caché de CDN esté caliente y preparada. Dado todo eso, podemos suponer que los sitios web principales probablemente tendrán un mejor rendimiento. ¿Es realmente así? Así que aquí estamos mirando los 100.000 principales sitios web, pero no espero que recuerden los números, así que simplemente comparemos lado a lado. WordPress ha aumentado un 18%, lo que parece corroborar mis suposiciones. Angular también ha aumentado significativamente un 22%, lo que demuestra que aparentemente necesitas ser un experto para construir sitios web rápidos con Angular. Pero su proporción sigue siendo bastante mala. Vue es prácticamente el mismo, lo que parece indicar que realmente no necesitas ser un experto para obtener todo lo que puedes de Vue. Y lo mismo ocurre con Preact. Sorprendentemente, Svelte ha disminuido un 8%, y realmente no sé por qué. Pero lo que es aún más significativo, React ha disminuido un asombroso 16%, lo que parece indicar que cuanto mejor desarrollador de React eres, peor eres en términos de rendimiento. Bastante sorprendente. Para tratar de entender estos resultados sorprendentes, decidí analizar el rendimiento de los MetaFrameworks, ya que así es como se utilizan los frameworks en estos días.

Además, los MetaFrameworks están especialmente diseñados para mejorar el rendimiento. Por ejemplo, al habilitar el renderizado del lado del servidor, conocido como SSR, y la generación estática del lado del servidor, conocida como SSG.

Primero, veamos los MetaFrameworks en general en los Estados Unidos. Debido a cómo funciona, también estoy considerando a QUIC como un MetaFramework. Y debido a que estoy filtrando para los Estados Unidos, el número de sitios web construidos con QUIC es aún menor. De hecho, son solo 8, lo que significa que es demasiado pronto para hablar de ello, pero nuevamente, parece prometedor.

Lo mismo ocurre con SolidStart, que solo tiene 9 sitios web construidos con él. No se centra tanto en el rendimiento como QUIC, pero Ryan Corneato, el creador de Solid, está haciendo cosas muy interesantes. Nuevamente, 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 es temprano. En la parte inferior tenemos a Nuxt, ligeramente por debajo de Next.js. Lo bueno que puedo decir es que en los últimos dos años ha mejorado en más de tres veces. Eso es mucho, pero aún 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í como referencia. Tanto Gatsby como Remix tienen un buen rendimiento y están por encima de la línea agregada de React. Según lo que hemos visto antes, la forma en que Remix fluctúa indica que hay muy pocos sitios web que lo utilizan, y ese es el caso en 254. Gatsby tiene un rendimiento similar a Remix, pero tiene muchos más sitios web, alrededor de 5.000.

Una cosa 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 permite el 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 ahora representa el 8% de todos los sitios web de React, esto es realmente desafortunado. En 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.

Tal vez te sorprenda por qué incluí a Wix en este gráfico. Después de todo, Wix no es un meta-framework de React. ¿O sí lo es? Resulta que sí lo es. Por cierto, para aquellos que no saben qué es Wix, es una popular plataforma de creación de sitios web mediante arrastrar y soltar, y solía trabajar allí antes de ir a Next Insurance. 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. Por lo tanto, cada sitio web de Wix también es un sitio web de React, y así es como se identifica en 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 obtienen un mejor rendimiento que los sitios web personalizados construidos manualmente con React o uno de estos meta-frameworks. Solo piénsalo.

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á impulsando a React hacia arriba. Por lo tanto, la razón por la que React tiene un mejor rendimiento agregado que todos los demás principales frameworks es porque Wix está construido con él. Cuando cambio el filtro para ver solo los 100.000 principales sitios web, podemos ver que la cantidad de sitios web de Wix disminuye significativamente. Esto se debe a que Wix se centra en pequeñas empresas. En consecuencia, Wix tiene muy poco impacto en React en este escenario. Esto explica por qué vimos una caída tan grande en el rendimiento de React del 16% cuando miramos los sitios principales, 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 que utilizan MetaFramework o manualmente en lugar de por Wix. En resumen.

En primer lugar, Crux es un gran recurso de información. Creo que todos podemos estar de acuerdo en eso. Claro, podemos tener diferentes opiniones sobre el hecho de que Google esté recopilando tanta información sobre nosotros y nuestras sesiones, pero el hecho de que también nos proporcione acceso a esta información es muy útil.

Lo segundo es que, aunque vimos que la buena relación de rendimiento de algunos sitios web era bastante baja, ninguno de ellos tenía una relació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 relación de rendimiento del 100%, lo que significa que puedes construir un sitio web lento utilizando cualquier framework, incluso Quick.

Pero dicho esto, vimos que hay diferencias en las relaciones de buen rendimiento 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 del framework y meta-framework que elijas usar. Tu elección de 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 un rendimiento peor que la web en general. Entonces, ¿todos esos sitios web geniales que estamos construyendo con React o Vue o lo que sea? Bueno, ¿adivina qué? Muchos de ellos en realidad están haciendo que la web sea más lenta y peor. Y eso, si tienes un vecino que no sabe nada sobre desarrollo web y está utilizando Wix para arrastrar y soltar su camino hacia un sitio web funcional, es probable que el sitio web que construya tu vecino sea más rápido que si lo construyes utilizando el mismo sitio web con tu framework favorito. Nuevamente, piénsalo.

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

Gracias por asistir a mi charla sobre la comparación del rendimiento de los frameworks utilizando datos del mundo real. Si deseas contactarme sobre esta presentación, sobre estos datos o sobre el rendimiento web en general, por favor hazlo en Twitter o Mastodon, donde mi usuario es Dan Shapir. Gracias y adiós.