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

Rate this content
Bookmark

Google recopila información de rendimiento de todas las sesiones en navegadores Chrome que hayan optado por participar en su base de datos Chrome User Experience Report (CrUX). Luego utiliza esta información como factor de clasificación para su motor de búsqueda, pero también la pone a disposición del público para que todos la vean. Utilicé estos datos para analizar y comparar el rendimiento de los principales frameworks de JavaScript. En particular, examiné la probabilidad de que los sitios web construidos con cada framework tengan buenos puntajes de Core Web Vitals (CWV). En el camino, me encontré con varios resultados sorprendentes y resolví al menos un misterio. ¡Descubre cómo se clasifica tu framework favorito en comparación con todos los demás!

28 min
05 Jun, 2023

Video Summary and Transcription

La elección del framework afecta el rendimiento del sitio web. Se utilizan pruebas de laboratorio y datos de campo para medir el rendimiento. Los Core Web Vitals son métricas importantes para la evaluación del rendimiento. Están surgiendo nuevos frameworks que priorizan la velocidad. MetaFrameworks como QUIC, SolidStart, Astro y Nuxt muestran promesas en la mejora del rendimiento. Los frameworks de React como Gatsby y Remix tienen un buen rendimiento. Wix tiene un impacto significativo en el rendimiento de React. La elección del framework afecta significativamente la probabilidad de construir un sitio web rápido. Se necesita mejorar el rendimiento del framework.

Available in English

1. Introducción a la rendimiento web y los frameworks

Short description:

Hola a todos, en esta parte, discutiré cómo la elección del framework afecta el rendimiento de los sitios web y aplicaciones web. Utilizaré datos del mundo real para comparar el impacto en el rendimiento de los principales frameworks de JavaScript y meta-frameworks. Nuestra elección de framework puede tener un gran impacto en el rendimiento del sitio web. Con tantos frameworks y meta-frameworks disponibles, es importante elegir aquel que nos ayude a construir un sitio web rápido. Para determinar el mejor framework, necesitamos medir y compararlos. El primer método para medir el rendimiento son las pruebas de laboratorio.

afecta el rendimiento de los sitios web y aplicaciones web que construimos. Para hacer esto, utilizaré datos del mundo real para comparar el impacto en el rendimiento de los principales frameworks de JavaScript y meta-frameworks.

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.

2. Medición del rendimiento del sitio web

Short description:

La medición del rendimiento del sitio web se puede realizar mediante pruebas de laboratorio o la recopilación de datos en campo. Las pruebas de laboratorio brindan un control y visibilidad completos, pero pueden ser difíciles de configurar y replicar escenarios. Los datos en campo implican recopilar datos de rendimiento de sesiones reales de usuarios, lo que garantiza mediciones precisas. La base de datos de experiencia del usuario de Chrome (CRUX) de Google recopila datos de rendimiento de sesiones del navegador Chrome y los utiliza como señal de clasificación para los resultados del motor de búsqueda.

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.

3. Core Web Vitals and Performance Data

Short description:

La información principal de rendimiento almacenada en CRUX son las mediciones de Core Web Vitals. Hay tres métricas: Largest Contentful Paint (LCP), First Input Delay (FID) y Cumulative Layout Shift (CLS). Google define rangos para cada métrica, indicando un rendimiento bueno, que necesita mejorar y pobre. Además de utilizar los datos de CRUX como una señal de clasificación, Google proporciona acceso gratuito a ellos. El archivo HTTP y el servicio WAPLizr ayudan a recopilar datos de rendimiento para sitios web construidos con frameworks específicos. El Informe de Tecnología de Core Web Vitals, creado por Rick Viscomi, ofrece un panel interactivo para analizar los datos de rendimiento agregados. Sin embargo, la correlación no implica causalidad y otros factores pueden contribuir a los patrones de rendimiento.

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.

4. Impacto de los Frameworks en el Rendimiento Web

Short description:

Un nuevo framework que promueve la velocidad puede atraer a desarrolladores orientados al rendimiento. La mayoría de los sitios web no tienen un buen rendimiento, pero la situación está mejorando. WordPress representa una gran cantidad de sitios web, pero algo más está influyendo en el rendimiento general. Los principales frameworks no tienen un mejor rendimiento que WordPress. Los nuevos frameworks, como Qwik, se centran en el rendimiento pero tienen un uso limitado.

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.

5. Bug in Preact and Performance Analysis

Short description:

Hubo un error en cómo Apple ISR identificó el uso de Preact, lo que hace que los datos anteriores a noviembre de 2021 sean irrelevantes. Svelte parece tener un rendimiento deficiente en comparación con otros frameworks, lo que plantea preguntas sobre correlación versus causalidad. El rendimiento del framework puede verse influenciado por la velocidad de Internet y las capacidades del dispositivo en diferentes países. Al limitar el análisis a Estados Unidos, Svelt tiene un buen rendimiento. Al filtrar los 100.000 principales sitios web, se observan variaciones en el rendimiento, con una disminución significativa en React. Para comprender estos resultados, se examinará el rendimiento de los MetaFrameworks.

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.

6. MetaFrameworks and their Performance

Short description:

Los MetaFrameworks como QUIC, SolidStart, Astro y Nuxt muestran promesa en la mejora del rendimiento de los sitios web. QUIC y SolidStart tienen un número reducido de sitios web construidos con ellos, pero sus creadores están trabajando en mejoras de rendimiento. Astro ha ganado cierto uso, mientras que Nuxt ha mostrado una mejora significativa en los últimos dos años.

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.

7. React Frameworks and Wix Impact

Short description:

Ahora, centrémonos en los frameworks de React. Gatsby y Remix tienen un buen rendimiento, siendo Gatsby el que tiene un mayor número de sitios web. Sorprendentemente, Next.js tiene un rendimiento peor que React, a pesar de sus optimizaciones de rendimiento. Wix, aunque no es un meta-framework de React, tiene un mejor rendimiento que los otros frameworks y tiene un impacto significativo en el rendimiento general de React. Cuando filtramos los 100.000 principales sitios web, el impacto de Wix disminuye y el rendimiento de React se alinea con View y Preact.

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.

8. Framework Performance and Impact

Short description:

Crux es un recurso valioso que proporciona acceso a datos de rendimiento. Cualquier framework puede usarse para construir un sitio web rápido o lento. La elección del framework o meta-framework tiene un impacto significativo en la probabilidad de construir un sitio web rápido y el esfuerzo requerido. Desafortunadamente, los principales frameworks a menudo tienen un rendimiento peor que la web en general. Necesitamos mejorar y los nuevos frameworks y mejoras pueden cambiar la situación. Gracias por asistir a mi charla sobre la comparación del rendimiento de los frameworks.

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.

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 Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
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.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
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
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

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 🤐)
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 Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
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
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
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 🤐)
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion