Non hai forma máis rápida de ralentizar un sitio web (juego de palabras) que usar un montón de código JavaScript nel. Ao usar JavaScript, ten que pagar por iso coa realización de proxectos non menos de catro veces. Así é como o código JavaScript do sitio carga os sistemas dos usuarios:
- Descargando un ficheiro pola rede.
- Analizando e compilando o código fonte descomprimido despois da descarga.
- Execución de código JavaScript.
- Consumo de memoria.
Esta combinación resulta .
E incluímos cada vez máis código JS nos nosos proxectos. A medida que as organizacións avanzan cara a sitios impulsados por frameworks e bibliotecas como React, Vue e outros, estamos facendo que a funcionalidade básica dos sitios dependa en gran medida de JavaScript.
Vin moitos sitios moi pesados usando frameworks JavaScript. Pero a miña visión do tema é moi parcial. O caso é que as empresas coas que traballo recorren a min precisamente porque se enfrontan a problemas complexos no ámbito do rendemento do sitio. Como resultado, sentín curiosidade sobre o común que é este problema e sobre que tipo de "penas" pagamos cando escollemos un ou outro marco como base para un determinado sitio.
O proxecto axudoume a entender isto. .
Datos
O proxecto HTTP Archive rastrexa un total de 4308655 ligazóns a sitios de escritorio habituais e 5484239 ligazóns a sitios móbiles. Entre as moitas métricas asociadas a estas ligazóns hai unha lista de tecnoloxías que se atopan nos respectivos sitios. Isto significa que podemos probar miles de sitios que usan varios marcos e bibliotecas e coñecer canto código envían aos clientes e canta carga crea este código nos sistemas dos usuarios.
Recollei os 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 en todos os sitios cos datos dos sitios atopados usando React, Vue e Angular, aínda que considerei usar outro material fonte tamén.
Para facelo máis interesante, tamén engadín sitios que usan jQuery ao conxunto de datos fonte. Esta biblioteca aínda é moi popular. Tamén introduce un enfoque diferente para o desenvolvemento web que o modelo de aplicación de páxina única (SPA) ofrecido por React, Vue e Angular.
Ligazóns do Arquivo HTTP que representan sitios que se descubriu que utilizan tecnoloxías de interese
Marco ou biblioteca
Ligazóns a sitios móbiles
Ligazóns a sitios 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 sobre o que me gustaría esperar.
Creo que nun mundo ideal, os frameworks deberían ir máis alá de satisfacer as necesidades dos desenvolvedores e proporcionar algún beneficio específico ao usuario medio que traballa cos nosos sitios. O rendemento é só un deses beneficios. Aquí é onde entran en xogo a accesibilidade e a seguridade. Pero este é só o máis importante.
Entón, nun mundo ideal, algún tipo de marco debería facilitar a creación dun sitio de alto rendemento. Isto debería facerse debido ao feito de que o marco proporciona ao desenvolvedor unha base digna sobre a que construír un proxecto, ou debido ao feito de que impón restricións ao desenvolvemento, presenta requisitos para iso que complican o desenvolvemento de algo que se transforma. para ser lento.
Os mellores frameworks deberían facer as dúas cousas: dar unha boa base e impoñer restricións ao traballo, permitindo conseguir un resultado decente.
Analizar os valores medianos dos datos non nos dará a información que necesitamos. E, de feito, este enfoque deixa fóra da nosa atención . Pola contra, derivei porcentaxes dos datos que tiña. Estes son os percentiles 10, 25, 50 (mediana), 75, 90.
Interésanme especialmente os percentiles 10 e 90. O percentil 10 representa o mellor rendemento (ou polo menos máis ou menos preto do mellor) para un marco particular. Noutras palabras, isto significa que só o 10% dos sitios que usan un marco en particular chegan a este nivel ou superior. O percentil 90, por outra banda, é a outra cara da moeda: móstranos o mal que poden chegar a ser as cousas. O percentil 90 son os sitios que están detrás: o 10 % inferior dos sitios que teñen máis código JS ou máis tempo para procesar o seu código no fío principal.
Volumes 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.
A cantidade de código JavaScript (Kb) transferido a dispositivos móbiles
Percentís
10
25
50
75
90
Todos os sitios
93.4
196.6
413.5
746.8
1201.6
Sitios jQuery
110.3
219.8
430.4
748.6
1162.3
Sitios de Vue
244.7
409.3
692.1
1065.5
1570.7
Sitios angulares
445.1
675.6
1066.4
1761.5
2893.2
React Sites
345.8
441.6
690.3
1238.5
1893.6
Cantidade de código JavaScript enviado a dispositivos móbiles
Cantidade de código JavaScript (Kb) transferido a dispositivos de escritorio
Percentís
10
25
50
75
90
Todos os sitios
105.5
226.6
450.4
808.8
1267.3
Sitios jQuery
121.7
242.2
458.3
803.4
1235.3
Sitios de Vue
248.0
420.1
718.0
1122.5
1643.1
Sitios angulares
468.8
716.9
1144.2
1930.0
3283.1
React Sites
308.6
469.0
841.9
1472.2
2197.8
Cantidade de código JavaScript enviado a dispositivos de escritorio
Se falamos só do tamaño do código JS que os sitios envían aos dispositivos, entón todo se ve como podería esperar. É dicir, se se usa un dos marcos, isto significa que, mesmo nunha situación ideal, o volume do código JavaScript do sitio aumentará. Non é sorprendente: non podes facer que un marco JavaScript sexa a base dun sitio e esperar que o volume do código JS do proxecto sexa moi baixo.
O destacable destes datos é que algúns marcos e bibliotecas poden considerarse un mellor punto de partida para un proxecto que outros. Os sitios con jQuery teñen o mellor aspecto. Nas versións de escritorio dos sitios, conteñen un 15 % máis de JavaScript que todos os sitios, e nos móbiles conteñen un 18 % máis. (É certo que aquí hai algún tipo de corrupción de datos. O feito é que jQuery está presente en moitos sitios, polo que é natural que estes sitios estean máis estreitamente asociados que outros co número total de sitios. Non obstante, isto non afecta a forma en que bruto). os datos saen para cada marco.)
Aínda que o aumento do 15-18% no volume de código é unha cifra notable, comparando isto con outros frameworks e bibliotecas, pódese concluír que o "imposto" que cobra jQuery é moi baixo. Os sitios angulares do percentil 10 envían un 344 % máis de datos ao escritorio que todos os sitios e un 377 % máis aos móbiles. Os sitios React son os seguintes máis pesados, enviando un 193 % máis de código ao escritorio que todos os sitios e un 270 % máis aos móbiles.
Anteriormente, mencionei que aínda que usar un marco significa que se incluirá unha certa cantidade de código no proxecto, ao comezo do traballo sobre el, espero que o marco poida limitar dalgún xeito o programador. En particular, estamos a falar de limitar a cantidade máxima de código.
Curiosamente, os sitios de jQuery seguen esta idea. Aínda que son lixeiramente máis pesados que todos os sitios do percentil 10 (un 15-18 %), son lixeiramente máis lixeiros no percentil 90 ao redor do 3 % tanto en ordenadores como en móbiles. Isto non quere dicir que este sexa un beneficio moi significativo, pero pódese dicir que os sitios jQuery, polo menos, non teñen grandes tamaños de código JavaScript, mesmo nas súas versións máis grandes.
Pero non se pode dicir o mesmo doutros marcos.
Do mesmo xeito que no caso do percentil 10, no percentil 90 os sitios de Angular e React difiren doutros sitios, pero, por desgraza, difieren para peor.
No percentil 90, os sitios de Angular envían un 141 % máis de datos ao móbil que todos os sitios e un 159 % máis ao escritorio. Os sitios React envían un 73 % máis ao escritorio que todos os sitios e un 58 % máis ao móbil. O tamaño do código dos sitios de React no percentil 90 é de 2197.8 KB. Isto significa que estes sitios envían 322.9 KB máis de datos aos dispositivos móbiles que os seus competidores máis próximos baseados en Vue. A diferenza entre os sitios de escritorio baseados en Angular e React e outros sitios é aínda maior. Por exemplo, os sitios React de escritorio envían 554.7 KB máis de código JS aos dispositivos que sitios similares de Vue.
Tempo necesario para procesar o código JavaScript no fío principal
Os datos anteriores indican claramente que os sitios que usan os frameworks e as bibliotecas en estudo conteñen grandes cantidades de código JavaScript. Pero, por suposto, iso é só unha parte da nosa ecuación.
Despois de que o código JavaScript chegou ao navegador, debe ser levado a un estado viable. Especialmente moitos problemas son causados por aquelas accións que teñen que realizarse co código no fío principal do navegador. O fío principal encárgase de procesar as accións do usuario, de calcular estilos, de construír e mostrar o deseño da páxina. Se superas o fío principal con tarefas JavaScript, non terá a oportunidade de completar o resto das tarefas a tempo. Isto leva a atrasos e "freos" no traballo das páxinas.
A base de datos HTTP Archive ten información sobre o tempo que leva procesar o código JavaScript no fío principal do motor V8. Isto significa que podemos recoller estes datos e descubrir canto tempo tarda o fío principal en procesar o JavaScript de varios sitios.
Tempo do procesador (en milisegundos) relacionado co procesamento de scripts en dispositivos móbiles
Percentís
10
25
50
75
90
Todos os sitios
356.4
959.7
2372.1
5367.3
10485.8
Sitios jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Sitios de Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Sitios angulares
1471.3
2380.1
4118.6
7450.8
13296.4
React Sites
2700.1
5090.3
9287.6
14509.6
20813.3
Tempo do procesador relacionado co procesamento de scripts en dispositivos móbiles
Tempo do procesador (en milisegundos) relacionado co procesamento de scripts en dispositivos de escritorio
Percentís
10
25
50
75
90
Todos os sitios
146.0
351.8
831.0
1739.8
3236.8
Sitios jQuery
199.6
399.2
877.5
1779.9
3215.5
Sitios de Vue
350.4
650.8
1280.7
2388.5
4010.8
Sitios angulares
482.2
777.9
1365.5
2400.6
4171.8
React Sites
508.0
1045.6
2121.1
4235.1
7444.3
Tempo do procesador relacionado co procesamento de scripts en dispositivos de escritorio
Aquí podedes ver algo moi coñecido.
Para comezar, os sitios con jQuery gastan moito menos en procesamento de JavaScript no fío principal que outros sitios. No percentil 10, en comparación con todos os sitios, os sitios de jQuery para móbiles pasan un 61 % máis de tempo procesando código JS no fío principal. No caso dos sitios jQuery de escritorio, o tempo de procesamento aumenta nun 37%. No percentil 90, os sitios de jQuery puntuan moi preto das puntuacións agregadas. En concreto, os sitios jQuery en dispositivos móbiles pasan un 1.3 % menos de tempo no fío principal que todos os sitios e un 0.7 % menos nos dispositivos de escritorio.
Do outro lado da nosa valoración están os cadros que se caracterizan pola maior carga no fío principal. Isto é, de novo, Angular e React. A única diferenza entre os dous é que mentres os sitios Angular envían máis código aos navegadores que os sitios React, os sitios Angular tardan menos tempo da CPU en procesar o código. Moito menos.
No percentil 10, os sitios Angular de escritorio pasan un 230 % máis de tempo no fío principal que procesa código JS que todos os sitios. Para sitios móbiles, esta cifra é do 313%. Os sitios de reacción son os que teñen peor rendemento. No escritorio, pasan un 248 % máis de tempo procesando código que todos os sitios e un 658 % máis no móbil. O 658 % non é un erro. No percentil 10, os sitios de React pasan 2.7 segundos de tempo de fío principal procesando o seu código.
O percentil 90, en comparación con estes números enormes, parece polo menos un pouco mellor. En comparación con todos os sitios, os proxectos Angular pasan un 29 % máis de tempo en dispositivos de escritorio no fío principal e un 27 % máis en dispositivos móbiles. No caso dos sitios React, as mesmas cifras parecen do 130% e do 98%, respectivamente.
As desviacións porcentuais para o percentil 90 parecen mellor que os valores similares para o percentil 10. Pero aquí convén lembrar que os números que indican a hora parecen bastante asustados. Digamos 20.8 segundos no fío móbil principal para un sitio web creado con React. (Creo que a historia do que realmente acontece durante este tempo é digna dun artigo aparte).
Aquí hai unha complicación potencial (grazas por chamarme a atención sobre esta característica e por considerar coidadosamente os datos desde este punto de vista). O feito é que moitos sitios usan varias ferramentas front-end. En particular, vin moitos sitios que usan jQuery xunto con React ou Vue, xa que eses sitios están migrando de jQuery a outros frameworks ou bibliotecas. Como resultado, batei de novo na base de datos, esta vez seleccionando só aquelas ligazóns que corresponden a sitios que só usan React, jQuery, Angular ou Vue, pero non ningunha combinación deles. Aquí está o que teño.
Tempo do procesador (en milisegundos) relacionado co procesamento de scripts en dispositivos móbiles nunha situación na que os sitios usan só un marco ou só unha biblioteca
Percentís
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 que só usan React
2443.2
4620.5
10061.4
17074.3
24956.3
Tempo do procesador relacionado co procesamento de scripts en dispositivos móbiles nunha situación na que os sitios usan só un marco ou só unha biblioteca
En primeiro lugar, algo que non sorprende: cando un sitio usa só un marco ou unha biblioteca, o rendemento deste sitio mellora a maioría das veces. Cada instrumento funciona mellor nos percentiles 10 e 25. Ten sentido. Un sitio que se crea usando un marco debería funcionar mellor que un sitio que se fai usando dous ou máis marcos ou bibliotecas.
De feito, o rendemento de cada ferramenta front-end estudada parece mellor en todos os casos, agás unha curiosa excepción. O que me sorprendeu foi que no percentil 50 e superior, os sitios que usan React funcionan peor cando React é a única biblioteca que usan. Este, por certo, foi o motivo polo que presento aquí estes datos.
Isto é un pouco estraño, pero aínda así intentarei buscar unha explicación para esta estrañeza.
Se un proxecto usa React e jQuery, entón ese proxecto probablemente estea nalgún lugar na metade da transición de jQuery a React. Quizais teña unha base de código onde se mesturan estas bibliotecas. Dado que xa vimos que os sitios de jQuery pasan menos tempo no fío principal que os de React, isto pode indicarnos que implementar algunha funcionalidade en jQuery axuda a que o sitio funcione un pouco mellor.
Pero a medida que o proxecto pasa de jQuery a React e depende máis de React, as cousas están cambiando. Se o sitio é realmente de alta calidade e os desenvolvedores do sitio usan React con coidado, entón todo estará ben con tal sitio. Pero para o sitio medio de React, o uso extensivo de React significa que o fío principal está sometido a unha gran carga.
A diferenza entre os dispositivos móbiles e de escritorio
Outro punto de vista desde o que mirei os datos investigados foi o de estudar o grande que é a diferenza entre traballar con sitios en dispositivos móbiles e de escritorio. Se falamos de comparar os volumes de código JavaScript, entón tal comparación non revela nada terrible. Por suposto, sería bo ver cantidades máis pequenas de código descargable, pero non hai moita diferenza na cantidade de código de móbil e de escritorio.
Pero se analizamos o tempo necesario para procesar o código, nótase unha brecha moi grande entre os dispositivos móbiles e de escritorio.
Aumento do tempo (porcentaxe) relacionado co procesamento de scripts en dispositivos móbiles en comparación co escritorio
Percentís
10
25
50
75
90
Todos os sitios
144.1
172.8
185.5
208.5
224.0
Sitios jQuery
188.2
187.4
191.3
209.6
221.9
Sitios de Vue
222.5
220.8
220.2
221.4
220.4
Sitios angulares
205.1
206.0
201.6
210.4
218.7
React Sites
431.5
386.8
337.9
242.6
179.6
Aínda que é de esperar algunha diferenza na velocidade de procesamento de código entre un teléfono e un portátil, un número tan grande dinme que os marcos modernos non están suficientemente dirixidos a dispositivos de baixa potencia e que se esforzan por pechar a brecha que descubriron. Incluso no percentil 10, os sitios de React pasan un 431.5% máis de tempo no fío principal do móbil que no do escritorio. jQuery ten a menor diferenza, pero aínda aquí a cifra correspondente é do 188.2%. Cando os desenvolvedores de sitios web fan os seus proxectos de tal xeito que o seu procesamento require máis tempo de procesador (e ocorre, e só empeora co paso do tempo), os propietarios de dispositivos de baixa potencia teñen que pagar por iso.
Resultados de
Os bos marcos deberían ofrecer aos desenvolvedores unha boa base para construír proxectos web (en termos de seguridade, accesibilidade, rendemento) ou deberían ter restricións integradas que dificulten a construción de algo que infrinxa esas restricións.
Isto non parece aplicarse ao rendemento dos proxectos web (e presumiblemente non ao seu ).
Paga a pena notar que só porque os sitios React ou Angular dediquen máis tempo á CPU a preparar código que outros non significa necesariamente que os sitios React consuman máis CPU que os sitios Vue mentres se executan. De feito, os datos que revisamos din moi pouco sobre o rendemento operativo dos frameworks e bibliotecas. Falan máis sobre os enfoques de desenvolvemento que, consciente ou non, estes frameworks poden impulsar aos programadores. Estamos a falar de documentación para frameworks, do seu ecosistema, de técnicas de desenvolvemento comúns.
Tamén paga a pena mencionar algo que non analizamos aquí, é dicir, canto tempo pasa o dispositivo executando código JavaScript ao navegar entre páxinas do sitio. O argumento a favor de SPA é que unha vez cargada a aplicación dunha soa páxina no navegador, teoricamente o usuario poderá abrir as páxinas do sitio máis rápido. A miña propia experiencia dime que isto está lonxe de ser un feito. Pero non temos datos que aclaren esta cuestión.
O que está claro é que se estás a usar un marco ou unha biblioteca para crear un sitio web, estás facendo un compromiso en canto a cargar inicialmente o proxecto e preparalo para funcionar. Isto aplícase incluso aos escenarios máis positivos.
É perfectamente posible facer algúns compromisos nas situacións adecuadas, pero é importante que os desenvolvedores fagan tales compromisos de forma consciente.
Pero tamén temos motivos de optimismo. Estou entusiasmado de ver como están a traballar os desenvolvedores de Chrome cos desenvolvedores dalgunhas das ferramentas front-end que revisamos para axudar a mellorar o rendemento desas ferramentas.
Porén, son unha persoa pragmática. As novas arquitecturas crean problemas de rendemento tantas veces como os solucionan. E leva tempo corrixir erros. Así como non debemos esperar resolverá todos os problemas de rendemento, non deberías esperar isto das novas versións dos nosos cadros favoritos.
Se queres usar unha das ferramentas front-end que se comentan neste artigo, isto significa que terás que esforzarte máis para non prexudicar o rendemento do teu proxecto mentres tanto. Aquí tes algunhas consideracións a ter en conta antes de comezar un novo marco:
- Proba a si mesmo con sentido común. Realmente necesitas usar o marco escollido? O JavaScript puro hoxe é capaz de moito.
- Existe unha alternativa máis lixeira ao marco escollido (como Preact, Svelte ou outra cousa) que che poida ofrecer o 90% das capacidades deste marco?
- 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.).
- Cal será o teu Rendemento de JavaScript?
- Como podes un proceso de desenvolvemento para facer máis difícil inxectar máis código JavaScript nun proxecto do que é absolutamente necesario?
- Se estás a usar un marco para facilitar o desenvolvemento, ten en conta enviar código marco aos clientes. Quizais poidas resolver todos os problemas do servidor?
Normalmente vale a pena ver estas ideas, independentemente do que escolliches exactamente para o desenvolvemento front-end. Pero son especialmente importantes cando estás a traballar nun proxecto que carece de rendemento desde o principio.
Queridos lectores! Como ves o marco de JavaScript ideal?
Fonte: www.habr.com