🥛 ◽️ 🍎 El precio de los marcos de JavaScript 👨🏽‍🏭 🌪️ 🤹🏾

No hay una forma más rápida de ralentizar un sitio (como un juego de palabras) que usar un montón de código JavaScript en él. Al usar JavaScript, debe pagar por esto con el rendimiento del proyecto al menos cuatro veces. Así es como el código JavaScript del sitio carga los sistemas de usuario:

Descargue un archivo a través de la red.
Analizar y compilar el código fuente desempaquetado después de la carga.
Ejecución de código JavaScript.
Consumo de memoria.

Esta combinación es muy costosa . Y estamos incluyendo más y más código JS en nuestros proyectos. A medida que las organizaciones se mueven hacia sitios basados en marcos y bibliotecas como React, Vue y otros, hacemos que la funcionalidad principal de los sitios dependa mucho de JavaScript.

Vi muchos sitios muy pesados usando frameworks de JavaScript. Pero mi visión del tema es muy parcial. El hecho es que las empresas con las que trabajo me contactan precisamente porque encuentran problemas complejos en el campo del rendimiento del sitio web. Como resultado, sentí curiosidad por saber qué tan extendido es este problema y qué tipo de "multas" pagamos cuando seleccionamos uno u otro marco como base para un determinado sitio.

El proyecto HTTP Archive me ayudó a resolver esto .

Datos

El proyecto HTTP Archive, en total, rastrea 4,308,655 enlaces a sitios regulares dedicados a dispositivos de escritorio, y 5,484,239 enlaces a sitios móviles. Entre los muchos indicadores asociados con estos enlaces, hay una lista de tecnologías que se encuentran en los sitios respectivos. Esto significa que podemos crear una muestra de miles de sitios que usan varios marcos y bibliotecas, y descubrir cuánto código envían a los clientes y cuánta carga crean los sistemas de los usuarios.

Recopilé datos para marzo de 2020, estos fueron los últimos datos a los que tuve acceso.

Decidí comparar los datos agregados del Archivo HTTP para todos los sitios con los datos de los sitios donde se detectaron React, Vue y Angular, aunque estaba considerando usar otro material fuente.

Para hacerlo más interesante, también agregué sitios que usan jQuery al conjunto de datos de origen. Esta biblioteca sigue siendo muy popular. También proporciona un enfoque de desarrollo de sitios web que difiere del modelo de aplicación de página única (SPA) propuesto por React, Vue y Angular.

Enlaces en el Archivo HTTP que representan sitios que han descubierto el uso de tecnologías de interés para nosotros.

Marco o biblioteca	Enlaces a sitios móviles	Enlaces a sitios regulares
jQuery	4615474	3714643
Reaccionar	489827	241023
Vue	85649	43691
Angular	19423	18088

Esperanzas y sueños

Antes de pasar al análisis de datos, quiero hablar sobre lo que me gustaría esperar.

Creo que en un mundo ideal, los marcos deberían ir más allá de satisfacer las necesidades de los desarrolladores y dar ciertas ventajas concretas a los usuarios comunes que trabajan con nuestros sitios. El rendimiento es solo uno de estos beneficios. Aquí, la accesibilidad y la seguridad todavía vienen a la mente. Pero esto es solo lo más importante.

Por lo tanto, en un mundo ideal, un determinado marco debería facilitar la creación de un sitio de alto rendimiento. Esto debe hacerse debido al hecho de que el marco le da al desarrollador una base decente sobre la cual construir el proyecto, o debido al hecho de que impone restricciones en el desarrollo, plantea requisitos que complican el desarrollo de algo que resulta lento.

Los mejores marcos deberían hacer ambas cosas: dar una buena base e imponer restricciones en el trabajo, lo que permite lograr un resultado decente.

El análisis de los valores medios de los datos no nos dará la información necesaria. Y, de hecho, este enfoque deja mucho más allá de nuestra atención . En cambio, deduje de mis indicadores de datos expresados en percentiles. Esto es 10, 25, 50 (mediana), 75, 90 percentiles.

Estoy particularmente interesado en los percentiles 10 y 90. El décimo percentil representa el mejor rendimiento (o al menos más o menos cercano al mejor) para un marco en particular. En otras palabras, esto significa que solo el 10% de los sitios que usan un marco particular alcanzan esto, o a un nivel superior. El percentil 90, por otro lado, es la otra cara de la moneda: nos muestra lo malas que pueden ser las cosas. El percentil 90 corresponde a los sitios de tejido: esos últimos 10% de los sitios que se caracterizan por los mayores volúmenes de código JS o el tiempo más largo requerido para procesar su código en la transmisión principal.

