Ez dago webgune bat moteltzeko modu azkarragorik (joko-jokoan) bertan JavaScript kode mordoa erabiltzea baino. JavaScript erabiltzean, lau aldiz baino gutxiago proiektuen errendimenduarekin ordaindu behar duzu. Hona hemen guneko JavaScript kodeak erabiltzaileen sistemak nola kargatzen dituen:
- Fitxategi bat saretik deskargatzea.
- Deskargatu ondoren deskargatutako iturburu-kodea analizatu eta konpilatu.
- JavaScript kodearen exekuzioa.
- Memoria-kontsumoa.
Konbinazio hau bihurtzen da .
Eta gero eta JS kode gehiago sartzen dugu gure proiektuetan. Erakundeak React, Vue eta beste bezalako esparru eta liburutegiek bultzatutako guneetara joaten diren heinean, guneen oinarrizko funtzionaltasuna JavaScript-en oso menpe jartzen ari gara.
Oso gune astun asko ikusi ditut JavaScript esparruak erabiltzen. Baina nire gaiaren ikuspegia oso alboragarria da. Kontua da lan egiten dudan enpresek nigana jotzen dutela, hain zuzen, guneen errendimenduaren alorrean arazo konplexuak dituztelako. Ondorioz, jakin-mina piztu zitzaidan arazo hau zein ohikoa den, eta gune jakin baten oinarri gisa esparru bat edo beste aukeratzen dugunean zer nolako "zigorra" ordaintzen ditugun.
Proiektuak hori asmatzen lagundu dit. .
Datu
HTTP Archive proiektuak guztira 4308655 esteka egiten ditu ohiko mahaigaineko guneetara eta 5484239 esteka mugikorretarako guneetara. Esteka hauekin lotutako neurketa askoren artean dagozkien guneetan aurkitutako teknologien zerrenda dago. Horrek esan nahi du hainbat esparru eta liburutegi erabiltzen dituzten milaka gune lagin ditzakegula eta bezeroei zenbat kode bidaltzen dieten eta kode honek erabiltzaileen sistemetan zenbat karga sortzen duen jakin dezakegu.
2020ko martxoko datuak bildu nituen, eskura izan nituen datu berrienak.
Webgune guztietako HTTP Artxiboko datu agregatuak React, Vue eta Angular erabiliz aurkitutako guneetako datuekin alderatzea erabaki nuen, nahiz eta beste iturri-materiala ere erabiltzea pentsatu nuen.
Interesgarriagoa izan dadin, jQuery erabiltzen duten guneak ere gehitu ditut iturriko datu multzoan. Liburutegi hau oso ezaguna da oraindik. Era berean, React, Vue eta Angular-ek eskaintzen duten orrialde bakarreko aplikazioaren (SPA) eredua baino ikuspegi ezberdin bat aurkezten du web garapenerako.
HTTP Artxiboko estekak teknologia interesgarriak erabiltzen ari direla aurkitu duten guneak adierazten dituztenak
Esparrua edo liburutegia
Mugikorrentzako guneetarako estekak
Ohiko guneetarako estekak
jQuery
4615474
3714643
Erreakzionatzeko
489827
241023
ikuspegi
85649
43691
Angeluen
19423
18088
Itxaropenak eta ametsak
Datuen azterketara pasatu baino lehen, espero nahiko nukeenari buruz hitz egin nahi dut.
Nire ustez, mundu ideal batean, esparruak garatzaileen beharrak asetzeaz harago joan beharko lirateke eta gure guneekin lan egiten duen erabiltzaile arruntari onura zehatz batzuk eman beharko lioketela. Errendimendua abantaila horietako bat besterik ez da. Hor sartzen dira irisgarritasuna eta segurtasuna. Baina hau garrantzitsuena baino ez da.
Beraz, mundu ideal batean, nolabaiteko esparru batek errendimendu handiko gune bat sortzea erraztu beharko luke. Hau egin beharko litzateke esparruak sustatzaileari proiektu bat eraikitzeko oinarri duin bat ematen diolako, edo garapenean murrizketak ezartzen dituelako, bilakatzen den zerbaiten garapena zailtzen duten eskakizunak ezartzen dituelako. motela izatera.
Esparru onenek biak egin beharko lituzkete: oinarri ona eman, eta lanari mugak ezarri, emaitza duin bat lortzeko aukera emanez.
Datuen mediana-balioak aztertzeak ez digu behar dugun informazioa emango. Eta, hain zuzen ere, ikuspegi honek gure arretatik kanpo uzten du . Horren ordez, nituen datuetatik ehunekoak atera ditut. Hauek 10, 25, 50 (mediana), 75, 90 pertzentilak dira.
Batez ere 10. eta 90. pertzentileak interesatzen zaizkit. 10. pertzentilak errendimendurik onena adierazten du (edo, gutxienez, hoberenetik hurbilago edo gutxi gorabehera) esparru jakin baterako. Beste era batera esanda, horrek esan nahi du esparru jakin bat erabiltzen duten guneen % 10ek baino ez dutela maila honetara iristen, edo gorago. 90. pertzentilea, berriz, txanponaren beste aldea da - gauzak zein txarrak izan daitezkeen erakusten digu. 90. pertzentilea atzean geratzen diren guneak dira: JS kode gehien edo hari nagusian kodea prozesatzeko denbora gehien duten guneen beheko %10a.
JavaScript kodearen bolumenak
Hasteko, zentzuzkoa da gune ezberdinek sarean zehar transmititzen duten JavaScript kodearen tamaina aztertzea.
Gailu mugikorretara transferitutako JavaScript kodearen kopurua (Kb).
Pertzentilak
10
25
50
75
90
Gune guztiak
93.4
196.6
413.5
746.8
1201.6
jQuery guneak
110.3
219.8
430.4
748.6
1162.3
Vue guneak
244.7
409.3
692.1
1065.5
1570.7
Gune angeluarrak
445.1
675.6
1066.4
1761.5
2893.2
Erreakzio Guneak
345.8
441.6
690.3
1238.5
1893.6
Gailu mugikorretara bidalitako JavaScript kodearen kopurua
Mahaigaineko gailuetara transferitutako JavaScript kodearen kopurua (Kb).
Pertzentilak
10
25
50
75
90
Gune guztiak
105.5
226.6
450.4
808.8
1267.3
jQuery guneak
121.7
242.2
458.3
803.4
1235.3
Vue guneak
248.0
420.1
718.0
1122.5
1643.1
Gune angeluarrak
468.8
716.9
1144.2
1930.0
3283.1
Erreakzio Guneak
308.6
469.0
841.9
1472.2
2197.8
Mahaigaineko gailuetara bidalitako JavaScript kodearen kopurua
Guneek gailuetara bidaltzen duten JS kodearen tamainari buruz bakarrik hitz egiten badugu, dena espero dezakezun bezala ikusten da. Hots, esparruetako bat erabiltzen bada, horrek esan nahi du egoera ideal batean ere gunearen JavaScript kodearen bolumena handituko dela. Ez da harritzekoa: ezin duzu JavaScript esparru bat gune baten oinarri bihurtu eta proiektuaren JS kodearen bolumena oso baxua izango dela espero.
Datu horiei buruz aipagarria dena da esparru eta liburutegi batzuk proiektu baterako beste batzuk baino abiapuntu hobetzat har daitezkeela. jQuery duten guneek itxurarik onena dute. Guneen mahaigaineko bertsioetan, gune guztiek baino %15 JavaScript gehiago dute, eta mugikorrean %18 gehiago. (Aitortu ere, hemen datuen ustelkeriaren bat dago. Izan ere, jQuery gune askotan dagoela, eta, beraz, naturala da horrelako guneak beste batzuk baino estuago lotuta egotea gune kopuru osoarekin. Hala ere, horrek ez du eragiten nola gordina. esparru bakoitzeko datuak ateratzen dira.)
Kode-bolumenaren %15-18ko igoera zifra nabarmena den arren, beste esparru eta liburutegiekin alderatuz gero, jQuery-k kobratzen duen "zerga" oso baxua dela ondoriozta daiteke. 10. pertzentileko gune angeluarrak gune guztiek baino %344 datu gehiago bidaltzen dituzte mahaigainera, eta %377 gehiago mugikorrera. React guneak dira hurrengo astunenak, gune guztietan baino %193 kode gehiago mahaigainera bidaltzen baitute eta %270 gehiago mugikorrera.
Lehenago aipatu nuen marko bat erabiltzeak proiektuan kode kopuru bat sartuko dela esan nahi badu ere, lanaren hasieran, espero dut esparrua nolabait garatzailea mugatzeko gai dela. Bereziki, kode gehieneko kopurua mugatzeaz ari gara.
Interesgarria da jQuery guneek ideia hau jarraitzen dutela. 10. pertzentileko gune guztiak baino zertxobait astunagoak diren arren (% 15-18), 90. pertzentilean apur bat arinagoak dira % 3 inguruan bai mahaigainean bai mugikorrean. Horrek ez du esan nahi oso onura esanguratsua denik, baina esan daiteke jQuery guneek, behintzat, ez dutela JavaScript kode tamaina handirik, bertsio handienetan ere.
Baina ezin da gauza bera esan beste esparru batzuei buruz.
10. pertzentilaren kasuan bezala, 90. pertzentilean Angular eta React-eko guneak desberdinak dira beste guneetatik, baina, zoritxarrez, txarrerako desberdinak dira.
90. pertzentilean, Angular guneek gune guztiek baino %141 datu gehiago bidaltzen dituzte mugikorrera, eta %159 gehiago mahaigainera. React guneek gune guztiek baino %73 gehiago bidaltzen dute mahaigainera, eta %58 gehiago mugikorrera. 90. pertzentileko React guneen kodearen tamaina 2197.8 KB da. Horrek esan nahi du gune horiek Vue-n oinarritutako hurbilen dauden lehiakideek baino 322.9 KB datu gehiago bidaltzen dituztela gailu mugikorrei. Angular eta React-en eta beste gune batzuen arteko aldea are handiagoa da. Adibidez, mahaigaineko React guneek 554.7 KB JS kode gehiago bidaltzen dituzte gailuetara Vue gune baliokideek baino.
JavaScript kodea prozesatzeko behar den denbora hari nagusian
Goiko datuek argi adierazten dute aztergai dauden esparruak eta liburutegiak erabiltzen dituzten guneek JavaScript kode kopuru handia dutela. Baina, noski, hori gure ekuazioaren zati bat besterik ez da.
JavaScript kodea arakatzailera iritsi ondoren, egoera erabilgarri batera eraman behar da. Batez ere, arazo asko nabigatzaile nagusiko hari kodearekin egin behar diren ekintzak sortzen dituzte. Hari nagusia erabiltzaileen ekintzak prozesatzeaz, estiloak kalkulatzeaz, orriaren diseinua eraikitzeaz eta bistaratzeaz arduratzen da. Hari nagusia JavaScript zereginekin gainditzen baduzu, ez du aukera izango gainerako zereginak garaiz betetzeko. Horrek atzerapenak eta "balaztak" eragiten ditu orrialdeen lanetan.
HTTP Archive datu-baseak JavaScript kodea prozesatzeko zenbat denbora behar duen informazioa du V8 motorren hari nagusian. Horrek esan nahi du datu hauek bil ditzakegula eta hari nagusiak zenbat denbora behar duen jakiteko hainbat gunetako JavaScript prozesatzeko.
Prozesadorearen denbora (milisegundotan) gailu mugikorretan script-en prozesamenduarekin erlazionatuta
Pertzentilak
10
25
50
75
90
Gune guztiak
356.4
959.7
2372.1
5367.3
10485.8
jQuery guneak
575.3
1147.4
2555.9
5511.0
10349.4
Vue guneak
1130.0
2087.9
4100.4
7676.1
12849.4
Gune angeluarrak
1471.3
2380.1
4118.6
7450.8
13296.4
Erreakzio Guneak
2700.1
5090.3
9287.6
14509.6
20813.3
Gailu mugikorretan script-en prozesamenduarekin erlazionatutako prozesadorearen denbora
Mahaigaineko gailuetan script-en prozesamenduarekin erlazionatutako prozesadorearen denbora (milisegundotan).
Pertzentilak
10
25
50
75
90
Gune guztiak
146.0
351.8
831.0
1739.8
3236.8
jQuery guneak
199.6
399.2
877.5
1779.9
3215.5
Vue guneak
350.4
650.8
1280.7
2388.5
4010.8
Gune angeluarrak
482.2
777.9
1365.5
2400.6
4171.8
Erreakzio Guneak
508.0
1045.6
2121.1
4235.1
7444.3
Mahaigaineko gailuetan script-en prozesamenduarekin erlazionatutako prozesadorearen denbora
Hemen oso ezaguna den zerbait ikus dezakezu.
Hasteko, jQuery duten guneek JavaScript prozesatzeko hari nagusian beste gune batzuek baino askoz gutxiago gastatzen dute. 10. pertzentilean, gune guztiekin alderatuta, mugikorreko jQuery guneek % 61 denbora gehiago ematen dute JS kodea hari nagusian prozesatzen. Mahaigaineko jQuery guneen kasuan, prozesatzeko denbora % 37 handitzen da. 90. pertzentilean, jQuery guneek puntuazio agregatuetatik oso gertu lortzen dute. Zehazki, gailu mugikorretako jQuery guneek gune guztietan baino % 1.3 denbora gutxiago ematen dute hari nagusian, eta % 0.7 denbora gutxiago mahaigaineko gailuetan.
Gure balorazioaren beste aldean hari nagusian karga handiena duten esparruak daude. Hau da, berriro ere, Angular eta React. Bien arteko desberdintasun bakarra da Angular-ek React guneek baino kode gehiago bidaltzen dituzten arakatzaileei, Angular-ek CPU denbora gutxiago behar duela kodea prozesatzeko. Askoz gutxiago.
10. pertzentilean, mahaigaineko Angular guneek % 230 denbora gehiago ematen dute JS kodea prozesatzen hari nagusian gune guztiek baino. Gune mugikorretarako, kopuru hori %313 da. React guneak dira errendimendurik txarrenak. Mahaigainean, gune guztiek baino % 248 denbora gehiago ematen dute kodea prozesatzen, eta % 658 gehiago mugikorrean. %658a ez da akatsa. 10. pertzentilean, React guneek 2.7 segundo igarotzen dituzte hari nagusiaren denbora beren kodea prozesatzen.
90. pertzentilak, kopuru handi horiekin alderatuta, itxura hobea du behintzat. Gune guztiekin alderatuta, Angular proiektuek % 29 denbora gehiago ematen dute mahaigaineko gailuetan hari nagusian, eta % 27 denbora gehiago gailu mugikorretan. React guneen kasuan, zifra berdinak %130 eta %98koak dira, hurrenez hurren.
90. pertzentilaren desbideratze ehunekoek 10. pertzentilaren antzeko balioek baino hobeto ikusten dute. Baina hemen merezi du gogoratzea ordua adierazten duten zenbakiek nahiko beldurgarriak diruditela. Demagun 20.8 segundo mugikorreko hari nagusian React-ekin eraikitako webgune baterako. (Uste dut garai honetan benetan gertatzen denaren istorioa aparteko artikulu bat merezi duela).
Hemen konplikazio potentzial bat dago (eskerrik asko ezaugarri honi arreta erakartzeagatik, eta datuak ikuspuntu horretatik arretaz kontuan hartzeagatik). Kontua da gune askok frontend-eko hainbat tresna erabiltzen dituztela. Bereziki, React edo Vuerekin batera jQuery erabiltzen duten gune asko ikusi ditut, gune horiek jQuerytik beste esparru edo liburutegi batzuetara migratzen ari baitira. Ondorioz, datu-basea jo dut berriro, oraingoan React, jQuery, Angular edo Vue soilik erabiltzen dituzten guneei dagozkien estekak soilik hautatuz, baina ez horien konbinaziorik. Hona hemen lortu dudana.
Prozesadorearen denbora (milisegundotan) gailu mugikorretan script-ak prozesatzearekin erlazionatutako guneek marko bakarra edo liburutegi bakarra erabiltzen duten egoera batean
Pertzentilak
10
25
50
75
90
jQuery bakarrik erabiltzen duten guneak
542.9
1062.2
2297.4
4769.7
8718.2
Vue bakarrik erabiltzen duten guneak
944.0
1716.3
3194.7
5959.6
9843.8
Angular bakarrik erabiltzen duten guneak
1328.9
2151.9
3695.3
6629.3
11607.7
React soilik erabiltzen duten guneak
2443.2
4620.5
10061.4
17074.3
24956.3
Gailu mugikorretan script-ak prozesatzearekin erlazionatutako prozesadorearen denbora, guneek marko bakarra edo liburutegi bakarra erabiltzen duten egoeran
Lehenik eta behin, harritzekoa ez dena: gune batek esparru edo liburutegi bakarra erabiltzen duenean, gune horren errendimendua hobetzen da maizago. Instrumentu bakoitzak hobeto funtzionatzen du 10. eta 25. pertzentiletan. Zentzuzkoa du. Esparru bat erabiliz egiten den gune batek bi esparru edo liburutegi edo gehiago erabiliz egiten den gune batek baino hobeto funtzionatuko luke.
Izan ere, aztertutako front-end tresna bakoitzaren errendimenduak itxura hobea du kasu guztietan, salbuespen bitxi bat izan ezik. Harritu ninduena zera izan zen: 50. pertzentilean eta gorago, React erabiltzen duten guneek okerrago funtzionatzen dutela React erabiltzen duten liburutegi bakarra denean. Hori izan da, bide batez, datu hauek hemen aurkezteko arrazoia.
Arraro samarra da hau, baina hala ere bitxikeria horri azalpena bilatzen saiatuko naiz.
Proiektu batek React eta jQuery erabiltzen baditu, litekeena da proiektu hori jQuery-tik React-erako trantsizioaren erdialdean egotea. Agian liburutegi hauek nahasten diren kode-base bat du. Dagoeneko ikusi dugunez jQuery guneek React guneek baino denbora gutxiago ematen dutela hari nagusian, horrek esan lezake jQuery-n funtzionalitate batzuk inplementatzeak guneak pixka bat hobetzen laguntzen duela.
Baina proiektua jQuery-tik React-era igarotzen den heinean eta React-en gehiago oinarritzen den heinean, gauzak aldatzen ari dira. Gunea oso ondo egina badago eta gunearen garatzaileek React arretaz erabiltzen badute, dena ondo egongo da gune horrekin. Baina batez besteko React gunerako, React-en erabilera zabalak esan nahi du hari nagusia karga handian dagoela.
Mugikorren eta mahaigaineko gailuen arteko aldea
Ikertutako datuak aztertu ditudan beste ikuspuntu bat izan da gailu mugikor eta mahaigaineko guneekin lan egitearen artean zenbateraino dagoen aldea aztertzea. JavaScript kodearen bolumenak alderatzeaz hitz egiten badugu, konparaketa horrek ez du ezer ikaragarririk erakusten. Noski, polita izango litzateke deskargatzeko kode kopuru txikiagoak ikustea, baina ez dago alde handirik mugikorraren eta mahaigaineko kodearen kopuruan.
Baina kodea prozesatzeko behar den denbora aztertzen badugu, mugikorren eta mahaigaineko gailuen artean oso tarte handia nabaritzen da.
Gailu mugikorretan script-ak prozesatzearekin erlazionatutako denbora-gehikuntza (ehunekoa) mahaigainarekin alderatuta
Pertzentilak
10
25
50
75
90
Gune guztiak
144.1
172.8
185.5
208.5
224.0
jQuery guneak
188.2
187.4
191.3
209.6
221.9
Vue guneak
222.5
220.8
220.2
221.4
220.4
Gune angeluarrak
205.1
206.0
201.6
210.4
218.7
Erreakzio Guneak
431.5
386.8
337.9
242.6
179.6
Telefono baten eta ordenagailu eramangarri baten arteko kodea prozesatzeko abiaduran desberdintasunen bat espero den arren, kopuru handiek esaten didate esparru modernoak ez daudela nahikoa potentzia baxuko gailuetara zuzenduta, eta aurkitu duten hutsunea ixten saiatzen ari direla. 10. pertzentilean ere, React guneek % 431.5 denbora gehiago ematen dute mugikorreko hari nagusian mahaigaineko hari nagusian baino. jQuery-k du hutsunerik txikiena, baina hemen ere dagokion zifra % 188.2 da. Webguneetako garatzaileek beren proiektuak prozesatzeko prozesadorearen denbora gehiago behar duten moduan egiten dituztenean (eta gertatzen da, eta denborarekin okerrera egiten da), potentzia gutxiko gailuen jabeek ordaindu behar dute.
Emaitzak
Esparru onek garatzaileei web proiektuak eraikitzeko oinarri on bat eman behar diete (segurtasunari, irisgarritasunari, errendimenduari dagokionez), edo murrizketak barneratu beharko lituzkete, murrizketa horiek urratzen dituen zerbait eraikitzea zaila egiten dutenak.
Hau ez dirudi web-proiektuen errendimenduari aplikatzen (eta, ziurrenik, ez haien ).
Aipatzekoa da React edo Angular guneek besteek baino CPU denbora gehiago ematen dutelako kodea prestatzen ez dutela zertan esan nahi React guneak Vue guneak baino CPU intentsiboagoak direnik exekutatzen ari diren bitartean. Izan ere, aztertu ditugun datuek oso gutxi esaten dute esparruen eta liburutegien funtzionamendu-errendimenduari buruz. Gehiago hitz egiten dute, kontzienteki edo ez, esparru hauek programatzaileak bultza ditzaketen garapen-ikuspegiei buruz. Esparruetarako dokumentazioaz ari gara, haien ekosistemaz, garapen teknika arruntez.
Aipatzekoa da hemen aztertu ez dugun zerbait ere, hots, gailuak zenbat denbora ematen duen JavaScript kodea exekutatzen guneko orrialdeen artean nabigatzean. SPAren aldeko argudioa da orrialde bakarreko aplikazioa nabigatzailean kargatu ondoren, erabiltzaileak teorian guneko orriak azkarrago ireki ahal izango dituela. Nire esperientziak dio hori errealitatetik urrun dagoela. Baina ez dugu gai hau argitzeko daturik.
Argi dagoena da webgune bat sortzeko esparru edo liburutegi bat erabiltzen ari bazara, hasiera batean proiektua kargatzeko eta martxan jartzeko prest dagoen konpromisoa hartzen ari zarela. Hau agertoki positiboenetan ere aplikatzen da.
Oso posible da egoera egokietan konpromiso batzuk egitea, baina garrantzitsua da garatzaileek horrelako konpromisoak kontzienteki egitea.
Baina baikortasunerako arrazoiak ere baditugu. Ilusio handiz ikusten dut Chrome-ko garatzaileek nola lan egiten duten tresna horien errendimendua hobetzen laguntzeko aztertu ditugun frontend-tresna batzuen garatzaileekin.
Hala ere, pertsona pragmatikoa naiz. Arkitektura berriek errendimendu arazoak konpontzen dituzten bezain maiz sortzen dituzte. Eta akatsak konpontzeko denbora behar da. Espero ez genukeen bezala errendimendu-arazo guztiak konponduko ditu, ez zenuke hori espero gure marko gogokoen bertsio berrietatik.
Artikulu honetan eztabaidatutako frontend-tresnetako bat erabili nahi baduzu, zure proiektuaren errendimenduari kalterik ez egiteko ahalegin handia egin behar duzula esan nahi du. Hona hemen esparru berri bat hasi aurretik kontuan hartu beharreko gogoeta batzuk:
- Probatu zeure burua sen onarekin. Benetan erabili behar al duzu aukeratutako markoa? Gaur egun JavaScript hutsa asko egiteko gai da.
- Ba al dago aukeratutako esparruaren (Preact, Svelte edo beste zerbait) alternatiba arinagoa, esparru honen gaitasunen %90 eman diezazukeen?
- Dagoeneko esparru bat erabiltzen ari bazara, kontuan hartu aukera estandar hobeak, kontserbadoreagoak eta estandarrak eskaintzen dituen zerbait (adibidez, Nuxt.js Vue-ren ordez, Next.js-en ordez React-en, eta abar).
- Zein izango da zure JavaScript errendimendua?
- Nola egin dezakezu garapen prozesu bat proiektu batean JavaScript kode gehiago sartzea beharrezkoa baino zailagoa izan dadin?
- Garapen errazteko esparru bat erabiltzen ari bazara, kontuan hartu bidali esparru-kodea bezeroei. Agian zerbitzariko arazo guztiak konpondu ditzakezu?
Normalean ideia hauek ikustea merezi dute, front-end garapenerako aukeratu duzuna kontuan hartu gabe. Baina bereziki garrantzitsuak dira hasiera-hasieratik errendimendu falta duen proiektu batean lanean ari zarenean.
Irakurle maitea! Nola ikusten duzu JavaScript esparru ideala?
Iturria: www.habr.com