Non hai xeito máis rápido de ralentizar un sitio web (con perdón polo xogo de palabras) que usar unha tonelada de código JavaScript. Usar JavaScript pode custarlle ao rendemento ao teu proxecto polo menos catro veces máis. Velaquí a carga que supón o código JavaScript para os sistemas dos usuarios:
- Descarga dun ficheiro pola rede.
- Análise e compilación do código fonte desempaquetado despois da descarga.
- Execución de código JavaScript.
- Consumo de memoria.
Esta combinación resulta ser .
Estamos a incorporar cada vez máis código JavaScript nos nosos proxectos. A medida que as organizacións avanzan cara a sitios web baseados en frameworks e bibliotecas como React, Vue e outras, estamos a facer que a funcionalidade principal dos sitios web dependa en gran medida de JavaScript.
Vin moitos sitios web moi complexos usando frameworks de JavaScript. Pero a miña perspectiva é moi parcial. O caso é que as empresas coas que traballo acoden a min especificamente porque se enfrontan a problemas complexos de rendemento web. Entón, sentín curiosidade por saber o estendido que está este problema e que "penalizacións" pagamos ao elixir un framework en particular como base para un sitio web.
O proxecto axudoume a descubrilo. .
Datos
O proxecto HTTP Archive rastrexa un total de 4 308 655 ligazóns a sitios web de escritorio normais e 5 484 239 ligazóns a sitios web para móbiles. Entre as moitas métricas asociadas a estas ligazóns hai unha lista de tecnoloxías detectadas nos sitios correspondentes. Isto significa que podemos crear unha mostra de miles de sitios usando varios marcos e bibliotecas e aprender sobre o volume de código que envían aos clientes e a carga que este código supón para os sistemas dos usuarios.
Recollín datos de marzo de 2020, que foron os datos máis recentes aos que tiven acceso.
Decidín comparar os datos agregados do arquivo HTTP de todos os sitios cos datos dos sitios que se descubriu que usaban React, Vue e Angular, aínda que tamén considerei usar outro material fonte.
Para facer as cousas máis interesantes, tamén engadín sitios web que usan jQuery ao conxunto de datos fonte. Esta biblioteca segue a ser extremadamente popular. Tamén representa unha maneira de abordar o desenvolvemento de sitios web que difire do modelo de aplicación dunha soa páxina (SPA) que ofrecen React, Vue e Angular.
Ligazóns de arquivo HTTP que representan sitios que se descubriu que usan as tecnoloxías de interese
Marco ou biblioteca
Ligazóns a sitios web para móbiles
Ligazóns a sitios web habituais
jQuery
4615474
3714643
Reaccionar
489827
241023
Vue
85649
43691
Angular
19423
18088
Esperanzas e soños
Antes de pasar á análise de datos, quero falar do que me gustaría esperar.
Creo que nun mundo ideal, os frameworks deberían ir máis alá de simplemente satisfacer as necesidades dos desenvolvedores e proporcionar beneficios específicos aos usuarios cotiáns dos nosos sitios web. O rendemento é só un destes beneficios. A accesibilidade e a seguridade tamén veñen á mente. Pero iso é só o máis importante.
Entón, nun mundo ideal, un framework debería facilitar a creación dun sitio web de alto rendemento. Isto debería conseguirse proporcionando ao desenvolvedor unha base sólida sobre a que construír ou impoñendo restricións ao desenvolvemento, impondo requisitos que dificulten o desenvolvemento de algo que será lento.
Os mellores marcos de traballo deberían facer ambas cousas: proporcionar unha boa base e impoñer restricións ao traballo que che permitan acadar resultados decentes.
Analizar os valores medios dos datos non nos dará a información que necesitamos. E, de feito, tal enfoque deixa fóra da nosa atención En vez diso, derivei as clasificacións percentiles dos datos que tiña. Estas clasificacións son os percentiles 10, 25, 50 (mediana), 75 e 90.
Interésanme especialmente os percentiles 10 e 90. O percentil 10 representa o mellor rendemento (ou polo menos bastante próximo ao mellor) para un marco de traballo determinado. Noutras palabras, significa que só o 10 % dos sitios que usan un marco de traballo determinado alcanzan este nivel ou superior. O percentil 90, pola contra, é a outra cara da moeda: móstranos o mal que poden ir as cousas. O percentil 90 representa os sitios da parte inferior, o último 10 % dos sitios que teñen as maiores cantidades de código JavaScript ou o maior tempo que leva procesar o seu código no fío principal.
Tamaños de código JavaScript
Para comezar, ten sentido analizar o tamaño do código JavaScript transmitido por diferentes sitios a través da rede.
Tamaño do código JavaScript (KB) transferido a dispositivos móbiles
Percentiles
10
25
50
75
90
Todos os sitios
93.4
196.6
413.5
746.8
1201.6
sitios web de jQuery
110.3
219.8
430.4
748.6
1162.3
Sitios web de Vue
244.7
409.3
692.1
1065.5
1570.7
Sitios web angulares
445.1
675.6
1066.4
1761.5
2893.2
Reaccionar sitios web
345.8
441.6
690.3
1238.5
1893.6
A cantidade de código JavaScript servido a dispositivos móbiles
Tamaño do código JavaScript (KB) transferido a dispositivos de escritorio
Percentiles
10
25
50
75
90
Todos os sitios
105.5
226.6
450.4
808.8
1267.3
sitios web de jQuery
121.7
242.2
458.3
803.4
1235.3
Sitios web de Vue
248.0
420.1
718.0
1122.5
1643.1
Sitios web angulares
468.8
716.9
1144.2
1930.0
3283.1
Reaccionar sitios web
308.6
469.0
841.9
1472.2
2197.8
A cantidade de código JavaScript servido a dispositivos de escritorio
Se só falamos do tamaño do código JavaScript enviado polos sitios web aos dispositivos, as cousas parecen ser bastante semellantes. En concreto, se se usa un framework, isto significa que mesmo nunha situación ideal, o tamaño do código JavaScript do sitio aumentará. Isto non é sorprendente: non se pode usar un framework JavaScript como base dun sitio web e esperar que o tamaño do código JavaScript do proxecto sexa moi pequeno.
O que chama a atención sobre estes datos é que algúns marcos de traballo e bibliotecas considéranse un mellor punto de partida para un proxecto que outros. Os sitios que usan jQuery son os que mellor funcionan. Nos sitios de escritorio, conteñen un 15 % máis de JavaScript que todos os sitios xuntos e, nos sitios para móbiles, conteñen un 18 % máis. (É certo que hai certa distorsión nos datos. Debido a que jQuery está presente en tantos sitios, é natural que estes sitios estean máis relacionados co reconto xeral de sitios. Non obstante, isto non afecta a forma en que se calculan os datos brutos para cada marco de traballo).
Aínda que un aumento do 15-18 % no tamaño do código é unha cifra significativa, en comparación con outros frameworks e bibliotecas, pódese concluír que o "imposto" imposto por jQuery é moi baixo. Os sitios baseados en Angular no percentil 10 envían un 344 % máis de datos a dispositivos de escritorio que todos os sitios xuntos e un 377 % máis a dispositivos móbiles. Os sitios baseados en React son os seguintes máis pesados, enviando un 193 % máis de código a dispositivos de escritorio que todos os sitios xuntos e un 270 % máis a dispositivos móbiles.
Xa mencionei antes que, aínda que usar un framework significa que se incluirá unha certa cantidade de código nun proxecto ao principio, espero que o framework sexa capaz de impoñer algunhas restricións ao desenvolvedor. En concreto, estou a falar de limitar a cantidade máxima de código.
Curiosamente, os sitios web de jQuery seguen esta idea. Aínda que son lixeiramente máis pesados que todos os demais sitios web no percentil 10 (nun 15-18%), no percentil 90 son lixeiramente máis lixeiros que todos os demais sitios web, aproximadamente un 3% tanto en escritorio como en móbiles. Isto non é unha gran vantaxe, pero suxire que os sitios web de jQuery, polo menos, non teñen unha gran pegada de código JavaScript, mesmo nas súas versións máis grandes.
Pero non se pode dicir o mesmo doutros cadros.
Do mesmo xeito que co percentil 10, no percentil 90, os sitios de Angular e React son diferentes doutros sitios, pero por desgraza, son diferentes dun xeito negativo.
No percentil 90, os sitios web de Angular envían un 141 % máis de datos a dispositivos móbiles que todos os sitios web xuntos e un 159 % máis a dispositivos de escritorio. Os sitios web de React envían un 73 % máis a dispositivos de escritorio que todos os sitios web xuntos e un 58 % máis a dispositivos móbiles. O tamaño do código dos sitios web de React no percentil 90 é de 2197.8 KB. Isto significa que estes sitios web envían 322.9 KB máis de datos a dispositivos móbiles que os seus competidores máis próximos baseados en Vue. A diferenza entre os sitios web de escritorio baseados en Angular e React e outros sitios web é aínda maior. Por exemplo, os sitios web de escritorio de React envían 554.7 KB máis de código JS a dispositivos que sitios web similares baseados en Vue.
Tempo empregado no procesamento de código JavaScript no fío principal
Os datos anteriores indican claramente que os sitios web que empregan os marcos e bibliotecas en estudo conteñen grandes volumes de código JavaScript. Pero, por suposto, esta é só unha parte da nosa ecuación.
Unha vez que o código JavaScript chega ao navegador, é necesario facelo utilizable. As accións que se deben realizar no código no fío principal do navegador son especialmente problemáticas. O fío principal é o responsable de procesar as interaccións do usuario, calcular estilos e construír e mostrar o deseño da páxina. Se o fío principal está sobrecargado de tarefas de JavaScript, non poderá xestionar outras tarefas de maneira oportuna. Isto leva a atrasos e lagoas no rendemento da páxina.
A base de datos do arquivo HTTP contén información sobre o tempo que leva procesar o código JavaScript no fío principal do motor V8. Isto significa que podemos agregar estes datos e saber canto tempo leva procesar JavaScript no fío principal en varios sitios web.
Tempo de CPU (en milisegundos) empregado no procesamento de scripts en dispositivos móbiles
Percentiles
10
25
50
75
90
Todos os sitios
356.4
959.7
2372.1
5367.3
10485.8
sitios web de jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Sitios web de Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Sitios web angulares
1471.3
2380.1
4118.6
7450.8
13296.4
Reaccionar sitios web
2700.1
5090.3
9287.6
14509.6
20813.3
Tempo de CPU empregado no procesamento de scripts en dispositivos móbiles
Tempo de CPU (en milisegundos) empregado no procesamento de scripts en dispositivos de escritorio
Percentiles
10
25
50
75
90
Todos os sitios
146.0
351.8
831.0
1739.8
3236.8
sitios web de jQuery
199.6
399.2
877.5
1779.9
3215.5
Sitios web de Vue
350.4
650.8
1280.7
2388.5
4010.8
Sitios web angulares
482.2
777.9
1365.5
2400.6
4171.8
Reaccionar sitios web
508.0
1045.6
2121.1
4235.1
7444.3
Tempo de CPU empregado no procesamento de scripts en dispositivos de escritorio
Podes ver algo moi familiar aquí.
Para comezar, os sitios web baseados en jQuery dedican moito menos tempo a procesar JavaScript no fío principal que outros sitios web. No percentil 10, en comparación con todos os sitios web, os sitios web baseados en jQuery en dispositivos móbiles dedican un 61 % máis de tempo a procesar JavaScript no fío principal. No caso dos sitios web baseados en jQuery de escritorio, este aumento é do 37 %. No percentil 90, os sitios web baseados en jQuery están moi preto das cifras agregadas. En concreto, os sitios web baseados en jQuery en dispositivos móbiles dedican un 1.3 % menos de tempo no fío principal que todos os sitios web, e en dispositivos de escritorio, dedican un 0.7 % menos de tempo.
No outro extremo da nosa clasificación están os frameworks caracterizados pola maior carga no fío principal. Estes son, de novo, Angular e React. A única diferenza entre eles é que, aínda que os sitios web de Angular envían maiores cantidades de código aos navegadores que os sitios web de React, os sitios web de Angular gastan menos tempo de CPU procesando o código. Moito menos.
No percentil 10, os sitios Angular de escritorio dedican un 230 % máis de tempo de procesamento de código JavaScript no fío principal que todos os sitios. No caso dos sitios para móbiles, esta cifra é do 313 %. Os sitios React teñen o peor rendemento. En escritorio, dedican un 248 % máis de tempo que todos os sitios ao procesamento de código JavaScript e, en móbiles, dedican un 658 % máis. O 658 % non é unha errata. No percentil 10, os sitios React dedican 2.7 segundos de tempo de procesamento de código no fío principal.
En comparación con estas cifras masivas, as cifras do percentil 90 parecen polo menos lixeiramente mellores. En comparación con todos os sitios web, os proxectos de Angular pasan un 29 % máis de tempo no fío principal en dispositivos de escritorio e un 27 % máis en dispositivos móbiles. Para os sitios web de React, as cifras correspondentes son do 130 % e do 98 %, respectivamente.
As porcentaxes de desviación do percentil 90 parecen mellores que as do percentil 10. Non obstante, convén lembrar que as cifras de tempo parecen bastante desalentadoras. Por exemplo, 20.8 segundos no fío principal dun dispositivo móbil para un sitio web React. (Creo que unha explicación do que realmente ocorre durante este tempo merecería un artigo separado).
Hai unha posible complicación aquí (grazas (Grazas por chamar a miña atención sobre isto e por examinar coidadosamente os datos desde esta perspectiva). O caso é que moitos sitios web usan varias ferramentas front-end. En particular, vin moitos sitios web que usan jQuery xunto con React ou Vue, xa que estes sitios web estaban migrando de jQuery a outros frameworks ou bibliotecas. Entón, volvín á base de datos, esta vez seleccionando só as ligazóns que correspondían a sitios web que usaban só React, jQuery, Angular ou Vue, pero non ningunha combinación deles. Isto é o que atopei.
Tempo de CPU (en milisegundos) empregado no procesamento de scripts en dispositivos móbiles en situacións nas que os sitios web só usan un marco de traballo ou unha biblioteca
Percentiles
10
25
50
75
90
Sitios que só usan jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Sitios que só usan Vue
944.0
1716.3
3194.7
5959.6
9843.8
Sitios que só usan Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Sitios web que só usan React
2443.2
4620.5
10061.4
17074.3
24956.3
Tempo de CPU relacionado co procesamento de scripts en dispositivos móbiles nunha situación na que os sitios só usan un framework ou unha biblioteca
Primeiro, algo que non debería sorprender: cando un sitio web usa só un framework ou biblioteca, o seu rendemento adoita mellorar. As métricas de cada ferramenta vense mellor nos percentiles 10 e 25. Isto ten sentido. Un sitio web creado cun único framework debería ter un mellor rendemento que un creado con dous ou máis frameworks ou bibliotecas.
De feito, o rendemento de cada ferramenta de interface estudada parece mellor en todos os casos, cunha curiosa excepción. Sorprendeume descubrir que no percentil 50 e por riba, os sitios web que usan React teñen o peor rendemento cando React é a única biblioteca utilizada. Esta, por certo, é a razón pola que presento estes datos aquí.
Isto é un pouco estraño, pero aínda así tentarei atopar unha explicación para esta rareza.
Se un proxecto usa tanto React como jQuery, é probable que estea a metade da migración de jQuery a React. Incluso pode ter unha base de código que mesture estas bibliotecas. Dado que xa vimos que os sitios web baseados en jQuery pasan menos tempo no fío principal que os sitios web baseados en React, isto pode indicar que implementar algunha funcionalidade en jQuery axuda a mellorar o rendemento do sitio.
Pero a medida que un proxecto pasa de jQuery a React e depende máis de React, a situación cambia. Se o sitio está realmente ben deseñado e os desenvolvedores usan React con criterio, entón todo irá ben. Pero para un sitio React medio, o uso extensivo de React significa que o fío principal está suxeito a unha maior carga.
A brecha entre os dispositivos móbiles e os de escritorio
Outra forma de analizar os datos foi examinar a diferenza entre o uso de sitios web para móbiles e para ordenadores de sobremesa. No que respecta ás comparacións do tamaño do código JavaScript, non se atopou nada alarmante. Aínda que sería bo ver descargas máis pequenas, non hai unha diferenza significativa entre os tamaños do código para móbiles e para ordenadores de sobremesa.
Pero se analizamos o tempo necesario para procesar o código, nótase unha gran diferenza entre os dispositivos móbiles e os de escritorio.
Aumento do tempo (en porcentaxe) dedicado ao procesamento de scripts en dispositivos móbiles en comparación cos dispositivos de escritorio
Percentiles
10
25
50
75
90
Todos os sitios
144.1
172.8
185.5
208.5
224.0
sitios web de jQuery
188.2
187.4
191.3
209.6
221.9
Sitios web de Vue
222.5
220.8
220.2
221.4
220.4
Sitios web angulares
205.1
206.0
201.6
210.4
218.7
Reaccionar sitios web
431.5
386.8
337.9
242.6
179.6
Aínda que é de esperar certa diferenza na velocidade de procesamento de código entre un teléfono e un portátil, unhas cifras tan elevadas indican que os frameworks modernos non están suficientemente centrados en dispositivos de baixo consumo e non se esforzan por pechar a brecha identificada. Mesmo no percentil 10, os sitios web de React dedican un 431.5 % máis de tempo ao fío principal dos dispositivos móbiles que ao fío principal dos dispositivos de escritorio. jQuery ten a brecha máis pequena, pero mesmo alí, a cifra correspondente é do 188.2 %. Cando os desenvolvedores de sitios web deseñan os seus proxectos para que requiran máis tempo de CPU (e o fan, e a situación só empeora co tempo), son os propietarios de dispositivos de baixo consumo os que pagan o prezo.
Resultados de
Uns bos marcos de traballo deberían proporcionarlles aos desenvolvedores unha boa base para construír proxectos web (en termos de seguridade, accesibilidade e rendemento) ou deberían ter limitacións integradas que dificulten a construción de calquera cousa que viole esas limitacións.
Isto non parece aplicarse ao rendemento dos proxectos web (e aparentemente aos seus ).
Cómpre sinalar que o feito de que os sitios web de React ou Angular dediquen máis tempo de CPU á preparación do código que outros non significa necesariamente que os sitios web de React consuman máis CPU durante o tempo de execución que os sitios web de Vue. De feito, os datos que revisamos din moi pouco sobre o rendemento operativo dos frameworks e as bibliotecas. Din máis sobre as abordaxes de desenvolvemento que estes frameworks poden, consciente ou inconscientemente, animar aos programadores a adoptar. Isto inclúe a documentación dos frameworks, os seus ecosistemas e as prácticas de desenvolvemento comúns.
Tamén paga a pena mencionar algo que non analizamos aquí: canto tempo pasa o dispositivo executando código JavaScript ao navegar entre páxinas web. O argumento a favor das aplicacións SPA é que, unha vez que se carga unha aplicación dunha soa páxina no navegador, o usuario, teoricamente, poderá acceder ás páxinas web máis rápido. A miña propia experiencia suxire que isto non é algo que se dea por sentado. Pero non temos os datos para aclaralo.
O que está absolutamente claro é que se empregas un framework ou unha biblioteca para crear un sitio web, estás a facer un compromiso en canto á carga e configuración iniciais do proxecto. Isto aplícase mesmo aos mellores escenarios.
En situacións axeitadas, é perfectamente aceptable facer algunhas concesións, pero é importante que os desenvolvedores as fagan conscientemente.
Pero tamén temos motivos para o optimismo. Anímame a colaboración estreita que teñen os desenvolvedores de Chrome cos desenvolvedores dalgunhas das ferramentas front-end que revisamos para axudar a mellorar o seu rendemento.
Non obstante, son unha persoa pragmática. As novas arquitecturas adoitan crear problemas de rendemento e, ao mesmo tempo, resolvelos. E leva tempo arranxar os erros. Do mesmo xeito que non deberiamos esperar que Aínda que resolverán todos os problemas de rendemento, non deberías esperar isto das novas versións dos nosos frameworks favoritos.
Se decides usar unha das ferramentas de frontend que se tratan neste artigo, terás que esforzarte un pouco máis para garantir que o rendemento do teu proxecto non se vexa comprometido. Aquí tes algunhas consideracións que debes ter en conta antes de usar un novo framework:
- Pon a proba o teu sentido común. De verdade necesitas usar o framework que escolliches? O JavaScript puro é capaz de moitísimo hoxe en día.
- Existe algunha alternativa máis lixeira ao framework que escolliches (como Preact, Svelte ou calquera outra cousa) que che poida dar o 90 % das capacidades dese framework?
- Se xa estás a usar un framework, considera se hai algo que ofreza opcións estándar mellores e máis conservadoras (por exemplo, Nuxt.js en lugar de Vue, Next.js en lugar de React, etc.).
- Como será o teu? Rendemento de JavaScript?
- Como podes? proceso de desenvolvemento co obxectivo de dificultar a incorporación de máis código JavaScript nun proxecto do absolutamente necesario?
- Se estás a usar un framework para facilitar o desenvolvemento, considera Envía o código do framework aos clientes. Quizais poidas resolver algún problema do lado do servidor?
Xeralmente, paga a pena considerar estas ideas independentemente do marco de desenvolvemento front-end que escolla. Pero son especialmente importantes cando se traballa nun proxecto que ten problemas de rendemento desde o principio.
Queridos lectores! Cal consideras o framework de JavaScript ideal?
Fonte: www.habr.com