Volúmenes de código JavaScript

Para empezar, tiene sentido analizar el tamaño del código JavaScript transmitido por diferentes sitios a través de la red.

La cantidad de código JavaScript (Kb) transferido a dispositivos móviles

	10	25	50	75	90
	93.4	196.6	413.5	746.8	1201.6
jQuery-	110.3	219.8	430.4	748.6	1162.3
Vue-	244.7	409.3	692.1	1065.5	1570.7
Angular-	445.1	675.6	1066.4	1761.5	2893.2
React-	345.8	441.6	690.3	1238.5	1893.6

JavaScript-,

JavaScript- (),

	10	25	50	75	90
	105.5	226.6	450.4	808.8	1267.3
jQuery-	121.7	242.2	458.3	803.4	1235.3
Vue-	248.0	420.1	718.0	1122.5	1643.1
Angular-	468.8	716.9	1144.2	1930.0	3283.1
React-	308.6	469.0	841.9	1472.2	2197.8

La cantidad de código JavaScript transmitido a los dispositivos de escritorio

Si hablamos solo del tamaño del código JS enviado por los sitios a los dispositivos, entonces todo se ve como es de esperar. Es decir, si se usa uno de los marcos, esto significa que incluso en una situación ideal, aumentará el volumen del código JavaScript del sitio. Esto no es sorprendente: no puede hacer que el marco de JavaScript sea la base del sitio y esperar que el volumen del código JS del proyecto sea muy bajo.

Es de destacar en estos datos que algunos marcos y bibliotecas pueden considerarse un punto de partida más exitoso del proyecto que otros. Los sitios de JQuery se ven mejor. En las versiones de escritorio de los sitios, contienen un 15% más de JavaScript que todos los sitios, y en las versiones móviles, un 18% más. (Debo admitir que aquí puede observar cierta distorsión de los datos. El hecho es que jQuery está presente en muchos sitios, por lo que es natural que dichos sitios estén más cerca que otros del número total de sitios. Sin embargo, esto no afecta la forma los datos de origen se muestran para cada marco).

Aunque un aumento del 15-18% en el código es una cifra significativa, comparándolo con otros marcos y bibliotecas, podemos concluir que el "impuesto" cobrado por jQuery es muy bajo. Los sitios en el Angular del percentil 10 envían un 344% más de datos a los dispositivos de escritorio que todos los sitios, y a los móviles, un 377% más. Los sitios de reacción, los siguientes en términos de gravedad, envían un 193% más de código a los dispositivos de escritorio que todos los sitios, y un 270% más a los dispositivos móviles.

Ya he mencionado que, aunque el uso del marco significa que se incluirá una cierta cantidad de código en el proyecto, al comienzo del trabajo en él, espero que el marco pueda de alguna manera limitar al desarrollador. En particular, estamos hablando de limitar la cantidad máxima de código.

Curiosamente, los sitios jQuery siguen esta idea. Aunque, en el nivel del percentil 10, son ligeramente más pesados que todos los sitios (15-18%), en el nivel del percentil 90, son un poco más ligeros que todos, aproximadamente un 3% en las versiones de escritorio y móviles. No se puede decir que esto sea un beneficio muy significativo, pero se puede decir que los sitios jQuery al menos no difieren en el gran tamaño del código JavaScript, incluso en sus versiones más grandes.

Pero no se puede decir lo mismo de otros marcos.

Al igual que con el percentil 10, los sitios del percentil 90 en Angular y React son diferentes de otros sitios, pero desafortunadamente difieren para peor.

En el percentil 90, los sitios angulares envían 141% más datos a dispositivos móviles que todos los sitios, y 159% más a computadoras de escritorio. Los sitios de reacción envían un 73% más a dispositivos de escritorio que todos los sitios, y un 58% más a dispositivos móviles. El tamaño del código de los sitios React en el percentil 90 es 2197.8 Kb. Esto significa que dichos sitios envían 322.9 Kb más datos a dispositivos móviles que sus competidores más cercanos basados en Vue. La brecha entre los sitios de escritorio basados en Angular y React, y entre otros sitios, es aún mayor. Por ejemplo, los sitios de escritorio React envían 554.7 KB más de código JS a dispositivos que los sitios Vue similares.

Tiempo empleado procesando código JavaScript en el hilo principal

