No hi ha una manera més ràpida de frenar un lloc web (sense joc de paraules) que executar-hi un munt de codi JavaScript. Quan utilitzeu JavaScript, heu de pagar-lo en el rendiment del projecte almenys quatre vegades. Aquí teniu el codi JavaScript del lloc amb què carrega els sistemes dels usuaris:
- Carregant un fitxer a la xarxa.
- Anàlisi i compilació del codi font descomprimit després de la descàrrega.
- S'està executant codi JavaScript.
- Consum de memòria.
Aquesta combinació resulta ser .
I cada cop incloem més codi JS als nostres projectes. A mesura que les organitzacions avancen cap a llocs basats en marcs i biblioteques com React, Vue i altres, estem fent que la funcionalitat bàsica dels llocs depengui molt de JavaScript.
He vist molts llocs web molt pesats que utilitzen marcs de JavaScript. Però la meva visió del tema és fortament esbiaixada. El cas és que les empreses amb les quals treballo vénen a mi precisament perquè tenen problemes complexos de rendiment del lloc web. Com a resultat, vaig tenir curiositat per saber com d'estès aquest problema i quines "multes" paguem quan triem un o un altre marc com a base per a un lloc determinat.
Aquest projecte m'ha ajudat a esbrinar-ho. .
Dades
El projecte HTTP Archive fa un seguiment d'un total de 4308655 enllaços a llocs d'escriptori habituals i 5484239 enllaços a llocs mòbils. Entre els molts indicadors associats a aquests enllaços hi ha una llista de tecnologies que es troben als llocs corresponents. Això vol dir que podem provar milers de llocs que utilitzen diferents marcs i biblioteques i saber quant codi envien als clients i quanta càrrega aquest codi suposa als sistemes dels usuaris.
Vaig recollir dades del març de 2020, que van ser les dades més recents a les quals vaig tenir accés.
Vaig decidir comparar les dades agregades de l'arxiu HTTP de tots els llocs amb les dades dels llocs que s'havien trobat que utilitzaven React, Vue i Angular, tot i que també vaig pensar en utilitzar altres materials font.
Per fer-ho més interessant, també he afegit llocs que utilitzen jQuery al conjunt de dades font. Aquesta biblioteca encara és molt popular. També introdueix un enfocament del desenvolupament de llocs web que difereix del model d'aplicació de pàgina única (SPA) que ofereix React, Vue i Angular.
Enllaços a l'Arxiu HTTP que representen llocs on s'ha trobat que utilitzen tecnologies del nostre interès
Marc o biblioteca
Enllaços a llocs mòbils
Enllaços a llocs habituals
jQuery
4615474
3714643
Reaccionar
489827
241023
Vue
85649
43691
Angular
19423
18088
Esperances i somnis
Abans de passar a l'anàlisi de les dades, vull parlar del que m'agradaria esperar.
Crec que en un món ideal, els frameworks anirien més enllà de satisfer les necessitats dels desenvolupadors i oferiran alguns beneficis concrets als usuaris quotidians dels nostres llocs. La productivitat és només un d'aquests beneficis. L'accessibilitat i la seguretat també vénen al cap aquí. Però això només és el més important.
Per tant, en un món ideal, algun tipus de marc hauria de facilitar la creació d'un lloc web d'alt rendiment. Això s'ha de fer ja sigui pel fet que el marc ofereix al desenvolupador una base digna sobre la qual construir un projecte, o pel fet que imposa restriccions al desenvolupament, plantejant-hi requisits que dificulten el desenvolupament d'alguna cosa. que resulta ser lent.
Els millors marcs haurien de fer les dues coses: proporcionar una bona base i imposar restriccions al treball que us permetin aconseguir un resultat decent.
L'anàlisi dels valors mitjans de les dades no ens donarà la informació que necessitem. I, de fet, aquest enfocament deixa més enllà de la nostra atenció . En canvi, vaig obtenir puntuacions percentils de les dades que tenia. Aquests són els percentils 10, 25, 50 (mediana), 75, 90.
M'interessen especialment els percentils 10 i 90. El percentil 10 representa el millor rendiment (o almenys més o menys proper al millor) per a un marc concret. En altres paraules, això significa que només el 10% dels llocs que utilitzen un marc determinat assoleixen aquest nivell, o un nivell superior. El percentil 90, en canvi, és l'altra cara de la moneda: ens mostra com poden ser les coses dolentes. El percentil 90 són els llocs finals: aquells darrers 10% dels llocs que tenen la major quantitat de codi JS o el temps més llarg necessari per processar el seu codi al fil principal.
Volums de codi JavaScript
Per començar, té sentit analitzar la mida del codi JavaScript transmès per diferents llocs a la xarxa.
Quantitat de codi JavaScript (KB) transferit a dispositius mòbils
Percentils
10
25
50
75
90
Tots els llocs
93.4
196.6
413.5
746.8
1201.6
Llocs jQuery
110.3
219.8
430.4
748.6
1162.3
Llocs web de Vue
244.7
409.3
692.1
1065.5
1570.7
Webs angulars
445.1
675.6
1066.4
1761.5
2893.2
Webs de reaccions
345.8
441.6
690.3
1238.5
1893.6
Quantitat de codi JavaScript enviat a dispositius mòbils
Quantitat de codi JavaScript (KB) transferit a dispositius d'escriptori
Percentils
10
25
50
75
90
Tots els llocs
105.5
226.6
450.4
808.8
1267.3
Llocs jQuery
121.7
242.2
458.3
803.4
1235.3
Llocs web de Vue
248.0
420.1
718.0
1122.5
1643.1
Webs angulars
468.8
716.9
1144.2
1930.0
3283.1
Webs de reaccions
308.6
469.0
841.9
1472.2
2197.8
Quantitat de codi JavaScript transferit a dispositius d'escriptori
Si només parlem de la mida del codi JS que els llocs envien als dispositius, aleshores tot es veu com podria esperar. És a dir, si s'utilitza un dels marcs, això significa que fins i tot en una situació ideal, el volum de codi JavaScript per al lloc augmentarà. Això no és sorprenent: no podeu fer d'un marc de JavaScript la base d'un lloc i esperar que la quantitat de codi JS per al projecte sigui molt baixa.
El que és interessant d'aquestes dades és que alguns marcs i biblioteques es poden considerar millors punts de partida per a un projecte que d'altres. Els llocs web amb jQuery es veuen millor. Els seus llocs d'escriptori contenen un 15% més de JavaScript que tots els llocs, i els seus llocs per a mòbils contenen un 18% més de JavaScript. (És cert que aquí hi ha una mica de sesg en les dades. El fet és que jQuery està present en molts llocs, per la qual cosa és natural que aquests llocs estiguin més relacionats amb el nombre total de llocs que altres. Tanmateix, això no afecta com les dades font es produeixen per a cada marc.)
Tot i que el creixement del codi del 15-18% és una xifra significativa, en comparació amb altres frameworks i biblioteques, l'impost imposat per jQuery és molt baix. Els llocs angulars del percentil 10 envien un 344% més de dades als dispositius d'escriptori que tots els llocs i un 377% més als dispositius mòbils. Els llocs React són els següents més pesats, enviant un 193% més de codi als dispositius d'escriptori que tots els llocs i un 270% més als dispositius mòbils.
He esmentat anteriorment que, tot i que l'ús d'un marc significa que una certa quantitat de codi s'inclourà al projecte al principi del treball, espero que el marc sigui capaç de limitar d'alguna manera el desenvolupador. En particular, estem parlant de limitar la quantitat màxima de codi.
El que és interessant és que els llocs de jQuery segueixen aquesta idea. Tot i que, al nivell del percentil 10, són lleugerament més pesats que tots els llocs (entre un 15 i un 18%), al nivell del percentil 90 són lleugerament més lleugers que tots els llocs, al voltant d'un 3% tant a les versions d'escriptori com a mòbils. Això no vol dir que sigui un avantatge molt important, però es pot dir que els llocs jQuery almenys no tenen grans mides de codi JavaScript fins i tot en les seves versions més grans.
Però no es pot dir el mateix d'altres marcs.
Igual que en el cas del percentil 10, al percentil 90 els llocs d'Angular i React difereixen d'altres llocs, però difereixen, malauradament, per pitjor.
Al percentil 90, els llocs Angular envien un 141% més de dades a dispositius mòbils que tots els llocs i un 159% més als dispositius d'escriptori. Els llocs React envien un 73% més als dispositius d'escriptori que tots els llocs i un 58% més als dispositius mòbils. La mida del codi dels llocs de React al percentil 90 és de 2197.8 KB. Això significa que aquests llocs envien 322.9 KB més de dades als dispositius mòbils que els seus competidors més propers basats en Vue. La bretxa entre els llocs d'escriptori basats en Angular i React i altres llocs és encara més gran. Per exemple, els llocs d'escriptori React envien 554.7 KB més de codi JS als dispositius que els llocs Vue similars.
Temps necessari per processar el codi JavaScript al fil principal
Les dades anteriors indiquen clarament que els llocs que utilitzen els marcs i les biblioteques estudiades contenen grans quantitats de codi JavaScript. Però, per descomptat, aquesta és només una part de la nostra equació.
Després que el codi JavaScript hagi arribat al navegador, s'ha de posar en un estat de funcionament. Sobretot, molts problemes són causats per aquelles accions que s'han de dur a terme amb codi al fil principal del navegador. El fil principal s'encarrega de processar les accions de l'usuari, calcular els estils i crear i mostrar el disseny de la pàgina. Si desbordeu el fil principal amb tasques de JavaScript, no tindrà l'oportunitat de completar altres tasques de manera oportuna. Això comporta retards i "fres" en el funcionament de les pàgines.
La base de dades de l'arxiu HTTP conté informació sobre quant de temps es triga a processar el codi JavaScript al fil principal del motor V8. Això vol dir que podem recollir aquestes dades i saber quant de temps triga el fil principal a processar el JavaScript de diversos llocs.
Temps de CPU (en mil·lisegons) relacionat amb el processament d'scripts en dispositius mòbils
Percentils
10
25
50
75
90
Tots els llocs
356.4
959.7
2372.1
5367.3
10485.8
Llocs jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Llocs web de Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Webs angulars
1471.3
2380.1
4118.6
7450.8
13296.4
Webs de reaccions
2700.1
5090.3
9287.6
14509.6
20813.3
Temps de CPU relacionat amb el processament d'scripts en dispositius mòbils
Temps de CPU (en mil·lisegons) relacionat amb el processament d'scripts en dispositius d'escriptori
Percentils
10
25
50
75
90
Tots els llocs
146.0
351.8
831.0
1739.8
3236.8
Llocs jQuery
199.6
399.2
877.5
1779.9
3215.5
Llocs web de Vue
350.4
650.8
1280.7
2388.5
4010.8
Webs angulars
482.2
777.9
1365.5
2400.6
4171.8
Webs de reaccions
508.0
1045.6
2121.1
4235.1
7444.3
Temps de CPU relacionat amb el processament d'scripts en dispositius d'escriptori
Aquí podeu veure quelcom molt conegut.
Per començar, els llocs amb jQuery gasten molt menys processant JavaScript al fil principal que altres. Al percentil 10, en comparació amb tots els llocs, els llocs de jQuery en dispositius mòbils passen un 61% més de temps processant codi JS al fil principal. En el cas dels llocs jQuery d'escriptori, el temps de processament augmenta un 37%. Al percentil 90, les puntuacions dels llocs de jQuery són molt properes a les puntuacions agregades. Concretament, els llocs de jQuery en dispositius mòbils passen un 1.3% menys de temps al fil principal que tots els llocs, i als dispositius d'escriptori passen un 0.7% menys de temps al fil principal.
A l'altre costat de la nostra qualificació hi ha marcs que es caracteritzen per la major càrrega al fil principal. Això és, de nou, Angular i React. L'única diferència entre ells és que, tot i que els llocs Angular envien quantitats més grans de codi als navegadors que els llocs React, es necessita menys temps de CPU per processar el codi dels llocs Angular. Molt menys.
Al percentil 10, els llocs d'escriptori Angular dediquen un 230% més de temps al fil principal processant codi JS que tots els llocs. Per als llocs mòbils, aquesta xifra és del 313%. Els llocs de React tenen el pitjor rendiment. Als dispositius d'escriptori dediquen un 248% més de temps a processar codi que a tots els llocs, i als dispositius mòbils passen un 658% més de temps a processar codi. El 658% no és una errada d'ortografia. Al percentil 10, els llocs de React dediquen 2.7 segons de temps del fil principal processant el codi existent.
Els números del percentil 90 semblen almenys una mica millors en comparació amb aquests nombres enormes. Els projectes angulars, en comparació amb tots els llocs, passen un 29% més de temps al fil principal en dispositius d'escriptori i un 27% més de temps en dispositius mòbils. En el cas dels llocs de React, els indicadors similars semblen un 130% i un 98%, respectivament.
Els percentatges de desviació del percentil 90 es veuen millor que els valors similars del percentil 10. Però aquí val la pena recordar que els números que indiquen el temps semblen bastant espantosos. Diguem: 20.8 segons al fil principal d'un dispositiu mòbil per a un lloc creat a React. (Crec que la història del que realment passa durant aquest temps és digne d'un article a part).
Aquí hi ha una complicació potencial (gràcies per cridar la meva atenció sobre aquesta característica i per examinar acuradament les dades des d'aquest punt de vista). El fet és que molts llocs utilitzen diverses eines de front-end. En particular, he vist que molts llocs utilitzen jQuery juntament amb React o Vue, ja que aquests llocs migren de jQuery a altres marcs o biblioteques. Com a resultat, vaig tornar a la base de dades, aquesta vegada seleccionant només aquells enllaços que corresponien a llocs que només utilitzaven React, jQuery, Angular o Vue, però no cap combinació d'ells. Aquí teniu el que tinc.
Temps del processador (en mil·lisegons) relacionat amb el processament d'scripts en dispositius mòbils en situacions en què els llocs només utilitzen un marc o només una biblioteca
Percentils
10
25
50
75
90
Llocs que només utilitzen jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Llocs que només utilitzen Vue
944.0
1716.3
3194.7
5959.6
9843.8
Llocs que només utilitzen Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Llocs web que només utilitzen React
2443.2
4620.5
10061.4
17074.3
24956.3
Temps del processador relacionat amb el processament d'scripts en dispositius mòbils en una situació en què els llocs només utilitzen un marc o només una biblioteca
En primer lloc, una cosa que no és sorprenent: quan un lloc només utilitza un marc o una biblioteca, el rendiment d'aquest lloc millora més sovint que no. El rendiment de cada instrument es veu millor als percentils 10 i 25. Que té sentit. Un lloc que es fa amb un marc ha de ser més ràpid que un lloc que es fa amb dos o més marcs o biblioteques.
De fet, les puntuacions de cada eina frontal que vam examinar es veien millor en tots els casos, amb una curiosa excepció. El que em va sorprendre va ser que al percentil 50 i superior, els llocs que utilitzen React funcionen pitjor quan React és l'única biblioteca que utilitzen. Aquest, per cert, va ser el motiu pel qual presento aquestes dades aquí.
Això és una mica estrany, però encara intentaré buscar una explicació per a aquesta estranyesa.
Si un projecte utilitza React i jQuery, és probable que aquest projecte estigui a mig camí del procés de migració de jQuery a React. Potser té una base de codi en què es barregen aquestes biblioteques. Com que ja hem vist que els llocs de jQuery passen menys temps al fil principal que els de React, això ens pot indicar que la implementació d'algunes funcionalitats a jQuery ajuda a millorar una mica el rendiment del lloc.
Però a mesura que el projecte passa de jQuery a React i es basa cada cop més en React, la situació canvia. Si el lloc està fet amb una qualitat realment alta i els desenvolupadors del lloc utilitzen React amb cura, tot anirà bé amb aquest lloc. Però per al lloc mitjà de React, l'ús extensiu de React significa que el fil principal està subjecte a una càrrega més gran.
La bretxa entre dispositius mòbils i d'escriptori
Una altra manera de mirar les dades va ser explorar com de gran és la bretxa entre les experiències mòbils i d'escriptori. Si parlem de comparar els volums de codi JavaScript, aquesta comparació no revela res terrible. Per descomptat, estaria bé veure quantitats més petites de codi descarregable, però no hi ha molta diferència en la quantitat de codi mòbil i d'escriptori.
Però si s'analitza el temps necessari per processar el codi, es nota una diferència molt gran entre els dispositius mòbils i d'escriptori.
Augment del temps (en percentatge) relacionat amb el processament d'scripts en dispositius mòbils en comparació amb els d'escriptori
Percentils
10
25
50
75
90
Tots els llocs
144.1
172.8
185.5
208.5
224.0
Llocs jQuery
188.2
187.4
191.3
209.6
221.9
Llocs web de Vue
222.5
220.8
220.2
221.4
220.4
Webs angulars
205.1
206.0
201.6
210.4
218.7
Webs de reaccions
431.5
386.8
337.9
242.6
179.6
Tot i que és d'esperar alguna diferència en la velocitat de processament de codi entre un telèfon i un ordinador portàtil, xifres tan grans em diuen que els marcs moderns no estan prou orientats a dispositius de baix consum i al desig de tancar la bretxa que s'ha identificat. Fins i tot al percentil 10, els llocs de React passen un 431.5% més de temps al fil principal mòbil que al fil principal de l'escriptori. jQuery té la bretxa més petita, però fins i tot aquí la xifra corresponent és del 188.2%. Quan els desenvolupadors de llocs web fan els seus projectes de tal manera que requereixen més temps de CPU per processar-los (i això és el que passa, i només empitjora amb el temps), els propietaris de dispositius de baix consum han de pagar-ho.
Resultats de
Els bons marcs haurien de proporcionar als desenvolupadors una bona base per crear projectes web (en termes de seguretat, accessibilitat, rendiment) o haurien de tenir restriccions incorporades que dificultin la creació d'alguna cosa que infringeixi aquestes restriccions.
Això no sembla aplicar-se al rendiment dels projectes web (i pel que sembla als seus ).
Val la pena assenyalar que només perquè els llocs React o Angular dediquin més temps de CPU a preparar codi que altres no vol dir necessàriament que els llocs React siguin més intensius en CPU que els llocs Vue quan s'executen. De fet, les dades que hem analitzat diuen molt poc sobre el rendiment operatiu dels marcs i les biblioteques. Parlen més dels enfocaments de desenvolupament als quals, conscientment o no, aquests frameworks poden impulsar els programadors. Estem parlant de documentació per a marcs, el seu ecosistema i tècniques de desenvolupament comunes.
També val la pena esmentar una cosa que no hem analitzat aquí, és a dir, quant de temps passa el dispositiu executant codi JavaScript quan fa la transició entre les pàgines del lloc. L'argument a favor de l'SPA és que un cop carregada l'aplicació d'una sola pàgina al navegador, l'usuari, en teoria, podrà accedir a les pàgines del lloc més ràpidament. La meva pròpia experiència em diu que això està lluny de ser un fet. Però no tenim dades per aclarir aquesta qüestió.
El que està clar és que si utilitzeu un marc o una biblioteca per crear un lloc web, esteu fent un compromís a l'hora de carregar inicialment el projecte i preparar-lo per començar. Això s'aplica fins i tot als escenaris més positius.
En les situacions adequades, és totalment possible fer alguns compromisos, però és important que els desenvolupadors facin aquests compromisos de manera conscient.
Però també tenim motius per a l'optimisme. M'anima la proximitat que els desenvolupadors de Chrome treballen amb els que hi ha darrere d'algunes de les eines frontals que hem cobert per ajudar a millorar el rendiment d'aquestes eines.
Tanmateix, sóc una persona pragmàtica. Les noves arquitectures creen problemes de rendiment tan sovint com els solucionen. I es necessita temps per eliminar les mancances. Igual que això no ens hem d'esperar solucionarà tots els problemes de rendiment, no hauríeu d'esperar això de les noves versions dels nostres frameworks preferits.
Si voleu utilitzar una de les eines de front-end que es comenten en aquest material, això vol dir que haureu de fer esforços addicionals per assegurar-vos que, de passada, no perjudiqueu el rendiment del vostre projecte. Aquí teniu algunes consideracions a tenir en compte abans de començar a utilitzar un marc nou:
- Comproveu-vos amb sentit comú. Realment necessiteu utilitzar el marc escollit? El JavaScript pur pot fer molt avui.
- Hi ha una alternativa més lleugera al marc que trieu (com Preact, Svelte o una altra cosa) que us pugui oferir el 90% de les capacitats d'aquest marc?
- Si ja esteu utilitzant un marc, penseu si hi ha alguna cosa que ofereix opcions estàndard millors, més conservadores (per exemple, Nuxt.js en lloc de Vue, Next.js en lloc de React, etc.).
- Què serà el teu Rendiment de JavaScript?
- Com pots procés de desenvolupament perquè sigui més difícil introduir més codi JavaScript en un projecte del que és absolutament necessari?
- Si utilitzeu un marc per facilitar el desenvolupament, tingueu en compte enviar codi marc als clients. Potser podeu resoldre tots els problemes del servidor?
En general, val la pena examinar-les amb més detall, independentment del que trieu exactament per desenvolupar el front-end. Però són especialment importants quan esteu treballant en un projecte que no té rendiment per començar.
Benvolguts lectors! Quin creus que és el marc de JavaScript ideal?
Font: www.habr.com