Veebisaidi aeglustamiseks pole kiiremat viisi (sõnamäng), kui käivitada sellel hulk JavaScripti koodi. JavaScripti kasutades tuleb selle eest projekti jõudluses tasuda vähemalt neli korda. Siin on see, mida saidi JavaScripti kood laadib kasutajate süsteemidesse:
- Faili üleslaadimine võrgu kaudu.
- Pakkimata lähtekoodi parsimine ja kompileerimine pärast allalaadimist.
- JavaScripti koodi täitmine.
- Mälu tarbimine.
See kombinatsioon osutub .
Ja me lisame oma projektidesse üha rohkem JS-koodi. Kuna organisatsioonid liiguvad saitide poole, mida kasutavad raamistikud ja teegid nagu React, Vue ja teised, muudame saitide põhifunktsioonid JavaScriptist väga sõltuvaks.
Olen näinud palju väga raskeid veebisaite, mis kasutavad JavaScripti raamistikke. Kuid minu nägemus sellest küsimusest on tugevalt kallutatud. Fakt on see, et ettevõtted, kellega ma töötan, tulevad minu juurde just seetõttu, et neil on keerulised veebisaidi jõudlusprobleemid. Sellest tulenevalt tekkis mul huvi teada, kui laialt levinud see probleem on ja milliseid “trahve” maksame, kui valime mingi saidi aluseks ühe või teise raamistiku.
See projekt aitas mul selle välja mõelda. .
Andmed
HTTP-arhiivi projekt jälgib kokku 4308655 5484239 XNUMX linki tavalistele lauaarvutisaitidele ja XNUMX XNUMX XNUMX linki mobiilisaitidele. Nende linkidega seotud paljude näitajate hulgas on vastavatelt saitidelt leitud tehnoloogiate loend. See tähendab, et saame proovida tuhandeid saite, mis kasutavad erinevaid raamistikke ja teeke, ning õppida, kui palju koodi nad klientidele saadavad ja kui palju koormust see kood kasutajate süsteemidele avaldab.
Kogusin andmeid 2020. aasta märtsist, mis olid kõige värskemad andmed, millele mul oli juurdepääs.
Otsustasin võrrelda kõigi saitide HTTP-arhiivi koondandmeid nende saitide andmetega, mis kasutavad Reacti, Vue-d ja Angulari, kuigi kaalusin ka muu lähtematerjali kasutamist.
Huvitavamaks muutmiseks lisasin lähteandmete hulka ka saidid, mis kasutavad jQueryt. See raamatukogu on endiselt väga populaarne. Samuti tutvustab see lähenemist veebisaitide arendamisele, mis erineb Reacti, Vue ja Angulari pakutavast ühelehelise rakenduse (SPA) mudelist.
HTTP-arhiivi lingid, mis esindavad saite, mis on leitud, et kasutavad meile huvipakkuvaid tehnoloogiaid
Raamistik või raamatukogu
Lingid mobiilisaitidele
Lingid tavalistele saitidele
jQuery
4615474
3714643
Reageerima
489827
241023
Vue
85649
43691
nurgeline
19423
18088
Lootused ja unistused
Enne kui asume andmete analüüsi juurde, tahan rääkida sellest, mida tahaksin loota.
Usun, et ideaalses maailmas ületaksid raamistikud arendajate vajaduste rahuldamise ja pakuksid meie saitide igapäevastele kasutajatele konkreetseid eeliseid. Tootlikkus on vaid üks neist eelistest. Siin tuleb meelde ka juurdepääsetavus ja ohutus. Kuid see on ainult kõige olulisem.
Seega peaks ideaalses maailmas mingisugune raamistik suure jõudlusega veebisaidi loomise lihtsamaks muutma. Seda tuleks teha kas seetõttu, et raamistik annab arendajale korraliku baasi, millele projekt ehitada, või seetõttu, et see seab arendusele piiranguid, esitades sellele nõudeid, mis raskendavad millegi väljatöötamist. mis osutub aeglaseks.
Parimad raamistikud peaksid tegema mõlemat: looma hea aluse ja seadma tööle piiranguid, mis võimaldavad teil saavutada korraliku tulemuse.
Andmete mediaanväärtuste analüüsimine ei anna meile vajalikku teavet. Ja tegelikult jätab see lähenemine meie tähelepanu kõrvale . Selle asemel tuletasin olemasolevatest andmetest protsentiilide hinded. Need on 10, 25, 50 (mediaan), 75, 90 protsentiilid.
Mind huvitavad eriti 10. ja 90. protsentiilid. 10. protsentiil tähistab konkreetse raamistiku parimat jõudlust (või vähemalt enam-vähem parimale lähedast). Teisisõnu tähendab see, et ainult 10% teatud raamistikku kasutavatest saitidest jõuavad sellele või kõrgemale tasemele. 90. protsentiil seevastu on mündi teine pool – see näitab meile, kui halvasti asjad võivad olla. 90. protsentiil on lõpusaidid – need viimased 10% saitidest, millel on suurim hulk JS-koodi või pikim aeg, mis kulub nende koodi töötlemiseks põhilõimes.
JavaScripti koodi mahud
Alustuseks on mõttekas analüüsida erinevate saitide poolt võrgu kaudu edastatava JavaScripti koodi suurust.
Mobiilseadmetesse edastatud JavaScripti koodi kogus (KB).
Protsentiilid
10
25
50
75
90
Kõik saidid
93.4
196.6
413.5
746.8
1201.6
jQuery saidid
110.3
219.8
430.4
748.6
1162.3
Vue veebisaidid
244.7
409.3
692.1
1065.5
1570.7
Nurgelised veebisaidid
445.1
675.6
1066.4
1761.5
2893.2
Reageeri veebisaidid
345.8
441.6
690.3
1238.5
1893.6
Mobiilseadmetesse saadetud JavaScripti koodi hulk
Lauaseadmetesse edastatud JavaScripti koodi kogus (KB).
Protsentiilid
10
25
50
75
90
Kõik saidid
105.5
226.6
450.4
808.8
1267.3
jQuery saidid
121.7
242.2
458.3
803.4
1235.3
Vue veebisaidid
248.0
420.1
718.0
1122.5
1643.1
Nurgelised veebisaidid
468.8
716.9
1144.2
1930.0
3283.1
Reageeri veebisaidid
308.6
469.0
841.9
1472.2
2197.8
Lauaseadmetesse edastatud JavaScripti koodi kogus
Kui räägime ainult JS-koodi suurusest, mille saidid seadmetele saadavad, näeb kõik välja umbes selline, nagu võite oodata. Nimelt ühe raamistiku kasutamine tähendab, et isegi ideaalses olukorras suureneb saidi JavaScripti koodi maht. See pole üllatav – te ei saa muuta JavaScripti raamistikku saidi aluseks ja eeldada, et projekti JS-koodi hulk on väga väike.
Nende andmete puhul on huvitav see, et mõnda raamistikku ja teeke võib pidada projekti paremaks lähtepunktiks kui teisi. JQueryga veebisaidid näevad parimad välja. Nende lauaarvutisaidid sisaldavad 15% rohkem JavaScripti kui kõik saidid ja nende mobiilisaidid 18% rohkem JavaScripti. (Tõsi küll, siin on andmetes mõningane viltu. Fakt on see, et jQuery on paljudel saitidel olemas, seega on loomulik, et sellised saidid on saitide koguarvuga tihedamalt seotud kui teised. See aga ei mõjuta seda, kuidas lähteandmed väljastatakse iga raamistiku jaoks.)
Kui koodide kasv 15–18% on märkimisväärne näitaja, siis võrreldes teiste raamistike ja raamatukogudega on jQuery kehtestatud maks väga madal. 10. protsentiili nurgasaidid saadavad lauaarvutitesse 344% rohkem andmeid kui kõik saidid ja 377% rohkem mobiilseadmetesse. Reacti saidid on raskuselt järgmised, saadavad lauaarvutitesse 193% rohkem koodi kui kõik saidid ja 270% rohkem mobiilseadmetesse.
Mainisin varem, et kuigi raamistiku kasutamine tähendab, et projekti kaasatakse juba selle kallal töötamise alguses teatud kogus koodi, loodan, et raamistik suudab arendajat kuidagi piirata. Eelkõige räägime koodi maksimaalse koguse piiramisest.
Huvitav on see, et jQuery saidid järgivad seda ideed. Kuigi need on 10. protsentiili tasemel kõigist saitidest pisut raskemad (15–18%), on need 90. protsentiili tasemel pisut kergemad kui kõik saidid – nii lauaarvutite kui ka mobiiliversioonide puhul umbes 3%. See ei tähenda, et see oleks väga märkimisväärne eelis, kuid võib öelda, et jQuery saitidel pole vähemalt suuri JavaScripti koodi suurusi isegi nende suurimates versioonides.
Kuid sama ei saa öelda teiste raamistike kohta.
Nii nagu 10. protsentiili puhul, erinevad ka Angulari ja Reacti 90. protsentiili saidid teistest saitidest, kuid need erinevad kahjuks halvemini.
90. protsentiili juures saadavad Angular saidid mobiilseadmetesse 141% rohkem andmeid kui kõik saidid ja 159% rohkem lauaarvutitesse. Reaktsioonisaidid saadavad lauaarvutitesse 73% rohkem kui kõik saidid ja 58% rohkem mobiilseadmetesse. Reacti saitide koodi suurus 90. protsentiili juures on 2197.8 KB. See tähendab, et need saidid saadavad mobiilseadmetesse 322.9 KB rohkem andmeid kui nende lähimad Vue-põhised konkurendid. Angularil ja Reactil põhinevate töölauasaitide ja muude saitide vaheline lõhe on veelgi suurem. Näiteks Reacti töölauasaidid saadavad seadmetele 554.7 KB rohkem JS-koodi kui sarnased Vue saidid.
Aeg, mis kulub põhilõime JavaScripti koodi töötlemiseks
Ülaltoodud andmed näitavad selgelt, et uuritud raamistikke ja teeke kasutavad saidid sisaldavad suures koguses JavaScripti koodi. Kuid loomulikult on see vaid üks osa meie võrrandist.
Kui JavaScripti kood on brauserisse jõudnud, tuleb see viia tööolekusse. Eriti palju probleeme põhjustavad need toimingud, mida tuleb teha brauseri põhilõime koodiga. Peamine lõim vastutab kasutaja toimingute töötlemise, stiilide arvutamise ning lehepaigutuse loomise ja kuvamise eest. Kui koormate põhilõime JavaScripti ülesannetega üle, pole sellel võimalust muid ülesandeid õigeaegselt täita. See toob kaasa viivitusi ja "pidurdusi" lehtede töös.
HTTP-arhiivi andmebaas sisaldab teavet selle kohta, kui kaua kulub V8 mootori põhilõime JavaScripti koodi töötlemine. See tähendab, et saame neid andmeid koguda ja teada saada, kui palju aega kulub põhilõimel erinevate saitide JavaScripti töötlemiseks.
Mobiilseadmetes skripti töötlemisega seotud protsessori aeg (millisekundites).
Protsentiilid
10
25
50
75
90
Kõik saidid
356.4
959.7
2372.1
5367.3
10485.8
jQuery saidid
575.3
1147.4
2555.9
5511.0
10349.4
Vue veebisaidid
1130.0
2087.9
4100.4
7676.1
12849.4
Nurgelised veebisaidid
1471.3
2380.1
4118.6
7450.8
13296.4
Reageeri veebisaidid
2700.1
5090.3
9287.6
14509.6
20813.3
Mobiilseadmete skripti töötlemisega seotud protsessori aeg
CPU aeg (millisekundites), mis on seotud skripti töötlemisega lauaarvutites
Protsentiilid
10
25
50
75
90
Kõik saidid
146.0
351.8
831.0
1739.8
3236.8
jQuery saidid
199.6
399.2
877.5
1779.9
3215.5
Vue veebisaidid
350.4
650.8
1280.7
2388.5
4010.8
Nurgelised veebisaidid
482.2
777.9
1365.5
2400.6
4171.8
Reageeri veebisaidid
508.0
1045.6
2121.1
4235.1
7444.3
CPU aeg, mis on seotud skripti töötlemisega lauaarvutites
Siin on näha midagi väga tuttavat.
Alustuseks kulutavad jQueryga saidid põhilõime JavaScripti töötlemisele oluliselt vähem kui teised. 10. protsentiili juures kulutavad mobiilseadmetes olevad jQuery saidid kõigi saitidega võrreldes põhilõime JS-koodi töötlemisele 61% rohkem aega. Töölaua jQuery saitide puhul pikeneb töötlemisaeg 37%. 90. protsentiili juures on jQuery saitide hinded väga lähedased koondskooridele. Täpsemalt, mobiilseadmetes veedavad jQuery saidid põhilõimes 1.3% vähem aega kui kõik saidid ja lauaarvutites veedavad nad põhilõimes 0.7% vähem aega.
Meie reitingu teisel poolel on raamistikud, mida iseloomustab põhikeerme suurim koormus. See on jällegi Angular and React. Ainus erinevus nende vahel on see, et kuigi Angular-saidid saadavad brauseritele suuremas koguses koodi kui Reacti saidid, kulub Angular-saitide koodi töötlemiseks protsessori jaoks vähem aega. Palju vähem.
10. protsentiili juures kulutavad Angulari töölauasaidid JS-koodi töötlemisele 230% rohkem aega kui kõik saidid. Mobiilisaitide puhul on see näitaja 313%. Reacti saitide jõudlus on kõige halvem. Lauaarvutites kulutavad nad koodi töötlemisele 248% rohkem aega kui kõigil saitidel ja mobiilseadmetes kulutavad nad koodi töötlemisele 658% rohkem aega. 658% ei ole kirjaviga. 10. protsentiili juures kulutavad Reacti saidid oma olemasoleva koodi töötlemisele 2.7 sekundit põhilõime aega.
90. protsentiili numbrid näevad nende tohutute arvudega võrreldes vähemalt veidi paremad välja. Võrreldes kõigi saitidega kulutavad nurgaprojektid lauaarvutites 29% rohkem aega ja mobiilseadmetes 27% rohkem aega. Reacti saitide puhul näevad sarnased näitajad välja vastavalt 130% ja 98%.
90. protsentiili kõrvalekalde protsendid näevad paremad välja kui 10. protsentiili sarnased väärtused. Siinkohal tasub aga meeles pidada, et kellaaega tähistavad numbrid tunduvad üsna hirmutavad. Oletame – 20.8 sekundit mobiilseadme põhilõimes Reactile ehitatud saidi jaoks. (Usun, et lugu sellest, mis selle aja jooksul tegelikult toimub, väärib eraldi artiklit).
Siin on üks võimalik tüsistus (aitäh et juhtisite sellele funktsioonile tähelepanu ja uurisite andmeid sellest vaatenurgast hoolikalt). Fakt on see, et paljud saidid kasutavad mitut esiotsa tööriista. Eelkõige olen näinud, et paljud saidid kasutavad jQueryt koos Reacti või Vue'ga, kuna need saidid migreeruvad jQueryst teistesse raamistikesse või teekidesse. Selle tulemusena läksin tagasi andmebaasi, valides seekord ainult need lingid, mis vastasid saitidele, mis kasutasid ainult Reacti, jQueryt, Angulari või Vue'i, kuid mitte ühtegi nende kombinatsiooni. Siin on see, mida ma sain.
Protsessori aeg (millisekundites), mis on seotud skripti töötlemisega mobiilseadmetes olukordades, kus saidid kasutavad ainult ühte raamistikku või ainult ühte teeki
Protsentiilid
10
25
50
75
90
Saidid, mis kasutavad ainult jQueryt
542.9
1062.2
2297.4
4769.7
8718.2
Saidid, mis kasutavad ainult Vue-d
944.0
1716.3
3194.7
5959.6
9843.8
Saidid, mis kasutavad ainult Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Veebisaidid, mis kasutavad ainult Reacti
2443.2
4620.5
10061.4
17074.3
24956.3
Protsessori aeg, mis on seotud skriptide töötlemisega mobiilseadmetes olukorras, kus saidid kasutavad ainult ühte raamistikku või ainult ühte teeki
Esiteks midagi, mis pole üllatav: kui sait kasutab ainult ühte raamistikku või ühte teeki, paraneb sellise saidi jõudlus sagedamini kui mitte. Iga instrumendi jõudlus näeb parem välja 10. ja 25. protsentiili puhul. See on loogiline. Ühe raamistiku abil tehtud sait peaks olema kiirem kui sait, mis on tehtud kahe või enama raamistiku või teegi abil.
Tegelikult nägid iga uuritud esiotsa tööriista hinded kõigil juhtudel paremad, välja arvatud üks uudishimulik erand. Mind üllatas see, et 50. protsentiili ja kõrgemal tasemel toimivad Reacti kasutavad saidid halvemini, kui React on ainus teek, mida nad kasutavad. Muide, see oli põhjus, miks ma need andmed siin esitan.
See on küll veidi kummaline, aga püüan sellele kummalisusele siiski seletust otsida.
Kui projekt kasutab nii Reacti kui ka jQueryt, on see projekt tõenäoliselt kuskil poole peal jQueryst Reactile ülemineku protsessis. Võib-olla on tal koodibaas, milles need teegid on segatud. Kuna oleme juba näinud, et jQuery saidid kulutavad põhilõimele vähem aega kui Reacti saidid, võib see meile öelda, et mõne funktsiooni rakendamine jQuerys aitab saidi jõudlust veidi parandada.
Kuid kuna projekt liigub jQuerylt Reactile ja tugineb üha enam Reactile, muutub olukord. Kui sait on tehtud tõeliselt kvaliteetselt ja saidi arendajad kasutavad Reacti hoolikalt, siis on sellise saidiga kõik hästi. Kuid keskmise Reacti saidi jaoks tähendab Reacti laialdane kasutamine, et põhilõngale on suurem koormus.
Lõhe mobiilseadmete ja lauaarvutite vahel
Teine viis, kuidas ma andmeid vaatasin, oli uurida, kui suur on vahe mobiilseadmete ja lauaarvutite kasutuskogemuse vahel. Kui rääkida JavaScripti koodi mahtude võrdlemisest, siis selline võrdlus midagi kohutavat ei paljasta. Muidugi oleks tore näha väiksemaid koguseid allalaaditavat koodi, kuid mobiili- ja lauaarvuti koodide hulgas pole suurt vahet.
Kui aga analüüsida koodi töötlemiseks kuluvat aega, on märgatav väga suur lõhe mobiilsete ja lauaarvutite vahel.
Mobiilseadmetes skriptitöötlusega seotud aja pikenemine (protsentides) võrreldes lauaarvutitega
Protsentiilid
10
25
50
75
90
Kõik saidid
144.1
172.8
185.5
208.5
224.0
jQuery saidid
188.2
187.4
191.3
209.6
221.9
Vue veebisaidid
222.5
220.8
220.2
221.4
220.4
Nurgelised veebisaidid
205.1
206.0
201.6
210.4
218.7
Reageeri veebisaidid
431.5
386.8
337.9
242.6
179.6
Kuigi telefoni ja sülearvuti kooditöötluse kiiruse erinevus on ootuspärane, näitavad nii suured numbrid mulle, et kaasaegsed raamistikud ei ole piisavalt suunatud vähese energiatarbega seadmetele ja soovile tuvastatud tühimikku täita. Isegi 10. protsentiili juures kulutavad Reacti saidid mobiili põhilõimele 431.5% rohkem aega kui töölaua põhilõimele. Kõige väiksem vahe on jQuerys, kuid ka siin on vastav näitaja 188.2%. Kui veebisaitide arendajad teevad oma projekte nii, et nende töötlemiseks kulub rohkem protsessori aega (ja see juhtub ja aja jooksul ainult hullemaks läheb), peavad vähese energiatarbega seadmete omanikud selle eest maksma.
Tulemused
Head raamistikud peaksid andma arendajatele hea aluse veebiprojektide loomiseks (turvalisuse, juurdepääsetavuse, jõudluse osas) või neil peaks olema sisseehitatud piirangud, mis raskendavad nende piiranguid rikkuva asja loomist.
Tundub, et see ei kehti veebiprojektide (ja ilmselt ka nende ).
Väärib märkimist, et see, et Reacti või Angular saidid kulutavad koodi ettevalmistamisele rohkem protsessori aega kui teised, ei tähenda tingimata, et Reacti saidid on töötamise ajal protsessorimahukamad kui Vue saidid. Tegelikult räägivad vaadatud andmed väga vähe raamistike ja teekide toimivuse kohta. Nad räägivad rohkem arenduskäsitlustest, mille poole need raamistikud võivad teadlikult või mitte programmeerijaid tõugata. Räägime raamistike dokumenteerimisest, nende ökosüsteemist ja levinud arendustehnikatest.
Samuti tasub mainida midagi, mida me siin ei analüüsinud, nimelt seda, kui palju aega kulub seadmel saidi lehtede vahel liikumisel JavaScripti koodi täitmiseks. Argument SPA kasuks on see, et kui ühe lehe rakendus on brauserisse laaditud, pääseb kasutaja teoreetiliselt saidi lehtedele kiiremini juurde. Minu enda kogemus ütleb, et see pole kaugeltki tõsi. Kuid meil pole selle probleemi selgitamiseks andmeid.
Selge on see, et kui kasutate veebisaidi loomiseks raamistikku või teeki, teete projekti algse laadimise ja selle tööks ettevalmistamise osas kompromissi. See kehtib isegi kõige positiivsemate stsenaariumide kohta.
Sobivates olukordades on võimalik teha mõningaid kompromisse, kuid on oluline, et arendajad teeksid selliseid kompromisse teadlikult.
Kuid meil on põhjust ka optimismiks. Mind julgustab see, kui tihedalt töötavad Chrome'i arendajad mõne meie käsitletud esiotsa tööriista taga olevate inimestega, et aidata nende tööriistade jõudlust parandada.
Samas olen ma pragmaatiline inimene. Uued arhitektuurid tekitavad jõudlusprobleeme sama sageli kui need lahendavad. Ja puuduste kõrvaldamine võtab aega. Nii nagu me ei peaks seda ootama lahendab kõik jõudlusprobleemid, ei tohiks te seda oodata meie lemmikraamistike uutelt versioonidelt.
Kui soovite kasutada mõnda selles materjalis käsitletud esiotsa tööriista, tähendab see, et peate tegema täiendavaid jõupingutusi tagamaks, et te muide oma projekti jõudlust ei kahjusta. Siin on mõned kaalutlused, mida kaaluda enne uue raamistiku kasutamist.
- Kontrolli ennast terve mõistusega. Kas peate tõesti valitud raamistikku kasutama? Puhas JavaScript suudab tänapäeval palju ära teha.
- Kas teie valitud raamistikule (nagu Preact, Svelte või midagi muud) on mõni kergem alternatiiv, mis annab teile 90% selle raamistiku võimalustest?
- Kui kasutate juba raamistikku, siis mõelge, kas on midagi, mis pakub paremaid, konservatiivsemaid standardseid võimalusi (näiteks Vue asemel Nuxt.js, Reacti asemel Next.js jne).
- Mida teie JavaScripti jõudlus?
- Kuidas saate arendusprotsessi, et muuta projekti rohkem JavaScripti koodi sisestamine, kui see on hädavajalik?
- Kui kasutate arendamise hõlbustamiseks raamistikku, kaaluge saata klientidele raamistiku kood. Võib-olla saate lahendada kõik serveri probleemid?
Tavaliselt tasub nende ideedega lähemalt tutvuda, olenemata sellest, mille esiotsa arendamiseks täpselt valite. Kuid need on eriti olulised siis, kui töötate projekti kallal, millel puudub algusest peale jõudlus.
Kallid lugejad! Mida näete ideaalse JavaScripti raamistikuna?
Allikas: www.habr.com