Los datos anteriores indican claramente que los sitios que usan los marcos y bibliotecas estudiados contienen grandes cantidades de código JavaScript. Pero, por supuesto, esto es solo una parte de nuestra ecuación.

Una vez que el código JavaScript ha llegado al navegador, debe ponerse en funcionamiento. Especialmente muchos problemas son causados por aquellas acciones que tienen que llevarse a cabo con el código en la secuencia principal del navegador. El hilo principal es responsable de procesar las acciones del usuario, calcular los estilos, crear y mostrar el diseño de la página. Si llena la secuencia principal con asuntos de JavaScript, no podrá resolver otras tareas a tiempo. Esto lleva a retrasos y "frenos" en el trabajo de las páginas.

La base de datos del Archivo HTTP contiene información sobre cuánto tiempo lleva procesar el código JavaScript en el hilo principal del motor V8. Esto significa que podemos recopilar estos datos y averiguar cuánto tiempo tarda el hilo principal en procesar el JavaScript de varios sitios.

Tiempo de CPU (en milisegundos) relacionado con el procesamiento de scripts en dispositivos móviles

Percentiles	10	25	cincuenta	75	90
Todos los sitios	356,4	959,7	2372,1	5367,3	10485.8
sitios jQuery	575,3	1147,4	2555,9	5511,0	10349,4
Sitios Vue	1130.0	2087,9	4100,4	7676,1	12849,4
Sitios angulares	1471,3	2380,1	4118,6	7450.8	13296,4
Sitios de reacción	2700,1	5090,3	9287,6	14509,6	20813.3

Tiempo de CPU relacionado con el procesamiento de script en dispositivos móviles Tiempo de

CPU (en milisegundos) relacionado con el procesamiento de script en dispositivos de escritorio

Percentiles	10	25	cincuenta	75	90
Todos los sitios	146,0	351,8	831,0	1739,8	3236,8
sitios jQuery	199,6	399,2	877,5	1779,9	3215.5
Vue-	350.4	650.8	1280.7	2388.5	4010.8
Angular-	482.2	777.9	1365.5	2400.6	4171.8
React-	508.0	1045.6	2121.1	4235.1	7444.3

Tiempo de CPU relacionado con el procesamiento de scripts en dispositivos de escritorio

Aquí puede ver algo muy familiar.

Para empezar, los sitios con jQuery gastan significativamente menos en procesamiento de JavaScript en el hilo principal que otros. En el percentil 10, en comparación con todos los sitios, los sitios jQuery en dispositivos móviles pasan un 61% más de tiempo procesando el código JS en el hilo principal. En el caso de los sitios jQuery de escritorio, el tiempo de procesamiento aumenta en un 37%. En el nivel del percentil 90, las métricas del sitio jQuery están muy cerca de las métricas agregadas. Es decir, los sitios jQuery en dispositivos móviles pasan un 1,3% menos de tiempo en la transmisión principal que todos los sitios, y en dispositivos de escritorio, un 0,7% menos de tiempo.

En el otro lado de nuestra calificación, hay marcos que se caracterizan por la mayor carga en el hilo principal. Esto, de nuevo, es angular y reaccionar. La única diferencia entre ellos es que, aunque los sitios angulares envían una mayor cantidad de código a los navegadores que los sitios React, se necesita menos tiempo del procesador para procesar el código de los sitios angulares. Mucho menos.

En el décimo percentil, los sitios angulares de escritorio gastan un 230% más de tiempo de subproceso principal procesando código JS que todos los sitios. Para los sitios móviles, esta cifra es del 313%. Los sitios de reacción tienen el peor rendimiento. En los dispositivos de escritorio, pasan un 248% más de tiempo en el procesamiento de código que todos los sitios, y en dispositivos móviles, un 658% más. 658% no es un error tipográfico. En el percentil 10, los sitios de React dedican 2.7 segundos del tiempo de subproceso principal para procesar el código que tienen.

El percentil 90, en comparación con estos enormes números, se ve al menos un poco mejor. Los proyectos angulares, en comparación con todos los sitios, pasan un 29% más de tiempo en dispositivos de escritorio en el hilo principal y un 27% más en dispositivos móviles. En el caso de los sitios React, los indicadores similares se ven, respectivamente, como 130% y 98%.

