Það er engin hraðari leið til að hægja á vefsíðu (orðaleikur ætlaður) en að nota fullt af JavaScript kóða á hana. Þegar JavaScript er notað þarftu að borga fyrir það með frammistöðu verkefna ekki sjaldnar en fjórum sinnum. Hér er hvernig JavaScript kóða síðunnar hleður kerfi notenda:
- Að sækja skrá yfir netið.
- Að flokka og setja saman ópakkaðan frumkóða eftir niðurhal.
- Framkvæmd JavaScript kóða.
- Minnisnotkun.
Þessi samsetning kemur í ljós .
Og við tökum fleiri og fleiri JS kóða inn í verkefnin okkar. Þegar stofnanir færast í átt að síðum sem knúnar eru af ramma og bókasöfnum eins og React, Vue og fleiri, erum við að gera kjarnavirkni vefsvæða mjög háð JavaScript.
Ég hef séð margar mjög þungar síður sem nota JavaScript ramma. En sýn mín á málið er mjög hlutdræg. Staðreyndin er sú að fyrirtækin sem ég vinn með leita til mín einmitt vegna þess að þau standa frammi fyrir flóknum vandamálum á sviði frammistöðu vefsvæða. Fyrir vikið varð ég forvitinn um hversu algengt þetta vandamál er og hvers konar „viðurlög“ við greiðum þegar við veljum einn eða annan ramma sem grunn fyrir ákveðna síðu.
Verkefnið hjálpaði mér að finna út úr þessu. .
Gögn
HTTP Archive verkefnið rekur samtals 4308655 tengla á venjulegar skrifborðssíður og 5484239 tengla á farsímasíður. Meðal margra mælikvarða sem tengjast þessum tenglum er listi yfir tækni sem finnast á viðkomandi síðum. Þetta þýðir að við getum tekið sýnishorn af þúsundum vefsvæða sem nota ýmsa ramma og bókasöfn og lært um hversu mikinn kóða þeir senda til viðskiptavina og hversu mikið álag þessi kóði skapar á kerfi notenda.
Ég safnaði gögnum fyrir mars 2020, sem voru nýjustu gögnin sem ég hafði aðgang að.
Ég ákvað að bera saman uppsöfnuð HTTP skjalasafn á öllum vefsvæðum við gögn frá síðum sem fundust með React, Vue og Angular, þó ég hafi líka íhugað að nota annað frumefni.
Til að gera það áhugaverðara bætti ég líka síðum sem nota jQuery við upprunagagnasettið. Þetta bókasafn er enn mjög vinsælt. Það kynnir einnig aðra nálgun við vefþróun en Single Page Application (SPA) líkanið sem React, Vue og Angular bjóða upp á.
Tenglar í HTTP skjalasafninu sem tákna síður sem hafa reynst nota tækni sem vekur áhuga
Rammi eða bókasafn
Tenglar á farsímasíður
Tenglar á venjulegar síður
jQuery
4615474
3714643
Bregðast
489827
241023
Vue
85649
43691
Stækkun
19423
18088
Vonir og draumar
Áður en við förum yfir í gagnagreiningu vil ég tala um það sem ég myndi vilja vonast eftir.
Ég tel að í hugsjónum heimi ættu rammar að ganga lengra en að mæta þörfum þróunaraðila og veita meðalnotandanum sem vinnur með vefsvæðum okkar einhvern sérstakan ávinning. Frammistaða er aðeins einn af þessum kostum. Þar kemur aðgengi og öryggi við sögu. En þetta er aðeins það mikilvægasta.
Svo, í hugsjónum heimi, ætti einhvers konar rammi að gera það auðvelt að búa til afkastamikla síðu. Þetta á annaðhvort að gerast vegna þess að umgjörðin veitir framkvæmdaraðila sómasamlegan grunn til að byggja verkefni á, eða vegna þess að hún setur hömlur á uppbyggingu, setur fram kröfur til þess sem torvelda þróun á einhverju sem snýr. út að vera hægur.
Bestu umgjörðirnar ættu að gera bæði: gefa góðan grunn og setja takmarkanir á vinnuna, sem gerir þér kleift að ná ágætis árangri.
Að greina miðgildi gagnanna mun ekki gefa okkur þær upplýsingar sem við þurfum. Og í raun fer þessi nálgun út úr athygli okkar . Þess í stað dró ég prósentur úr þeim gögnum sem ég hafði. Þetta eru 10, 25, 50 (miðgildi), 75, 90 hundraðshlutar.
Ég hef sérstaklega áhuga á 10. og 90. hundraðshlutum. 10. hundraðshluti táknar bestu frammistöðu (eða að minnsta kosti meira og minna nálægt því besta) fyrir tiltekið ramma. Með öðrum orðum, þetta þýðir að aðeins 10% vefsvæða sem nota tiltekna ramma komast á þetta stig, eða hærra. 90. hundraðshlutinn er hins vegar hin hliðin á peningnum - það sýnir okkur hversu slæmt hlutirnir geta orðið. 90. hundraðshlutinn eru síðurnar sem eru á eftir – þær neðstu 10% vefsvæða sem hafa mestan JS kóða eða lengstan tíma til að vinna úr kóðanum sínum á aðalþræðinum.
Magn af JavaScript kóða
Til að byrja með er skynsamlegt að greina stærð JavaScript kóðans sem send er frá mismunandi síðum um netið.
Magn JavaScript kóða (Kb) sem er flutt í fartæki
Prósentíla
10
25
50
75
90
Allar síður
93.4
196.6
413.5
746.8
1201.6
jQuery síður
110.3
219.8
430.4
748.6
1162.3
Vue síður
244.7
409.3
692.1
1065.5
1570.7
Hyrndar síður
445.1
675.6
1066.4
1761.5
2893.2
Viðbragðssíður
345.8
441.6
690.3
1238.5
1893.6
Magn JavaScript kóða sem sent er í fartæki
Magn JavaScript kóða (Kb) flutt yfir á borðtölvur
Prósentíla
10
25
50
75
90
Allar síður
105.5
226.6
450.4
808.8
1267.3
jQuery síður
121.7
242.2
458.3
803.4
1235.3
Vue síður
248.0
420.1
718.0
1122.5
1643.1
Hyrndar síður
468.8
716.9
1144.2
1930.0
3283.1
Viðbragðssíður
308.6
469.0
841.9
1472.2
2197.8
Magn JavaScript kóða sem sendur er á borðtölvur
Ef við tölum aðeins um stærð JS kóðans sem síður senda í tæki, þá lítur allt út eins og þú gætir búist við. Það þýðir nefnilega að ef eitthvert ramma er notað þýðir það að jafnvel við kjöraðstæður mun rúmmál JavaScript kóða síðunnar aukast. Þetta kemur ekki á óvart - þú getur ekki gert JavaScript ramma að grunni síðunnar og búist við því að magn JS kóða verkefnisins verði mjög lítið.
Það sem er merkilegt við þessi gögn er að sum umgjörð og bókasöfn geta talist betri upphafspunktur fyrir verkefni en önnur. Síður með jQuery líta best út. Á borðtölvuútgáfum vefsvæða innihalda þær 15% meira JavaScript en allar síður og í farsímum innihalda þær 18% meira. (Að vísu er einhver gagnaspilling hér. Staðreyndin er sú að jQuery er til staðar á mörgum síðum, svo það er eðlilegt að slíkar síður séu nánar en aðrar tengdar heildarfjölda vefsvæða. Þetta hefur hins vegar ekki áhrif á hversu hráefni gögn eru framleidd fyrir hvern ramma.)
Þó að 15-18% aukning á kóðamagni sé athyglisverð tala, þegar þetta er borið saman við önnur ramma og bókasöfn, má álykta að „skatturinn“ sem jQuery leggur á sé mjög lágur. Hornsíður á 10. hundraðshluta senda 344% meiri gögn á skjáborð en allar síður og 377% meira til farsíma. React síður eru næst þyngstar, senda 193% meiri kóða á skjáborð en allar síður og 270% meira til farsíma.
Áðan nefndi ég að þó að nota ramma þýði að ákveðið magn af kóða verði innifalið í verkefninu, strax í upphafi vinnu við það, þá vona ég að ramminn geti á einhvern hátt takmarkað þróunaraðilann. Sérstaklega erum við að tala um að takmarka hámarksmagn kóða.
Athyglisvert er að jQuery síður fylgja þessari hugmynd. Þó að þær séu örlítið þyngri en allar síður á 10. hundraðshlutanum (um 15-18%), eru þær aðeins léttari á 90. hundraðshlutanum í kringum 3% bæði á tölvum og farsímum. Þetta er ekki þar með sagt að þetta sé mjög verulegur ávinningur, en það má segja að jQuery síður hafi að minnsta kosti ekki miklar JavaScript kóðastærðir, jafnvel í stærstu útgáfunum.
En það sama verður ekki sagt um aðra ramma.
Rétt eins og í tilfelli 10. hundraðshlutans, á 90. hundraðshlutanum eru síður á Angular og React frábrugðnar öðrum síðum, en þeir eru því miður ólíkir til hins verra.
Á 90. hundraðshlutanum senda Angular síður 141% meiri gögn til farsíma en allar síður og 159% meira til tölvu. React síður senda 73% meira til skjáborðs en allar síður og 58% meira til farsíma. Kóðastærð React síðna á 90. hundraðshlutanum er 2197.8 KB. Þetta þýðir að slíkar síður senda 322.9 KB meiri gögn í fartæki en nánustu keppinautar þeirra byggt á Vue. Bilið á milli skrifborðsvefsíðna byggðar á Angular og React og annarra vefsvæða er enn stærra. Til dæmis senda skjáborðs React síður 554.7 KB meiri JS kóða til tækja en sambærilegar Vue síður.
Tími sem það tekur að vinna JavaScript kóða í aðalþræðinum
Ofangreind gögn gefa greinilega til kynna að síður sem nota ramma og bókasöfn sem eru til rannsóknar innihalda mikið magn af JavaScript kóða. En auðvitað er þetta bara einn hluti af jöfnu okkar.
Eftir að JavaScript kóðinn er kominn í vafrann þarf að koma honum í nothæft ástand. Sérstaklega mörg vandamál stafa af þeim aðgerðum sem þarf að framkvæma með kóðanum í aðalvafraþræðinum. Meginþráðurinn er ábyrgur fyrir vinnslu notendaaðgerða, útreikninga á stílum, til að byggja upp og birta uppsetningu síðunnar. Ef þú yfirgnæfir aðalþráðinn með JavaScript verkefnum mun hann ekki hafa tækifæri til að klára restina af verkefnum í tíma. Þetta leiðir til tafa og "bremsur" í starfi síðna.
HTTP skjalasafnið hefur upplýsingar um hversu langan tíma það tekur að vinna JavaScript kóða í aðalþræði V8 vélarinnar. Þetta þýðir að við getum safnað þessum gögnum og fundið út hversu mikinn tíma aðalþráðurinn tekur að vinna úr JavaScript á ýmsum síðum.
Örgjörvatími (í millisekúndum) sem tengist handritsvinnslu í fartækjum
Prósentíla
10
25
50
75
90
Allar síður
356.4
959.7
2372.1
5367.3
10485.8
jQuery síður
575.3
1147.4
2555.9
5511.0
10349.4
Vue síður
1130.0
2087.9
4100.4
7676.1
12849.4
Hyrndar síður
1471.3
2380.1
4118.6
7450.8
13296.4
Viðbragðssíður
2700.1
5090.3
9287.6
14509.6
20813.3
Örgjörvatími sem tengist handritsvinnslu í farsímum
Örgjörvatími (í millisekúndum) sem tengist handritsvinnslu á borðtölvum
Prósentíla
10
25
50
75
90
Allar síður
146.0
351.8
831.0
1739.8
3236.8
jQuery síður
199.6
399.2
877.5
1779.9
3215.5
Vue síður
350.4
650.8
1280.7
2388.5
4010.8
Hyrndar síður
482.2
777.9
1365.5
2400.6
4171.8
Viðbragðssíður
508.0
1045.6
2121.1
4235.1
7444.3
Örgjörvatími sem tengist handritsvinnslu á borðtölvum
Hér má sjá eitthvað mjög kunnuglegt.
Til að byrja með eyða síður með jQuery umtalsvert minna í JavaScript vinnslu á aðalþræðinum en aðrar síður. Á 10. hundraðshlutanum, samanborið við allar síður, eyða jQuery síður í farsíma 61% meiri tíma í að vinna úr JS kóða á aðalþræðinum. Þegar um er að ræða jQuery skjáborðssíður eykst vinnslutími um 37%. Á 90. hundraðshlutanum skora jQuery síður mjög nálægt heildarskorunum. Nánar tiltekið eyða jQuery síður í fartækjum 1.3% minni tíma í aðalþráðinn en allar síður og 0.7% minni tíma í borðtölvum.
Hinum megin við einkunnina okkar eru rammar sem einkennast af mestu álagi á aðalþráðinn. Þetta er aftur Angular og React. Eini munurinn á þessu tvennu er að á meðan Angular síður senda meiri kóða til vafra en React síður, þá taka Angular síður minni CPU tíma að vinna úr kóða. Mun minna.
Á 10. hundraðshlutanum eyða Angular skrifborðssíður 230% meiri tíma í aðalþráðinn í vinnslu JS kóða en allar síður. Fyrir farsímasíður er þessi tala 313%. React síður standa sig verst. Á skjáborðinu eyða þeir 248% meiri tíma í að vinna kóða en allar síður og 658% meiri tíma í farsíma. 658% er ekki innsláttarvilla. Á 10. hundraðshlutanum eyða React síður 2.7 sekúndum af aðalþráðartíma í að vinna úr kóðanum sínum.
90. hundraðshlutinn, miðað við þessar miklu tölur, lítur að minnsta kosti aðeins betur út. Í samanburði við allar síður eyða Angular verkefni 29% meiri tíma í borðtölvur í aðalþræðinum og 27% meiri tíma í fartæki. Þegar um er að ræða React síður líta sömu tölur út eins og 130% og 98%, í sömu röð.
Hlutfallsfrávik fyrir 90. hundraðshluti líta betur út en svipuð gildi fyrir 10. hundraðshluta. En hér er rétt að muna að tölurnar sem gefa til kynna tímann virðast frekar skelfilegar. Segjum 20.8 sekúndur á aðal farsímaþræðinum fyrir vefsíðu sem byggð er með React. (Ég held að sagan af því sem raunverulega gerist á þessum tíma sé verðug sérstakrar greinar).
Það er einn hugsanlegur fylgikvilli hér (takk fyrir að vekja athygli mína á þessum eiginleika og fyrir að hafa gaumgæfið gögnin frá þessu sjónarhorni). Staðreyndin er sú að margar síður nota nokkur framhlið verkfæri. Sérstaklega hef ég séð margar síður nota jQuery samhliða React eða Vue, þar sem þessar síður eru að flytja úr jQuery yfir í önnur ramma eða bókasöfn. Fyrir vikið skellti ég mér aftur í gagnagrunninn, í þetta sinn valdi ég aðeins þá tengla sem samsvara síðum sem nota aðeins React, jQuery, Angular eða Vue, en ekki neina samsetningu þeirra. Hér er það sem ég fékk.
Örgjörvatími (í millisekúndum) sem tengist vinnslu forskrifta í fartækjum í aðstæðum þar sem vefsvæði nota aðeins eina ramma eða aðeins eitt bókasafn
Prósentíla
10
25
50
75
90
Síður sem nota eingöngu jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Síður sem nota eingöngu Vue
944.0
1716.3
3194.7
5959.6
9843.8
Síður sem nota aðeins Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Síður sem nota eingöngu React
2443.2
4620.5
10061.4
17074.3
24956.3
Örgjörvatími sem tengist vinnslu forskrifta í farsímum í aðstæðum þar sem vefsvæði nota aðeins eitt ramma, eða aðeins eitt bókasafn
Í fyrsta lagi eitthvað sem kemur ekki á óvart: þegar síða notar aðeins eina ramma eða eitt bókasafn batnar frammistaða slíkrar síðu oftar en ekki. Hvert hljóðfæri virkar betur á 10. og 25. hundraðshluta. Það er skynsamlegt. Síða sem er gerð með því að nota einn ramma ætti að skila betri árangri en síða sem er gerð með tveimur eða fleiri ramma eða bókasöfnum.
Reyndar lítur frammistaða hvers framenda tóls sem rannsakað er betur út í öllum tilvikum, nema einni undarlegri undantekningu. Það sem kom mér á óvart var að á 50. hundraðshlutanum og ofar standa síður sem nota React verr þegar React er eina bókasafnið sem þeir nota. Þetta var að vísu ástæðan fyrir því að ég set þessi gögn hér fram.
Þetta er svolítið skrítið en ég ætla samt að reyna að leita skýringa á þessu undarlega.
Ef verkefni notar bæði React og jQuery, þá er það verkefni líklega einhvers staðar hálfa leið með umskiptin frá jQuery til React. Kannski er það með kóðagrunn þar sem þessum bókasöfnum er blandað saman. Þar sem við höfum þegar séð að jQuery síður eyða minni tíma í aðalþráðinn en React síður, gæti þetta sagt okkur að innleiðing á einhverri virkni í jQuery hjálpar síðunni að skila aðeins betri árangri.
En eftir því sem verkefnið fer úr jQuery yfir í React og treystir meira á React eru hlutirnir að breytast. Ef síðan er virkilega hágæða og vefhönnuðir nota React vandlega, þá verður allt í lagi með slíka síðu. En fyrir meðal React-síðuna þýðir mikil notkun React að meginþráðurinn er undir miklu álagi.
Bilið á milli farsíma og borðtækja
Annað sjónarhorn sem ég skoðaði rannsökuð gögn frá var að kanna hversu stórt bilið er á milli þess að vinna með síður á farsímum og borðtölvum. Ef við tölum um að bera saman magn JavaScript kóða, þá leiðir slíkur samanburður ekki neitt hræðilegt í ljós. Auðvitað væri gaman að sjá minna magn af kóða sem hægt er að hlaða niður, en það er ekki mikill munur á magni farsímakóða og tölvukóða.
En ef við greinum þann tíma sem þarf til að vinna úr kóðanum verður mjög stórt bil á milli farsíma og skrifborðstækja áberandi.
Aukning í tíma (prósenta) sem tengist vinnslu forskrifta í fartækjum samanborið við skjáborð
Prósentíla
10
25
50
75
90
Allar síður
144.1
172.8
185.5
208.5
224.0
jQuery síður
188.2
187.4
191.3
209.6
221.9
Vue síður
222.5
220.8
220.2
221.4
220.4
Hyrndar síður
205.1
206.0
201.6
210.4
218.7
Viðbragðssíður
431.5
386.8
337.9
242.6
179.6
Þó að búast megi við einhverjum mun á kóðavinnsluhraða milli síma og fartölvu, þá segja svo miklar tölur mér að nútíma rammakerfi sé ekki nægilega miðuð við orkulítil tæki og að þeir séu að reyna að minnka bilið sem þeir hafa uppgötvað. Jafnvel á 10. hundraðshlutanum eyða React-síður 431.5% meiri tíma í farsímaþráðinn en á tölvuþráðnum. jQuery er með minnsta bilið, en jafnvel hér er samsvarandi tala 188.2%. Þegar vefsíðuhönnuðir gera verkefni sín á þann hátt að vinnsla þeirra krefst meiri örgjörvatíma (og það gerist og versnar bara með tímanum) þurfa eigendur lítilla tækja að borga fyrir það.
Niðurstöður
Góð umgjörð ætti að gefa forriturum góðan grunn til að byggja upp vefverkefni (hvað varðar öryggi, aðgengi, frammistöðu), eða þeir ættu að hafa innbyggðar takmarkanir sem gera það erfitt að byggja eitthvað sem brýtur í bága við þessar takmarkanir.
Þetta virðist ekki eiga við um frammistöðu vefverkefna (og væntanlega ekki þeirra ).
Það er athyglisvert að bara vegna þess að React eða Angular síður eyða meiri CPU tíma í að útbúa kóða en aðrar þýðir ekki endilega að React síður séu örgjörvafrekari en Vue síður á meðan þær keyra. Reyndar segja gögnin sem við höfum farið yfir mjög lítið um rekstrarframmistöðu ramma og bókasöfna. Þeir tala meira um þróunaraðferðirnar sem, meðvitað eða ekki, geta þessar rammar ýtt undir forritara. Við erum að tala um skjöl fyrir ramma, um vistkerfi þeirra, um algenga þróunartækni.
Það er líka vert að nefna eitthvað sem við greindum ekki hér, nefnilega hversu miklum tíma tækið eyðir í að keyra JavaScript kóða þegar flakkar á milli síðna á síðunni. Rökin fyrir SPA eru þau að þegar einsíðuforritinu hefur verið hlaðið inn í vafrann mun notandinn fræðilega geta opnað síður síðunnar hraðar. Mín eigin reynsla segir mér að þetta sé langt frá því að vera staðreynd. En við höfum ekki gögn til að skýra þetta mál.
Það sem er ljóst er að ef þú ert að nota ramma eða bókasafn til að búa til vefsíðu, þá ertu að gera málamiðlun hvað varðar upphaflega að hlaða verkefninu og gera það tilbúið til að fara í gang. Þetta á jafnvel við um jákvæðustu aðstæður.
Það er fullkomlega mögulegt að gera einhverjar málamiðlanir við viðeigandi aðstæður, en það er mikilvægt að forritarar geri slíkar málamiðlanir meðvitað.
En við höfum líka ástæðu til bjartsýni. Ég er spenntur að sjá hversu náið Chrome forritarar vinna með þróunaraðilum sumra framendaverkfæra sem við höfum skoðað í viðleitni til að hjálpa til við að bæta árangur þessara verkfæra.
Hins vegar er ég raunsær manneskja. Nýr arkitektúr skapar árangursvandamál eins oft og þeir leysa þau. Og það tekur tíma að laga villur. Rétt eins og við ættum ekki að búast við mun leysa öll frammistöðuvandamál, þú ættir ekki að búast við þessu frá nýjum útgáfum af uppáhalds ramma okkar.
Ef þú vilt nota eitt af framhliðarverkfærunum sem fjallað er um í þessari grein þýðir þetta að þú verður að leggja mikið á þig til að skaða ekki frammistöðu verkefnisins á meðan. Hér eru nokkur atriði sem þarf að huga að áður en nýr rammi er hafinn:
- Prófaðu sjálfan þig með skynsemi. Þarftu virkilega að nota valinn ramma? Hreint JavaScript í dag er fær um margt.
- Er til léttari valkostur við valinn ramma (eins og Preact, Svelte eða eitthvað annað) sem getur gefið þér 90% af getu þessa ramma?
- Ef þú ert nú þegar að nota ramma skaltu íhuga hvort það sé eitthvað sem býður upp á betri, íhaldssamari, staðlaða valkosti (til dæmis Nuxt.js í stað Vue, Next.js í stað React, og svo framvegis).
- Hvað mun þitt JavaScript árangur?
- Hvernig getur þú þróunarferli til að gera það erfiðara að dæla meiri JavaScript kóða inn í verkefni en bráðnauðsynlegt er?
- Ef þú ert að nota ramma til að auðvelda þróun skaltu íhuga senda rammakóða til viðskiptavina. Kannski þú getur leyst öll vandamál á þjóninum?
Venjulega eru þessar hugmyndir þess virði að skoða, óháð því hvað þú hefur nákvæmlega valið fyrir framhliðarþróun. En þau eru sérstaklega mikilvæg þegar þú ert að vinna í verkefni sem skortir árangur frá upphafi.
Kæru lesendur! Hvernig sérðu hinn fullkomna JavaScript ramma?
Heimild: www.habr.com