No hay una forma más rápida de ralentizar un sitio web (juego de palabras) que usar un montón de código JavaScript en él. Al usar JavaScript, debe pagarlo con el rendimiento de los proyectos no menos de cuatro veces. Así es como el código JavaScript del sitio carga los sistemas de los usuarios:
- Descarga de un archivo a través de la red.
- Análisis y compilación del código fuente desempaquetado después de la descarga.
- Ejecución de código JavaScript.
- Consumo de memoria.
Esta combinación resulta .
E incluimos cada vez más código JS en nuestros proyectos. A medida que las organizaciones avanzan hacia sitios impulsados por marcos y bibliotecas como React, Vue y otros, estamos haciendo que la funcionalidad central de los sitios dependa en gran medida de JavaScript.
He visto muchos sitios muy pesados que usan marcos de JavaScript. Pero mi visión del tema es muy sesgada. El hecho es que las empresas con las que trabajo recurren a mí precisamente porque se enfrentan a problemas complejos en el campo del rendimiento del sitio. Como resultado, me dio curiosidad saber qué tan común es este problema y qué tipo de "penalizaciones" pagamos cuando elegimos uno u otro marco como base para un sitio determinado.
El proyecto me ayudó a resolver esto. .
Datos
El proyecto HTTP Archive rastrea un total de 4308655 5484239 XNUMX enlaces a sitios de escritorio regulares y XNUMX XNUMX XNUMX enlaces a sitios móviles. Entre las muchas métricas asociadas con estos enlaces hay una lista de tecnologías que se encuentran en los sitios respectivos. Esto significa que podemos probar miles de sitios que usan varios marcos y bibliotecas y aprender cuánto código envían a los clientes y cuánta carga crea este código en los sistemas de los usuarios.
Recopilé datos de marzo de 2020, que fueron los datos más recientes a los que tuve acceso.
Decidí comparar los datos agregados del Archivo HTTP en todos los sitios con los datos de sitios encontrados usando React, Vue y Angular, aunque también consideré usar otro material de origen.
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 presenta un enfoque diferente para el desarrollo web que el modelo de aplicación de página única (SPA) ofrecido por React, Vue y Angular.
Enlaces en el Archivo HTTP que representan sitios que se ha encontrado que usan tecnologías de interés
Marco o biblioteca
Enlaces a sitios móviles
Enlaces a sitios regulares
jQuery
4615474
3714643
Reaccionar
489827
241023
Vista
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 brindar algún beneficio específico al usuario promedio que trabaja con nuestros sitios. El rendimiento es solo uno de esos beneficios. Aquí es donde entran en juego la accesibilidad y la seguridad. Pero esto es sólo lo más importante.
Entonces, en un mundo ideal, algún tipo de marco debería facilitar la creación de un sitio de alto rendimiento. Esto debe hacerse debido al hecho de que el marco le brinda al desarrollador una base decente sobre la cual construir un proyecto, o debido al hecho de que impone restricciones al desarrollo, presenta requisitos que complican el desarrollo de algo que se vuelve fuera a ser lento.
Los mejores marcos deben hacer ambas cosas: dar una buena base e imponer restricciones en el trabajo, permitiéndole lograr un resultado decente.
Analizar los valores medianos de los datos no nos dará la información que necesitamos. Y, de hecho, este enfoque deja fuera de nuestra atención . En cambio, derivé porcentajes de los datos que tenía. Estos son percentiles 10, 25, 50 (mediana), 75, 90.
Estoy especialmente interesado en los percentiles 10 y 90. El percentil 10 representa el mejor rendimiento (o al menos más o menos cerca del mejor) para un marco en particular. En otras palabras, esto significa que solo el 10 % de los sitios que utilizan un marco en particular llegan a este nivel o a uno superior. El percentil 90, por otro lado, es la otra cara de la moneda: nos muestra lo mal que pueden ponerse las cosas. El percentil 90 son los sitios que se quedan atrás: el 10% inferior de los sitios que tienen la mayor cantidad de código JS o el tiempo más largo para procesar su código en el hilo 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
percentiles
10
25
50
75
90
Todos los sitios
93.4
196.6
413.5
746.8
1201.6
sitios jQuery
110.3
219.8
430.4
748.6
1162.3
sitios vue
244.7
409.3
692.1
1065.5
1570.7
sitios angulares
445.1
675.6
1066.4
1761.5
2893.2
Sitios de reacción
345.8
441.6
690.3
1238.5
1893.6
Cantidad de código JavaScript enviado a dispositivos móviles
Cantidad de código JavaScript (Kb) transferido a dispositivos de escritorio
percentiles
10
25
50
75
90
Todos los sitios
105.5
226.6
450.4
808.8
1267.3
sitios jQuery
121.7
242.2
458.3
803.4
1235.3
sitios vue
248.0
420.1
718.0
1122.5
1643.1
sitios angulares
468.8
716.9
1144.2
1930.0
3283.1
Sitios de reacción
308.6
469.0
841.9
1472.2
2197.8
Cantidad de código JavaScript enviado a dispositivos de escritorio
Si solo hablamos del tamaño del código JS que los sitios envían a los dispositivos, entonces todo se ve como cabría esperar. Es decir, si se utiliza 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 un marco de JavaScript sea la base de un sitio y esperar que el volumen del código JS del proyecto sea muy bajo.
Lo notable de estos datos es que algunos marcos y bibliotecas pueden considerarse un mejor punto de partida para un proyecto que otros. Los sitios con 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 los dispositivos móviles contienen un 18 % más. (Es cierto que hay algo de corrupción de datos aquí. El hecho es que jQuery está presente en muchos sitios, por lo que es natural que dichos sitios estén más estrechamente asociados que otros con el número total de sitios. Sin embargo, esto no afecta cómo raw se emiten datos para cada marco).
Si bien el aumento del 15 al 18 % en el volumen del código es una cifra notable, al compararlo con otros marcos y bibliotecas, se puede concluir que el "impuesto" recaudado por jQuery es muy bajo. Los sitios angulares en el percentil 10 envían un 344 % más de datos al escritorio que todos los sitios y un 377 % más a los dispositivos móviles. Los sitios de React son los siguientes más pesados, ya que envían un 193 % más de código al escritorio que todos los sitios y un 270 % más a los dispositivos móviles.
Anteriormente, mencioné que aunque usar un 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 limitar de alguna manera al desarrollador. En particular, estamos hablando de limitar la cantidad máxima de código.
Curiosamente, los sitios jQuery siguen esta idea. Si bien son un poco más pesados que todos los sitios en el percentil 10 (entre un 15 y un 18 %), son un poco más livianos en el percentil 90 con alrededor del 3 % tanto en computadoras de escritorio como en dispositivos móviles. Esto no quiere decir que este sea un beneficio muy significativo, pero se puede decir que los sitios jQuery, al menos, no tienen códigos de JavaScript de gran tamaño, incluso en sus versiones más grandes.
Pero no se puede decir lo mismo de otros marcos.
Al igual que en el caso del percentil 10, en el percentil 90 los sitios en Angular y React difieren de otros sitios, pero difieren, desafortunadamente, para peor.
En el percentil 90, los sitios de Angular envían un 141 % más de datos a dispositivos móviles que todos los sitios y un 159 % más a computadoras de escritorio. Los sitios de React envían un 73 % más al escritorio que todos los sitios y un 58 % más a los dispositivos móviles. El tamaño del código de los sitios de React en el percentil 90 es de 2197.8 KB. Esto significa que dichos sitios envían 322.9 KB más de datos a dispositivos móviles que sus competidores más cercanos según Vue. La brecha entre los sitios de escritorio basados en Angular y React y otros sitios es aún mayor. Por ejemplo, los sitios React de escritorio envían 554.7 KB más de código JS a los dispositivos que los sitios Vue equivalentes.
Tiempo necesario para procesar el código JavaScript en el hilo principal
Los datos anteriores indican claramente que los sitios que utilizan los marcos y bibliotecas bajo estudio contienen grandes cantidades de código JavaScript. Pero, por supuesto, eso es solo una parte de nuestra ecuación.
Una vez que el código JavaScript ha llegado al navegador, debe ponerse en un estado funcional. Especialmente, muchos problemas son causados por aquellas acciones que deben llevarse a cabo con el código en el hilo principal del navegador. El subproceso principal es responsable de procesar las acciones del usuario, calcular estilos, construir y mostrar el diseño de la página. Si abruma el hilo principal con tareas de JavaScript, no tendrá la oportunidad de completar el resto de las tareas a tiempo. Esto conduce a retrasos y "frenos" en el trabajo de las páginas.
La base de datos de HTTP Archive tiene información sobre cuánto tiempo lleva procesar el código JavaScript en el subproceso 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 procesador (en milisegundos) relacionado con el procesamiento de scripts en dispositivos móviles
percentiles
10
25
50
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 procesador relacionado con el procesamiento de scripts en dispositivos móviles
Tiempo del procesador (en milisegundos) relacionado con el procesamiento de scripts en dispositivos de escritorio
percentiles
10
25
50
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
sitios vue
350.4
650.8
1280.7
2388.5
4010.8
sitios angulares
482.2
777.9
1365.5
2400.6
4171.8
Sitios de reacción
508.0
1045.6
2121.1
4235.1
7444.3
Tiempo de procesador relacionado con el procesamiento de scripts en dispositivos de escritorio
Aquí se puede ver algo muy familiar.
Para empezar, los sitios con jQuery gastan significativamente menos en el procesamiento de JavaScript en el hilo principal que otros sitios. En el percentil 10, en comparación con todos los sitios, los sitios jQuery en dispositivos móviles dedican un 61 % más de tiempo a procesar el código JS en el subproceso principal. En el caso de los sitios jQuery de escritorio, el tiempo de procesamiento aumenta en un 37%. En el percentil 90, los sitios jQuery obtienen una puntuación muy cercana a las puntuaciones totales. Específicamente, los sitios jQuery en dispositivos móviles pasan un 1.3 % menos de tiempo en el hilo principal que todos los sitios y un 0.7 % menos en dispositivos de escritorio.
En el otro lado de nuestra calificación están los marcos que se caracterizan por la mayor carga en el hilo principal. Esto es, nuevamente, Angular y React. La única diferencia entre los dos es que, mientras que los sitios de Angular envían más código a los navegadores que los sitios de React, los sitios de Angular requieren menos tiempo de CPU para procesar el código. Mucho menos.
En el percentil 10, los sitios Angular de escritorio pasan un 230 % más de tiempo en el procesamiento del código JS del subproceso principal que todos los sitios. Para los sitios móviles, esta cifra es del 313%. Los sitios de reacción son los de peor desempeño. En el escritorio, dedican un 248 % más de tiempo a procesar código que todos los sitios y un 658 % más en dispositivos móviles. 658% no es un error tipográfico. En el percentil 10, los sitios de React dedican 2.7 segundos del tiempo del subproceso principal a procesar su código.
El percentil 90, en comparación con estos números enormes, se ve al menos un poco mejor. En comparación con todos los sitios, los proyectos de Angular pasan un 29 % más de tiempo en dispositivos de escritorio en el hilo principal y un 27 % más de tiempo en dispositivos móviles. En el caso de los sitios React, las mismas cifras parecen 130% y 98%, respectivamente.
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 el hilo móvil principal de un sitio web creado con React. (Creo que la historia de lo que realmente sucede durante este tiempo es digna de un artículo aparte).
Hay una complicación potencial aquí (gracias 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 utilizan varias herramientas de front-end. En particular, he visto muchos sitios que usan jQuery junto con React o Vue, ya que esos sitios están migrando de jQuery a otros marcos o bibliotecas. Como resultado, accedí a la base de datos nuevamente, esta vez seleccionando solo aquellos enlaces que corresponden a sitios que usan solo React, jQuery, Angular o Vue, pero no una combinación de ellos. Esto es lo que tengo.
Tiempo de procesador (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 biblioteca
percentiles
10
25
50
75
90
Sitios que solo usan jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Sitios que solo usan Vue
944.0
1716.3
3194.7
5959.6
9843.8
Sitios que solo usan Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Sitios que solo usan React
2443.2
4620.5
10061.4
17074.3
24956.3
Tiempo de procesador relacionado con el procesamiento de scripts en dispositivos móviles en una situación en la que los sitios usan solo un marco o solo una biblioteca
Primero, algo que no es sorprendente: cuando un sitio usa solo un marco o una biblioteca, el rendimiento de dicho sitio mejora la mayoría de las veces. Cada instrumento funciona mejor en los percentiles 10 y 25. Que tiene sentido. Un sitio creado con un marco debe funcionar mejor que un sitio creado con dos o más marcos o bibliotecas.
De hecho, el rendimiento de cada herramienta front-end estudiada se ve mejor en todos los casos, excepto en una curiosa excepción. Lo que me sorprendió fue que en el percentil 50 y superior, los sitios que usan React funcionan peor cuando React es la única biblioteca que usan. Esta, por cierto, fue la razón por la que presento estos datos aquí.
Esto es un poco extraño, pero aún intentaré buscar una explicación para esta extrañeza.
Si un proyecto usa tanto React como jQuery, es probable que ese proyecto se encuentre en algún punto a la mitad de la transición de jQuery a React. Quizás tenga un código base donde se mezclen estas bibliotecas. Dado que ya hemos visto que los sitios de jQuery pasan menos tiempo en el hilo principal que los sitios de React, esto podría indicarnos que implementar alguna funcionalidad en jQuery ayuda a que el sitio funcione un poco mejor.
Pero a medida que el proyecto pasa de jQuery a React y se basa más en React, las cosas están cambiando. Si el sitio es realmente de alta calidad y los desarrolladores del sitio usan React con cuidado, entonces todo estará bien con dicho sitio. Pero para el sitio promedio de React, el uso extensivo de React significa que el hilo principal está bajo una gran carga.
La brecha entre los dispositivos móviles y de escritorio
Otro punto de vista desde el que observé los datos investigados 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 cantidades más pequeñas de código descargable, pero no hay mucha diferencia en la cantidad de código móvil y de escritorio.
Pero si analizamos el tiempo requerido para procesar el código, se nota una brecha muy grande entre los dispositivos móviles y de escritorio.
Aumento del tiempo (porcentaje) relacionado con el procesamiento de scripts en dispositivos móviles en comparación con el escritorio
percentiles
10
25
50
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
Si bien es de esperar alguna diferencia en la velocidad de procesamiento de código entre un teléfono y una computadora portátil, números tan grandes me dicen que los marcos modernos no están suficientemente dirigidos a dispositivos de baja potencia y que se esfuerzan por cerrar la brecha que han descubierto. Incluso en el percentil 10, los sitios de React pasan un 431.5 % más de tiempo en el hilo principal móvil que en el hilo principal de escritorio. jQuery tiene la brecha más pequeña, pero incluso aquí la cifra correspondiente es 188.2%. Cuando los desarrolladores de sitios web hacen sus proyectos de tal manera que su procesamiento requiere más tiempo de procesador (y sucede, y solo empeora con el tiempo), los propietarios de dispositivos de bajo consumo tienen que pagar por ello.
resultados
Los buenos marcos deberían brindar a los desarrolladores una buena base para crear proyectos web (en términos de seguridad, accesibilidad, rendimiento), o deberían tener restricciones integradas que dificulten la creación de algo que viole esas restricciones.
Esto no parece aplicarse al desempeño de los proyectos web (y presumiblemente no a su ).
Vale la pena señalar que el hecho de que los sitios React o Angular dediquen más tiempo de CPU a preparar el código que otros no significa necesariamente que los sitios React consuman más CPU que los sitios Vue mientras se ejecutan. De hecho, los datos que hemos revisado dicen muy poco sobre el rendimiento operativo de los marcos y las bibliotecas. Hablan más sobre los enfoques de desarrollo que, conscientemente o no, estos marcos pueden impulsar a los programadores. Estamos hablando de documentación para frameworks, de su ecosistema, de técnicas comunes de desarrollo.
También vale la pena mencionar algo que no analizamos aquí, a saber, cuánto tiempo pasa el dispositivo ejecutando código JavaScript cuando navega entre las páginas del sitio. El argumento a favor de SPA es que una vez que la aplicación de una sola página se carga en el navegador, el usuario teóricamente 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 tema.
Lo que está claro es que si está utilizando un marco o biblioteca para crear un sitio web, está haciendo un compromiso en términos de cargar inicialmente el proyecto y dejarlo listo para funcionar. Esto se aplica incluso a los escenarios más positivos.
Es perfectamente posible hacer algunos compromisos en situaciones apropiadas, pero es importante que los desarrolladores hagan tales compromisos conscientemente.
Pero también tenemos motivos para el optimismo. Me emociona ver cuán estrechamente trabajan los desarrolladores de Chrome con los desarrolladores de algunas de las herramientas de front-end que hemos revisado en un esfuerzo por ayudar a mejorar el rendimiento de esas herramientas.
Sin embargo, soy una persona pragmática. Las nuevas arquitecturas crean problemas de rendimiento tan a menudo como los resuelven. Y se necesita tiempo para corregir errores. Así como no deberíamos esperar resolverá todos los problemas de rendimiento, no debe esperar esto de las nuevas versiones de nuestros marcos favoritos.
Si desea utilizar una de las herramientas front-end discutidas en este artículo, significa que debe hacer un esfuerzo adicional para no dañar el rendimiento de su proyecto mientras tanto. Aquí hay algunas consideraciones a considerar antes de comenzar un nuevo marco:
- Ponte a prueba con el sentido común. ¿Realmente necesita usar el marco elegido? JavaScript puro hoy en día es capaz de mucho.
- ¿Existe una alternativa más ligera al marco elegido (como Preact, Svelte u otro) que pueda brindarle el 90% de las capacidades de este marco?
- Si ya está utilizando un marco, considere 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á tu ¿Rendimiento de JavaScript?
- Como puedes ¿Un proceso de desarrollo para dificultar la inyección de más código JavaScript en un proyecto de lo absolutamente necesario?
- Si está utilizando un marco para facilitar el desarrollo, considere enviar código de marco a los clientes. ¿Tal vez puedas resolver todos los problemas en el servidor?
Por lo general, vale la pena analizar estas ideas, independientemente de lo que haya elegido exactamente para el desarrollo frontal. Pero son especialmente importantes cuando se trabaja en un proyecto que carece de rendimiento desde el principio.
Estimados lectores! ¿Cómo ves el framework de JavaScript ideal?
Fuente: habr.com