Las desviaciones porcentuales para el percentil 90 se ven mejor que valores similares para el percentil 10. Pero aquí vale la pena recordar que los números que indican la hora parecen bastante aterradores. Digamos: 20.8 segundos en la transmisión principal de un dispositivo móvil para un sitio construido en React. (Creo que la historia de lo que realmente sucede durante este tiempo es digna de un artículo separado).

Hay una dificultad potencial (graciasJeremy por llamar mi atención sobre esta característica y por considerar cuidadosamente los datos desde este punto de vista). El hecho es que muchos sitios usan varias herramientas de front-end. En particular, he visto muchos sitios que usan jQuery junto con React o Vue, ya que estos sitios migran de jQuery a otros marcos o bibliotecas. Como resultado, volví a recurrir a la base de datos, eligiendo esta vez solo aquellos enlaces que corresponden a sitios que usan solo React, jQuery, Angular o Vue, pero no alguna combinación de ellos. Eso fue lo que hice.

Tiempo de CPU (en milisegundos) relacionado con el procesamiento de scripts en dispositivos móviles en una situación en la que los sitios usan solo un marco o una sola biblioteca

Percentiles	10	25	cincuenta	75	90
, jQuery	542.9	1062.2	2297.4	4769.7	8718.2
, Vue	944.0	1716.3	3194.7	5959.6	9843.8
, Angular	1328.9	2151.9	3695.3	6629.3	11607.7
, React	2443.2	4620.5	10061.4	17074.3	24956.3

Tiempo de CPU relacionado con el procesamiento de scripts en dispositivos móviles en una situación en la que solo se usa un marco en sitios, o solo una biblioteca

Al principio, no es sorprendente: cuando solo se usa un marco o una biblioteca en un sitio, el rendimiento de dicho sitio es más frecuente mejorando que no mejorando. Los indicadores para cada instrumento se ven mejor en los percentiles 10 y 25. Que tiene sentido. Un sitio creado con un marco debería ser más productivo que un sitio creado con dos o más marcos o bibliotecas.

De hecho, los indicadores para cada instrumento front-end estudiado se ven mejor en todos los casos, menos una curiosa excepción. Me sorprendió que en el nivel del percentil 50 y superior, los sitios que usan React tienen un rendimiento peor si React es la única biblioteca utilizada en ellos. Esto, por cierto, fue la razón por la que traje aquí estos datos.

Esto es un poco extraño, pero aún trato de buscar una explicación de esta rareza.

Si un proyecto usa React y jQuery, entonces es muy probable que este proyecto esté a la mitad de la transición de jQuery a React. Quizás tiene una base de código en la que se mezclan estas bibliotecas. Como ya hemos visto que los sitios jQuery pasan menos tiempo en el hilo principal que los sitios React, esto puede decirnos que implementar alguna funcionalidad en jQuery ayuda a mejorar ligeramente el rendimiento del sitio.

Pero a medida que el proyecto, que pasa de jQuery a React, se basa más en React, la situación cambia. Si el sitio tiene una calidad realmente alta, y los desarrolladores del sitio usan React con prudencia, entonces con este sitio todo estará bien. Pero para el sitio de React promedio, el uso generalizado de React significa que el hilo principal está bajo una carga mayor.

La brecha entre dispositivos móviles y de escritorio

Otro punto de vista desde el que miré los datos en estudio fue estudiar qué tan grande es la brecha entre trabajar con sitios en dispositivos móviles y de escritorio. Si hablamos de comparar los volúmenes de código JavaScript, esa comparación no revela nada terrible. Por supuesto, sería bueno ver pequeñas cantidades de código descargado, pero no hay mucha diferencia en los volúmenes de código móvil y de escritorio.

Pero si analiza el tiempo requerido para procesar el código, notará una brecha muy grande entre los dispositivos móviles y de escritorio.

El aumento en el tiempo (en porcentaje) relacionado con el procesamiento de scripts en dispositivos móviles en comparación con el escritorio

Percentiles	10	25	cincuenta	75	90
Todos los sitios	144,1	172,8	185,5	208,5	224,0
sitios jQuery	188,2	187,4	191,3	209,6	221,9
Sitios Vue	222,5	220,8	220,2	221,4	220,4
Sitios angulares	205,1	206,0	201,6	210,4	218,7
Sitios de reacción	431,5	386,8	337,9	242,6	179,6

