D'r is gjin fluggere manier om in webside te fertragen (pun bedoeld) dan in boskje JavaScript-koade derop te brûken. By it brûken fan JavaScript moatte jo der foar betelje mei de prestaasjes fan projekten net minder dan fjouwer kear. Hjir is hoe't de JavaScript-koade fan 'e side de systemen fan brûkers laadt:
- It ynladen fan in triem oer it netwurk.
- Unferpakte boarnekoade parsearje en kompilearje nei download.
- Utfiering fan JavaScript-koade.
- Unthâld konsumpsje.
Dizze kombinaasje docht bliken .
En wy befetsje mear en mear JS-koade yn ús projekten. As organisaasjes ferhúzje nei siden oandreaun troch kaders en biblioteken lykas React, Vue en oaren, meitsje wy de kearnfunksjonaliteit fan siden heul ôfhinklik fan JavaScript.
Ik haw in protte heul swiere siden sjoen dy't JavaScript-kaders brûke. Mar myn fisy op 'e kwestje is tige biased. It feit is dat de bedriuwen mei wa't ik wurkje, nei my wenden, krekt om't se te krijen hawwe mei komplekse problemen op it mêd fan sideprestaasjes. Dêrtroch waard ik nijsgjirrich oer hoe faak dit probleem is, en oer hokker soarte "straffen" wy betelje as wy ien of oar ramt kieze as basis foar in bepaalde side.
It projekt holp my dit út te finen. .
data
It HTTP-argyfprojekt folget in totaal fan 4308655 keppelings nei reguliere buroblêdsides en 5484239 keppelings nei mobile siden. Under de protte metriken dy't ferbûn binne mei dizze keppelings is in list mei technologyen fûn op 'e respektivelike siden. Dit betsjut dat wy tûzenen siden kinne probearje dy't ferskate kaders en bibleteken brûke en leare oer hoefolle koade se stjoere nei kliïnten en hoefolle lading dizze koade makket op systemen fan brûkers.
Ik sammele gegevens fan maart 2020, dat wie de meast resinte gegevens dêr't ik tagong ta hie.
Ik besleat om aggregearre HTTP-argyfgegevens oer alle siden te fergelykjen mei gegevens fan siden fûn mei React, Vue, en Angular, hoewol ik ek tocht om oar boarnemateriaal te brûken.
Om it nijsgjirriger te meitsjen, haw ik ek siden tafoege dy't jQuery brûke oan 'e boarnegegevensset. Dizze bibleteek is noch altyd tige populêr. It yntrodusearret ek in oare oanpak foar webûntwikkeling dan it Single Page Application (SPA) model oanbean troch React, Vue en Angular.
Keppelings yn it HTTP-argyf dy't siden fertsjintwurdigje dy't fûn binne te brûken technologyen fan belang
Framework of biblioteek
Keppelings nei mobile sites
Keppelings nei gewoane siden
jQuery
4615474
3714643
Reagearje
489827
241023
vue
85649
43691
Winkelje
19423
18088
Winsken en dreamen
Foardat wy oergeane nei data-analyze, wol ik prate oer wêr't ik op hoopje soe.
Ik leau dat yn in ideale wrâld, kaders moatte gean fierder as it foldwaan oan 'e behoeften fan ûntwikkelders en jouwe wat spesifyk foardiel foar de gemiddelde brûker dy't wurket mei ús siden. Prestaasje is mar ien fan dy foardielen. Dit is wêr't tagonklikens en feiligens yn it spul komme. Mar dit is allinich it wichtichste.
Dat, yn in ideale wrâld, soe in soarte fan ramt it maklik meitsje moatte om in hege prestaasjes side te meitsjen. Dit moat dien wurde of troch it feit dat it ramt de ûntwikkelder in fatsoenlike basis jout om in projekt op te bouwen, of troch it feit dat it beheiningen oplein oan ûntwikkeling, easken foar stelt dy't de ûntwikkeling fan iets dat draait komplisearje. út te wêzen stadich.
De bêste kaders moatte beide dwaan: in goede basis jaan en beheiningen oplizze op it wurk, sadat jo in fatsoenlik resultaat kinne berikke.
It analysearjen fan de mediaanwearden fan 'e gegevens sil ús net de ynformaasje jaan dy't wy nedich binne. En, yn feite, dizze oanpak ferlit ús oandacht . Ynstee haw ik persintaazjes ôflaat fan 'e gegevens dy't ik hie. Dit binne 10, 25, 50 (mediaan), 75, 90 percentiles.
Ik bin benammen ynteressearre yn 'e 10e en 90e percentiles. It 10e persintaazje stiet foar de alderbêste prestaasje (of op syn minst min of mear ticht by de bêste) foar in bepaald ramt. Mei oare wurden, dit betsjut dat allinich 10% fan siden dy't in bepaald ramt brûke, it op dit nivo meitsje, of heger. It 90e persintaazje, oan 'e oare kant, is de oare kant fan 'e munt - it lit ús sjen hoe min dingen kinne wurde. It 90e persintaazje is de siden dy't efterfolgje - dy ûnderste 10% fan siden dy't de measte JS-koade hawwe as de langste tiid om har koade op 'e haadthread te ferwurkjen.
Folumes fan JavaScript-koade
Om te begjinnen is it logysk om de grutte fan 'e JavaScript-koade te analysearjen dy't troch ferskate siden oer it netwurk oerbrocht wurdt.
It bedrach fan JavaScript-koade (Kb) oerdroegen oan mobile apparaten
Persintilen
10
25
50
75
90
Alle siden
93.4
196.6
413.5
746.8
1201.6
jQuery sites
110.3
219.8
430.4
748.6
1162.3
Vue sites
244.7
409.3
692.1
1065.5
1570.7
Angular sites
445.1
675.6
1066.4
1761.5
2893.2
Reagearje Sites
345.8
441.6
690.3
1238.5
1893.6
Hoefolle JavaScript-koade stjoerd nei mobile apparaten
Bedrach fan JavaScript-koade (Kb) oerdroegen oan buroblêdapparaten
Persintilen
10
25
50
75
90
Alle siden
105.5
226.6
450.4
808.8
1267.3
jQuery sites
121.7
242.2
458.3
803.4
1235.3
Vue sites
248.0
420.1
718.0
1122.5
1643.1
Angular sites
468.8
716.9
1144.2
1930.0
3283.1
Reagearje Sites
308.6
469.0
841.9
1472.2
2197.8
Bedrach fan JavaScript-koade stjoerd nei buroblêdapparaten
As wy allinich prate oer de grutte fan 'e JS-koade dy't siden nei apparaten stjoere, dan sjocht alles sa't jo kinne ferwachtsje. As ien fan 'e kaders wurdt brûkt, betsjut dit nammentlik dat sels yn in ideale situaasje it folume fan' e JavaScript-koade fan 'e side sil tanimme. Dit is net ferrassend - jo kinne gjin JavaSkript-ramt de basis meitsje fan in side en ferwachtsje dat it folume fan 'e JS-koade fan it projekt heul leech sil wêze.
Wat opfallend is oan dizze gegevens is dat guon kaders en bibleteken as in better útgongspunt foar in projekt beskôge wurde kinne as oaren. Siden mei jQuery sjogge it bêste. Op buroblêdferzjes fan siden befetsje se 15% mear JavaScript dan alle siden, en op mobyl befetsje se 18% mear. (Jawis, d'r is hjir wat datakorrupsje. It feit is dat jQuery op in protte siden oanwêzich is, dus it is gewoan natuerlik dat sokke siden nauwer ferbûn binne as oaren mei it totale oantal siden. Dit hat lykwols gjin ynfloed op hoe rau gegevens wurde útfier foar elk ramt.)
Wylst de 15-18% ferheging fan koade folume is in opmerklike figuer, fergelykje dit mei oare kaders en biblioteken, men kin konkludearje dat de "belesting" oplein troch jQuery is hiel leech. Angular siden yn 'e 10e percentile stjoere 344% mear gegevens nei buroblêd dan alle siden, en 377% mear nei mobyl. React sites binne de folgjende swierste, stjoert 193% mear koade nei buroblêd dan alle siden, en 270% mear nei mobyl.
Earder neamde ik dat hoewol it brûken fan in ramt betsjut dat in bepaalde hoemannichte koade yn it projekt sil wurde opnommen, hoopje ik oan it begjin fan it wurk deroan dat it ramt de ûntwikkelder op ien of oare manier kin beheine. Yn it bysûnder hawwe wy it oer it beheinen fan it maksimale bedrach fan koade.
Ynteressant folgje jQuery-siden dit idee. Wylst se wat swierder binne as alle siden op 'e 10e percentile (troch 15-18%), binne se wat lichter op' e 90e percentile by sawat 3% op sawol buroblêd as mobyl. Dit is net te sizzen dat dit in tige wichtige foardiel is, mar it kin sein wurde dat jQuery-siden, op syn minst, gjin grutte JavaSkript-koadegrutte hawwe, sels yn har grutste ferzjes.
Mar itselde kin net sein wurde oer oare kaders.
Krekt as yn it gefal fan 'e 10e percentile, by de 90e percentile ferskille sites op Angular en React fan oare siden, mar se ferskille, spitigernôch, foar it slimmer.
Op it 90e persintaazje stjoere Angular-siden 141% mear gegevens nei mobyl dan alle siden, en 159% mear nei buroblêd. React-siden stjoere 73% mear nei buroblêd dan alle siden, en 58% mear nei mobyl. De koadegrutte fan React-sites op it 90ste persintaazje is 2197.8 KB. Dit betsjut dat sokke siden 322.9 KB mear gegevens stjoere nei mobile apparaten dan har neiste konkurrinten basearre op Vue. De kloof tusken buroblêdsites basearre op Angular en React en oare siden is noch grutter. Bygelyks, buroblêd React-siden stjoere 554.7 KB mear JS-koade nei apparaten dan lykweardige Vue-siden.
Tiid nommen om JavaScript-koade te ferwurkjen yn 'e haadtried
De boppesteande gegevens jouwe dúdlik oan dat siden dy't de ûndersochte kaders en biblioteken brûke, grutte hoemannichten JavaScript-koade befetsje. Mar dat is fansels mar ien diel fan ús fergeliking.
Nei't de JavaScript-koade yn 'e browser is oankommen, moat it yn in wurkbere steat brocht wurde. Benammen in protte problemen wurde feroarsake troch dy aksjes dy't moatte wurde útfierd mei de koade yn de haadblêder thread. De haadtried is ferantwurdlik foar it ferwurkjen fan brûkersaksjes, foar it berekkenjen fan stilen, foar it bouwen en werjaan fan de side-yndieling. As jo de haadtried oerweldigje mei JavaSkript-taken, sil it net de kâns hawwe om de rest fan 'e taken yn' e tiid te foltôgjen. Dit liedt ta fertragingen en "remmen" yn it wurk fan 'e siden.
De HTTP-argyf-database hat ynformaasje oer hoe lang it duorret om JavaScript-koade te ferwurkjen yn 'e haadthread fan' e V8-motor. Dit betsjut dat wy dizze gegevens sammelje kinne en útfine hoefolle tiid de haadtried nimt om de JavaScript fan ferskate siden te ferwurkjen.
Prozessortiid (yn millisekonden) relatearre oan skriptferwurking op mobile apparaten
Persintilen
10
25
50
75
90
Alle siden
356.4
959.7
2372.1
5367.3
10485.8
jQuery sites
575.3
1147.4
2555.9
5511.0
10349.4
Vue sites
1130.0
2087.9
4100.4
7676.1
12849.4
Angular sites
1471.3
2380.1
4118.6
7450.8
13296.4
Reagearje Sites
2700.1
5090.3
9287.6
14509.6
20813.3
Prozessortiid yn ferbân mei skriptferwurking op mobile apparaten
CPU-tiid (yn millisekonden) relatearre oan skriptferwurking op buroblêdapparaten
Persintilen
10
25
50
75
90
Alle siden
146.0
351.8
831.0
1739.8
3236.8
jQuery sites
199.6
399.2
877.5
1779.9
3215.5
Vue sites
350.4
650.8
1280.7
2388.5
4010.8
Angular sites
482.2
777.9
1365.5
2400.6
4171.8
Reagearje Sites
508.0
1045.6
2121.1
4235.1
7444.3
Prozessortiid yn ferbân mei skriptferwurking op buroblêdapparaten
Hjir kinne jo wat heul fertrouds sjen.
Om te begjinnen besteegje siden mei jQuery signifikant minder oan JavaScript-ferwurking op 'e haadtried as oare siden. By de 10e percentile, yn ferliking mei alle siden, besteegje jQuery-siden op mobyl 61% mear tiid oan it ferwurkjen fan JS-koade op 'e haadtried. Yn it gefal fan buroblêd jQuery sites, ferwurkingstiid nimt ta mei 37%. Op it 90ste persintaazje skoare jQuery-siden heul ticht by de aggregearre skoares. Spesifyk besteegje jQuery-siden op mobile apparaten 1.3% minder tiid op 'e haadtried as alle siden, en 0.7% minder tiid op buroblêdapparaten.
Oan 'e oare kant fan ús wurdearring binne de kaders dy't wurde karakterisearre troch de heechste lading op' e haadtried. Dit is, wer, Angular en React. It ienige ferskil tusken de twa is dat wylst Angular-siden mear koade nei browsers stjoere dan React-siden, Angular-sites minder CPU-tiid nimme om koade te ferwurkjen. Folle minder.
Op it 10e persintaazje besteegje desktop Angular-sites 230% mear tiid oan 'e haadthread-ferwurking fan JS-koade dan alle siden. Foar mobile siden is dit sifer 313%. React sites binne de minste performers. Op buroblêd besteegje se 248% mear tiid oan it ferwurkjen fan koade dan alle siden, en 658% mear op mobyl. 658% is gjin typflater. Op it 10e persintaazje besteegje React-sites 2.7 sekonden fan haadtriedtiid troch oan it ferwurkjen fan har koade.
It 90e percentile, yn ferliking mei dizze enoarme oantallen, sjocht der teminsten in bytsje better. Yn ferliking mei alle siden besteegje Angular-projekten 29% mear tiid oan buroblêdapparaten yn 'e haadthread, en 27% mear tiid op mobile apparaten. Yn it gefal fan React-siden lykje deselde sifers respektivelik 130% en 98%.
Persintaazje ôfwikingen foar it 90e percentile sjogge better dan ferlykbere wearden foar it 10e percentile. Mar hjir is it wurdich te betinken dat de sifers dy't de tiid oanjaan, nochal skriklik lykje. Litte wy sizze 20.8 sekonden op 'e wichtichste mobile thread foar in webside boud mei React. (Ik tink dat it ferhaal fan wat der eins bart yn dizze tiid in apart artikel wurdich is).
D'r is hjir ien potinsjele komplikaasje (tank foar it tekenjen fan myn oandacht foar dizze funksje, en foar soarchfâldich beskôgje de gegevens út dit eachpunt). It feit is dat in protte siden ferskate front-end-ark brûke. Benammen haw ik in protte siden sjoen dy't jQuery njonken React of Vue brûke, om't dy siden migrearje fan jQuery nei oare kaders of bibleteken. As resultaat sloech ik de databank opnij, dizze kear selektearje ik allinich de keppelings dy't oerienkomme mei siden dy't allinich React, jQuery, Angular, of Vue brûke, mar gjin kombinaasje fan har. Hjir is wat ik krige.
Prozessortiid (yn millisekonden) relatearre oan it ferwurkjen fan skripts op mobile apparaten yn in situaasje dêr't siden mar ien ramt of mar ien bibleteek brûke
Persintilen
10
25
50
75
90
Siden dy't allinich jQuery brûke
542.9
1062.2
2297.4
4769.7
8718.2
Siden dy't allinich Vue brûke
944.0
1716.3
3194.7
5959.6
9843.8
Siden dy't allinich Angular brûke
1328.9
2151.9
3695.3
6629.3
11607.7
Siden dy't allinich React brûke
2443.2
4620.5
10061.4
17074.3
24956.3
Prozessortiid relatearre oan it ferwurkjen fan skripts op mobile apparaten yn in situaasje wêryn siden mar ien ramt brûke, of mar ien bibleteek
Earst wat dat net ferrassend is: as in side mar ien ramt of ien bibleteek brûkt, ferbetteret de prestaasjes fan sa'n side faker as net. Elk ynstrumint docht better op 'e 10e en 25e percentiles. It makket sin. In side dy't makke is mei ien ramt moat better prestearje dan in side dy't makke is mei twa of mear kaders of bibleteken.
Yn feite, de prestaasjes fan elk studearre front-end ark sjocht der better yn alle gefallen, útsein ien nijsgjirrige útsûndering. Wat my fernuvere wie dat op it 50e percentiel en boppe sites dy't React brûke, minder prestearje as React de ienige bibleteek is dy't se brûke. Dit wie trouwens de reden dat ik dizze gegevens hjir presintearje.
Dit is in bytsje nuver, mar ik sil dochs besykje te sykjen nei in ferklearring foar dizze frjemdens.
As in projekt sawol React as jQuery brûkt, dan is dat projekt wierskynlik earne healwei de oergong fan jQuery nei React. Miskien hat it in koadebasis wêr't dizze biblioteken wurde mingd. Om't wy al sjoen hawwe dat jQuery-siden minder tiid besteegje oan 'e haadthread dan React-siden, kin dit ús fertelle dat it ymplementearjen fan wat funksjonaliteit yn jQuery de side in bytsje better helpt te prestearjen.
Mar as it projekt oergiet fan jQuery nei React en fertrout mear op React, dingen feroarje. As de side echt fan hege kwaliteit is, en de side-ûntwikkelders brûke React foarsichtich, dan sil alles goed wêze mei sa'n side. Mar foar de gemiddelde React-side betsjut wiidweidich gebrûk fan React dat de haadtried ûnder swiere lêst is.
It gat tusken mobile en buroblêd apparaten
In oar eachpunt wêrfan ik de ûndersochte gegevens seach, wie om te studearjen hoe grut de kleau is tusken wurkjen mei siden op mobile en buroblêdapparaten. As wy prate oer it fergelykjen fan de folumes fan JavaScript-koade, dan sil sa'n ferliking neat ferskrikliks sjen. Fansels soe it moai wêze om lytsere hoemannichten downloadbare koade te sjen, mar d'r is net folle ferskil yn 'e hoemannichte mobyl- en buroblêdkoade.
Mar as wy de tiid analysearje dy't nedich is om de koade te ferwurkjen, wurdt in heul grutte gat tusken mobile en buroblêdapparaten merkber.
Ferheging yn tiid (persintaazje) relatearre oan it ferwurkjen fan skripts op mobile apparaten yn ferliking mei buroblêd
Persintilen
10
25
50
75
90
Alle siden
144.1
172.8
185.5
208.5
224.0
jQuery sites
188.2
187.4
191.3
209.6
221.9
Vue sites
222.5
220.8
220.2
221.4
220.4
Angular sites
205.1
206.0
201.6
210.4
218.7
Reagearje Sites
431.5
386.8
337.9
242.6
179.6
Wylst wat ferskil yn koade-ferwurkingssnelheid tusken in tillefoan en in laptop te ferwachtsjen is, fertelle sokke grutte oantallen my dat moderne kaders net genôch rjochte binne op apparaten mei leech krêft, en dat se stribje om it gat te sluten dat se ûntdutsen hawwe. Sels by it 10e persintaazje besteegje React-sites 431.5% mear tiid oan 'e mobile haadthread dan oan' e buroblêd haadthread. jQuery hat it lytste gat, mar ek hjir is it oerienkommende sifer 188.2%. As webside-ûntwikkelders har projekten op sa'n manier meitsje dat har ferwurking mear prosessortiid fereasket (en it bart, en it wurdt allinich slimmer mei de tiid), moatte eigners fan apparaten mei leech oandriuwing dêrfoar betelje.
Resultaten
Goede kaders moatte ûntwikkelders in goede basis jaan foar it bouwen fan webprojekten (yn termen fan feiligens, tagonklikens, prestaasjes), of se moatte ynboude beheiningen hawwe dy't it dreech meitsje om iets te bouwen dat yn striid is mei dy beheiningen.
Dit liket net fan tapassing te wêzen foar de prestaasjes fan webprojekten (en nei alle gedachten net foar har ).
It is de muoite wurdich op te merken dat gewoan om't React- as Angular-siden mear CPU-tiid besteegje oan it tarieden fan koade dan oaren, net needsaaklik betsjuttet dat React-siden CPU-yntinsiver binne dan Vue-siden by it rinnen. Yn feite sizze de gegevens dy't wy hawwe hifke, heul min oer de operasjonele prestaasjes fan kaders en bibleteken. Se prate mear oer de ûntwikkelingsbenaderingen dy't, bewust of net, dizze kaders programmeurs kinne triuwe. Wy hawwe it oer dokumintaasje foar kaders, oer har ekosysteem, oer mienskiplike ûntwikkelingstechniken.
It is ek de muoite wurdich om iets te neamen dat wy hjir net analysearren, nammentlik hoefolle tiid it apparaat besteget oan it útfieren fan JavaScript-koade by it navigearjen tusken siden fan 'e side. It argumint yn it foardiel fan SPA is dat ienris de ien-side-applikaasje yn 'e browser is laden, de brûker teoretysk de siden fan' e side flugger kin iepenje. Myn eigen ûnderfining seit my dat dit fier fan in feit is. Mar wy hawwe gjin gegevens om dit probleem te ferdúdlikjen.
Wat dúdlik is, is dat as jo in ramt of biblioteek brûke om in webside te meitsjen, jo in kompromis meitsje yn termen fan it earstoan laden fan it projekt en it klear meitsje om te gean. Dit jildt sels foar de meast positive senario's.
It is perfoarst mooglik om guon kompromissen te meitsjen yn passende situaasjes, mar it is wichtich dat ûntwikkelders sokke kompromissen bewust meitsje.
Mar wy hawwe ek reden foar optimisme. Ik bin optein om te sjen hoe nau de Chrome-ûntwikkelders wurkje mei de ûntwikkelders fan guon fan 'e front-end-ark dy't wy hawwe hifke yn in poging om de prestaasjes fan dy ark te ferbetterjen.
Ik bin lykwols in pragmatysk persoan. Nije arsjitektuer meitsje prestaasjesproblemen sa faak as se se oplosse. En it duorret tiid om bugs te reparearjen. Krekt sa't wy net ferwachtsje moatte sil alle prestaasjesproblemen oplosse, jo moatte dit net ferwachtsje fan nije ferzjes fan ús favorite kaders.
As jo ien fan 'e front-end-ark brûke wolle dy't yn dit artikel besprutsen binne, betsjuttet it dat jo ekstra ynspanning moatte sette om de prestaasjes fan jo projekt yn 'e tuskentiid net te skealjen. Hjir binne wat oerwegings dy't jo moatte beskôgje foardat jo in nij ramt begjinne:
- Test dysels mei sûn ferstân. Moatte jo it keazen ramt wirklik brûke? Pure JavaScript is hjoed in protte by steat.
- Is d'r in lichter alternatyf foar it keazen ramt (lykas Preact, Svelte of wat oars) dat jo 90% fan 'e mooglikheden fan dit ramt kin jaan?
- As jo al in ramt brûke, beskôgje as d'r wat is dat bettere, konservative, standert opsjes biedt (bgl. Nuxt.js ynstee fan Vue, Next.js ynstee fan React, ensfh.).
- Wat sil dyn JavaSkript prestaasjes?
- Hoe kinsto in ûntwikkelingsproses om it dreger te meitsjen om mear JavaSkript-koade yn in projekt te ynjeksje dan perfoarst nedich is?
- As jo in ramt brûke foar maklik ûntwikkeling, beskôgje dan stjoer ramtkoade oan kliïnten. Miskien kinne jo alle problemen op 'e tsjinner oplosse?
Normaal binne dizze ideeën it wurdich om nei te sjen, nettsjinsteande wat jo krekt hawwe keazen foar front-endûntwikkeling. Mar se binne benammen wichtich as jo wurkje oan in projekt dat fan it begjin ôf oan prestaasjes mist.
Dear readers! Hoe sjogge jo it ideale JavaSkript-ramt?
Boarne: www.habr.com