Aunque es bastante esperada alguna diferencia en la velocidad de procesamiento del código entre el teléfono y la computadora portátil, un número tan grande me dice que los marcos modernos no están suficientemente enfocados en dispositivos de baja potencia y en el deseo de cerrar la brecha. Incluso en el percentil 10, los sitios de React pasan un 431.5% más de tiempo en la transmisión principal de dispositivos móviles que en la transmisión principal de dispositivos de escritorio. La brecha más pequeña se observa en jQuery, pero incluso aquí el indicador correspondiente es 188.2%. Cuando los desarrolladores de sitios web realizan sus proyectos para que los procesadores tarden más tiempo (y esto sucede, y con el tiempo todo empeora), los propietarios de dispositivos de baja potencia tienen que pagar por ello.

Resumen

Los buenos marcos deberían proporcionar a los desarrolladores una base de alta calidad para crear proyectos web (en términos de seguridad, accesibilidad, rendimiento), o deberían tener restricciones incorporadas que dificulten la creación de algo que viole estas restricciones.

Esto no parece aplicarse al desempeño de los proyectos web (y, aparentemente, a su disponibilidad ).

Vale la pena señalar que el hecho de que los sitios React o Angular gasten más tiempo de CPU en la preparación del código que otros no significa necesariamente que los sitios React en el curso del trabajo carguen el procesador más que los sitios Vue. De hecho, los datos que hemos revisado dicen muy poco sobre el rendimiento de los marcos y las bibliotecas. Hablan más sobre enfoques de desarrollo a los que, conscientemente o no, estos marcos pueden impulsar a los programadores. Estamos hablando de documentación para marcos, sobre su ecosistema, sobre técnicas comunes de desarrollo.

Vale la pena mencionar que no lo analizamos aquí, es decir, cuánto tiempo pasa el dispositivo ejecutando el código JavaScript al navegar entre las páginas del sitio. El argumento a favor de SPA es que tan pronto como se carga una aplicación de una página en el navegador, el usuario, en teoría, podrá abrir las páginas del sitio más rápido. Mi propia experiencia me dice que esto está lejos de ser un hecho. Pero no tenemos datos para aclarar este problema.

Solo está claro que si utiliza un marco o biblioteca para crear un sitio, se compromete en términos de carga inicial del proyecto y preparación para el trabajo. Esto se aplica incluso a los escenarios más positivos.

En situaciones apropiadas, es bastante posible hacer algunos compromisos, pero es importante que los desarrolladores hagan compromisos conscientes.

Pero tenemos razones para ser optimistas. Me alienta cuán estrechamente interactúan los desarrolladores de Chrome con algunas de las herramientas front-end que hemos revisado en un esfuerzo por ayudar a mejorar el rendimiento de estas herramientas.

Sin embargo, soy una persona pragmática. Las arquitecturas nuevas a menudo crean problemas de rendimiento a medida que los resuelven. Y lleva tiempo solucionar los defectos. Así como no deberíamos esperar que las nuevas tecnologías de red resuelvan todos los problemas de rendimiento, tampoco deberíamos esperar esto de las nuevas versiones de nuestros marcos favoritos.

Si desea utilizar una de las herramientas de front-end tratadas en este material, esto significa que tendrá que hacer esfuerzos adicionales para asegurarse de que, mientras tanto, no perjudique la productividad de su proyecto. Aquí hay algunas consideraciones a tener en cuenta antes de comenzar a usar el nuevo marco:

Ponte a prueba en términos de sentido común. ¿Realmente necesitas usar el marco elegido? Pure JavaScript es capaz de hacer mucho en la actualidad.
¿Existe una alternativa más fácil al marco elegido (como Preact, Svelte u otra cosa) que pueda brindarle el 90% de las capacidades de este marco?
Si ya está utilizando algún tipo de marco, piense si hay algo que ofrezca opciones estándar mejores y más conservadoras (por ejemplo, Nuxt.js en lugar de Vue, Next.js en lugar de React, etc.).
¿Cuál será su presupuesto de rendimiento de JavaScript?
¿Cómo puede limitar el proceso de desarrollo para complicar la implementación de una mayor cantidad de código JavaScript en el proyecto de lo que es absolutamente necesario?
Si usa el marco para la conveniencia del desarrollo, considere si necesita enviar el código del marco a sus clientes. ¿Quizás puedas resolver todos los problemas en el servidor?

Por lo general, vale la pena echar un vistazo a estas ideas, independientemente de lo que haya elegido exactamente para desarrollar la interfaz. Pero son especialmente importantes cuando está trabajando en un proyecto que, desde el principio, carece de productividad.

¡Queridos lectores! ¿Cómo ves el marco JavaScript perfecto?