Daar is geen vinniger manier om 'n webwerf te vertraag (geen woordspeling bedoel nie) as om 'n klomp JavaScript-kode daarop uit te voer. As u JavaScript gebruik, moet u ten minste vier keer daarvoor betaal in projekprestasie. Hier is waarmee die werf se JavaScript-kode gebruikers se stelsels laai:
- Laai 'n lêer oor die netwerk op.
- Ontleding en samestelling van die uitgepakte bronkode na aflaai.
- Voer tans JavaScript-kode uit.
- Geheueverbruik.
Hierdie kombinasie blyk te wees .
En ons sluit meer en meer JS-kode by ons projekte in. Soos organisasies beweeg na werwe wat deur raamwerke en biblioteke soos React, Vue en ander aangedryf word, maak ons die kernfunksionaliteit van die werwe baie afhanklik van JavaScript.
Ek het baie baie swaar webwerwe gesien wat JavaScript-raamwerke gebruik. Maar my visie van die kwessie is sterk bevooroordeeld. Die feit is dat die maatskappye met wie ek werk, na my toe kom, juis omdat hulle komplekse webwerfprestasieprobleme het. Gevolglik het ek nuuskierig geraak om te weet hoe wydverspreid hierdie probleem is, en watter "boetes" ons betaal wanneer ons een of ander raamwerk as basis vir 'n sekere webwerf kies.
Hierdie projek het my gehelp om dit uit te vind. .
Data
Die HTTP-argiefprojek volg 'n totaal van 4308655 5484239 XNUMX skakels na gewone rekenaarwebwerwe en XNUMX XNUMX XNUMX skakels na mobiele werwe. Onder die vele aanwysers wat met hierdie skakels geassosieer word, is 'n lys van tegnologieë wat op die ooreenstemmende webwerwe gevind word. Dit beteken dat ons duisende werwe kan monster wat verskillende raamwerke en biblioteke gebruik en leer hoeveel kode hulle aan kliënte stuur en hoeveel las daardie kode op gebruikers se stelsels plaas.
Ek het data vanaf Maart 2020 ingesamel, wat die mees onlangse data was waartoe ek toegang gehad het.
Ek het besluit om die saamgevoegde HTTP-argiefdata vir alle werwe te vergelyk met data vir werwe wat gevind is dat hulle React, Vue en Angular gebruik, hoewel ek dit oorweeg het om ook ander bronmateriaal te gebruik.
Om dit meer interessant te maak, het ek ook werwe wat jQuery gebruik by die brondatastel gevoeg. Hierdie biblioteek is steeds baie gewild. Dit stel ook 'n benadering tot webwerf-ontwikkeling bekend wat verskil van die Single Page Application (SPA)-model wat deur React, Vue en Angular aangebied word.
Skakels in die HTTP-argief wat werwe verteenwoordig wat gevind is dat hulle tegnologieë gebruik wat vir ons van belang is
Raamwerk of biblioteek
Skakels na mobiele werwe
Skakels na gewone webwerwe
jQuery
4615474
3714643
reageer
489827
241023
Vue
85649
43691
Hoekige
19423
18088
Hoop en drome
Voordat ons verder gaan met die ontleding van die data, wil ek praat oor wat ek graag sou wou hoop.
Ek glo dat raamwerke in 'n ideale wêreld verder gaan as om aan die behoeftes van ontwikkelaars te voldoen en 'n paar konkrete voordele aan die alledaagse gebruikers van ons werwe bied. Produktiwiteit is net een van daardie voordele. Toeganklikheid en veiligheid kom ook hier ter sprake. Maar dit is net die belangrikste ding.
Dus, in 'n ideale wêreld, behoort 'n soort raamwerk dit makliker te maak om 'n hoëprestasie-webwerf te skep. Dit moet gedoen word óf as gevolg van die feit dat die raamwerk die ontwikkelaar 'n ordentlike basis gee waarop 'n projek gebou kan word, óf as gevolg van die feit dat dit beperkings op die ontwikkeling stel en vereistes daarvoor stel wat dit moeilik maak om iets te ontwikkel. dit blyk stadig te wees.
Die beste raamwerke moet albei doen: 'n goeie basis bied en beperkings op die werk stel wat jou toelaat om 'n ordentlike resultaat te behaal.
Die ontleding van die mediaanwaardes van die data sal ons nie die inligting gee wat ons nodig het nie. En in werklikheid laat hierdie benadering buite ons aandag . In plaas daarvan het ek persentieltellings afgelei van die data wat ek gehad het. Dit is die 10, 25, 50 (mediaan), 75, 90 persentiele.
Ek stel veral belang in die 10de en 90ste persentiele. Die 10de persentiel verteenwoordig die beste prestasie (of ten minste min of meer naby die beste) vir 'n spesifieke raamwerk. Met ander woorde, dit beteken dat slegs 10% van webwerwe wat 'n spesifieke raamwerk gebruik, hierdie vlak, of 'n hoër vlak, bereik. Die 90ste persentiel, aan die ander kant, is die ander kant van die munt – dit wys ons hoe sleg dinge kan wees. Die 90ste persentiel is die agterste webwerwe—die laaste 10% van webwerwe wat die grootste hoeveelheid JS-kode of die langste tyd het wat nodig is om hul kode op die hoofdraad te verwerk.
Volumes van JavaScript-kode
Om mee te begin, maak dit sin om die grootte van die JavaScript-kode wat deur verskillende werwe oor die netwerk versend word, te ontleed.
Hoeveelheid JavaScript-kode (KB) wat na mobiele toestelle oorgedra is
Persentiele
10
25
50
75
90
Alle werwe
93.4
196.6
413.5
746.8
1201.6
jQuery-webwerwe
110.3
219.8
430.4
748.6
1162.3
Vue-webwerwe
244.7
409.3
692.1
1065.5
1570.7
Hoekige webwerwe
445.1
675.6
1066.4
1761.5
2893.2
Reageer webwerwe
345.8
441.6
690.3
1238.5
1893.6
Hoeveelheid JavaScript-kode wat na mobiele toestelle gestuur is
Hoeveelheid JavaScript-kode (KB) wat na rekenaartoestelle oorgedra is
Persentiele
10
25
50
75
90
Alle werwe
105.5
226.6
450.4
808.8
1267.3
jQuery-webwerwe
121.7
242.2
458.3
803.4
1235.3
Vue-webwerwe
248.0
420.1
718.0
1122.5
1643.1
Hoekige webwerwe
468.8
716.9
1144.2
1930.0
3283.1
Reageer webwerwe
308.6
469.0
841.9
1472.2
2197.8
Hoeveelheid JavaScript-kode wat na rekenaartoestelle oorgedra is
As ons net praat oor die grootte van die JS-kode wat webwerwe na toestelle stuur, dan lyk alles omtrent soos u kan verwag. As een van die raamwerke gebruik word, beteken dit naamlik dat selfs in 'n ideale situasie die volume JavaScript-kode vir die webwerf sal toeneem. Dit is nie verbasend nie - jy kan nie 'n JavaScript-raamwerk die basis van 'n webwerf maak en verwag dat die hoeveelheid JS-kode vir die projek baie laag sal wees nie.
Wat interessant is van hierdie data, is dat sommige raamwerke en biblioteke as beter beginpunte vir 'n projek as ander beskou kan word. Webwerwe met jQuery lyk die beste. Hul rekenaarwebwerwe bevat 15% meer JavaScript as alle werwe, en hul mobiele werwe bevat 18% meer JavaScript. (Daar is weliswaar 'n mate van skeefheid in die data hier. Die feit is dat jQuery op baie werwe teenwoordig is, so dit is natuurlik dat sulke webwerwe nouer verwant is aan die totale aantal webwerwe as ander. Dit beïnvloed egter nie hoe brondata word vir elke raamwerk uitgevoer.)
Terwyl 15-18% kodegroei 'n beduidende syfer is, in vergelyking met ander raamwerke en biblioteke, is die belasting wat deur jQuery opgelê word, baie laag. Hoekige werwe in die 10de persentiel stuur 344% meer data na rekenaartoestelle as alle werwe, en 377% meer na mobiele toestelle. Reageer-webwerwe is die volgende swaarste, en stuur 193% meer kode na rekenaartoestelle as alle werwe, en 270% meer na mobiele toestelle.
Ek het vroeër genoem dat alhoewel die gebruik van 'n raamwerk beteken dat 'n sekere hoeveelheid kode by die projek ingesluit sal word aan die begin van die werk daaraan, hoop ek dat die raamwerk die ontwikkelaar op een of ander manier kan beperk. In die besonder, ons praat oor die beperking van die maksimum hoeveelheid kode.
Wat interessant is, is dat jQuery-webwerwe hierdie idee volg. Alhoewel hulle, op die 10de persentielvlak, effens swaarder is as alle werwe (met 15-18%), is hulle, op die 90ste persentielvlak, effens ligter as alle werwe - met ongeveer 3% in beide rekenaar- en mobiele weergawes. Dit is nie te sê dat dit 'n baie belangrike voordeel is nie, maar daar kan gesê word dat jQuery-webwerwe ten minste nie groot JavaScript-kodegroottes het nie, selfs in hul grootste weergawes.
Maar dieselfde kan nie oor ander raamwerke gesê word nie.
Net soos in die geval van die 10de persentiel, by die 90ste persentiel verskil terreine op Angular en React van ander webwerwe, maar hulle verskil, ongelukkig, vir die erger.
By die 90ste persentiel stuur Angular-webwerwe 141% meer data na mobiele toestelle as alle werwe, en 159% meer na rekenaartoestelle. Reageer-werwe stuur 73% meer na rekenaartoestelle as alle werwe, en 58% meer na mobiele toestelle. Die kodegrootte van React-webwerwe by die 90ste persentiel is 2197.8 KB. Dit beteken dat hierdie werwe 322.9 KB meer data na mobiele toestelle stuur as hul naaste Vue-gebaseerde mededingers. Die gaping tussen rekenaarwebwerwe gebaseer op Angular en React en ander werwe is selfs groter. Byvoorbeeld, React-rekenaarwebwerwe stuur 554.7 KB meer JS-kode na toestelle as soortgelyke Vue-webwerwe.
Tyd geneem om JavaScript-kode op die hoofdraad te verwerk
Bogenoemde data dui duidelik aan dat die werwe wat die raamwerke en biblioteke wat bestudeer gebruik, groot hoeveelhede JavaScript-kode bevat. Maar dit is natuurlik net een deel van ons vergelyking.
Nadat die JavaScript-kode in die blaaier aangekom het, moet dit in 'n werkende toestand gebring word. Veral baie probleme word veroorsaak deur daardie aksies wat met kode in die hoofblaaierdraad uitgevoer moet word. Die hoofdraad is verantwoordelik vir die verwerking van gebruikershandelinge, berekening van style en die bou en vertoon van die bladsyuitleg. As jy die hoofdraad met JavaScript-take oorweldig, sal dit nie die geleentheid hê om ander take betyds te voltooi nie. Dit lei tot vertragings en "remme" in die werking van bladsye.
Die HTTP-argiefdatabasis bevat inligting oor hoe lank dit neem om JavaScript-kode op die hoofdraad van die V8-enjin te verwerk. Dit beteken dat ons hierdie data kan insamel en leer hoeveel tyd die hoofdraad neem om die JavaScript van verskeie werwe te verwerk.
SVE-tyd (in millisekondes) wat verband hou met skripverwerking op mobiele toestelle
Persentiele
10
25
50
75
90
Alle werwe
356.4
959.7
2372.1
5367.3
10485.8
jQuery-webwerwe
575.3
1147.4
2555.9
5511.0
10349.4
Vue-webwerwe
1130.0
2087.9
4100.4
7676.1
12849.4
Hoekige webwerwe
1471.3
2380.1
4118.6
7450.8
13296.4
Reageer webwerwe
2700.1
5090.3
9287.6
14509.6
20813.3
SVE-tyd wat verband hou met skrifverwerking op mobiele toestelle
SVE-tyd (in millisekondes) wat verband hou met skripverwerking op rekenaartoestelle
Persentiele
10
25
50
75
90
Alle werwe
146.0
351.8
831.0
1739.8
3236.8
jQuery-webwerwe
199.6
399.2
877.5
1779.9
3215.5
Vue-webwerwe
350.4
650.8
1280.7
2388.5
4010.8
Hoekige webwerwe
482.2
777.9
1365.5
2400.6
4171.8
Reageer webwerwe
508.0
1045.6
2121.1
4235.1
7444.3
SVE-tyd wat verband hou met skrifverwerking op rekenaartoestelle
Hier kan jy iets baie bekend sien.
Om mee te begin spandeer werwe met jQuery aansienlik minder aan die verwerking van JavaScript op die hoofdraad as ander. By die 10de persentiel, in vergelyking met alle werwe, spandeer jQuery-webwerwe op mobiele toestelle 61% meer tyd om JS-kode op die hoofdraad te verwerk. In die geval van desktop jQuery-webwerwe, neem die verwerkingstyd met 37% toe. By die 90ste persentiel is jQuery-webwerwe se tellings baie naby aan die totale tellings. Spesifiek, jQuery-webwerwe op mobiele toestelle spandeer 1.3% minder tyd in die hoofdraad as alle werwe, en op rekenaartoestelle spandeer hulle 0.7% minder tyd in die hoofdraad.
Aan die ander kant van ons gradering is raamwerke wat gekenmerk word deur die grootste las op die hoofdraad. Dit is weereens Angular and React. Die enigste verskil tussen hulle is dat, hoewel Angular-webwerwe groter hoeveelhede kode na blaaiers stuur as React-webwerwe, dit minder SVE-tyd neem om die kode van Angular-webwerwe te verwerk. Veel minder.
By die 10de persentiel bestee Angular lessenaarwebwerwe 230% meer hoofdraadtyd aan die verwerking van JS-kode as alle werwe. Vir mobiele werwe is hierdie syfer 313%. Reageer-webwerwe het die swakste prestasie. Op rekenaartoestelle spandeer hulle 248% meer tyd aan die verwerking van kode as alle werwe, en op mobiele toestelle spandeer hulle 658% meer tyd aan die verwerking van kode. 658% is nie 'n tikfout nie. By die 10de persentiel spandeer React-webwerwe 2.7 sekondes se hoofdraadtyd om hul bestaande kode te verwerk.
Die 90ste persentiel getalle lyk ten minste 'n bietjie beter in vergelyking met hierdie groot getalle. Hoekprojekte, in vergelyking met alle werwe, spandeer 29% meer tyd in die hoofdraad op rekenaartoestelle, en 27% meer tyd op mobiele toestelle. In die geval van React-webwerwe lyk soortgelyke aanwysers onderskeidelik 130% en 98%.
Die afwykingpersentasies vir die 90ste persentiel lyk beter as die soortgelyke waardes vir die 10de persentiel. Maar hier is dit die moeite werd om te onthou dat die syfers wat tyd aandui nogal skrikwekkend lyk. Kom ons sê - 20.8 sekondes in die hoofdraad van 'n mobiele toestel vir 'n webwerf wat op React gebou is. (Ek glo die storie van wat eintlik gedurende hierdie tyd gebeur, is 'n aparte artikel werd).
Daar is een potensiële komplikasie hier (dankie om my aandag op hierdie kenmerk te vestig en die data noukeurig vanuit hierdie oogpunt te ondersoek). Die feit is dat baie werwe verskeie front-end gereedskap gebruik. Ek het veral gesien dat baie werwe jQuery saam met React of Vue gebruik, aangesien hierdie werwe van jQuery na ander raamwerke of biblioteke migreer. Gevolglik het ek teruggegaan na die databasis en hierdie keer net daardie skakels gekies wat ooreenstem met werwe wat slegs React, jQuery, Angular of Vue gebruik het, maar nie enige kombinasie daarvan nie. Hier is wat ek gekry het.
Verwerkertyd (in millisekondes) wat verband hou met skripverwerking op mobiele toestelle in situasies waar werwe slegs een raamwerk of slegs een biblioteek gebruik
Persentiele
10
25
50
75
90
Webwerwe wat slegs jQuery gebruik
542.9
1062.2
2297.4
4769.7
8718.2
Werwe wat slegs Vue gebruik
944.0
1716.3
3194.7
5959.6
9843.8
Werwe wat slegs Angular gebruik
1328.9
2151.9
3695.3
6629.3
11607.7
Webwerwe wat slegs React gebruik
2443.2
4620.5
10061.4
17074.3
24956.3
Verwerkertyd wat verband hou met die verwerking van skrifte op mobiele toestelle in 'n situasie waar werwe slegs een raamwerk, of slegs een biblioteek gebruik
Eerstens, iets wat nie verbasend is nie: wanneer 'n webwerf slegs een raamwerk of een biblioteek gebruik, verbeter die werkverrigting van so 'n webwerf meer dikwels as nie. Die werkverrigting vir elke instrument lyk beter by die 10de en 25ste persentiele. Dit maak sin. 'n Werf wat met een raamwerk gemaak word, moet vinniger wees as 'n werf wat gemaak is deur twee of meer raamwerke of biblioteke te gebruik.
Trouens, die tellings vir elke front-end-instrument wat ons ondersoek het, het in alle gevalle beter gelyk, met een eienaardige uitsondering. Wat my verbaas het, was dat webwerwe wat React by die 50ste persentiel en hoër gebruik, swakker presteer wanneer React die enigste biblioteek is wat hulle gebruik. Dit was terloops die rede waarom ek hierdie data hier aanbied.
Dit is 'n bietjie vreemd, maar ek sal tog probeer om 'n verduideliking vir hierdie vreemdheid te soek.
As 'n projek beide React en jQuery gebruik, dan is daardie projek heel waarskynlik iewers halfpad in die proses om van jQuery na React te migreer. Miskien het hy 'n kodebasis waarin hierdie biblioteke gemeng is. Aangesien ons reeds gesien het dat jQuery-webwerwe minder tyd aan die hoofdraad bestee as React-webwerwe, kan dit vir ons sê dat die implementering van sommige funksies in jQuery help om werfprestasie 'n bietjie te verbeter.
Maar soos die projek van jQuery na React beweeg en meer en meer op React staatmaak, verander die situasie. As die webwerf met werklik hoë gehalte gemaak is, en die webwerf-ontwikkelaars gebruik React versigtig, dan sal alles in orde wees met so 'n webwerf. Maar vir die gemiddelde React-werf beteken uitgebreide gebruik van React dat die hoofdraad onderhewig is aan verhoogde las.
Die gaping tussen mobiele en rekenaartoestelle
Nog 'n manier waarop ek na die data gekyk het, was om te verken hoe groot die gaping tussen mobiele en rekenaarervarings is. As ons praat oor die vergelyking van die volumes van JavaScript-kode, dan openbaar so 'n vergelyking niks verskrikliks nie. Natuurlik sal dit lekker wees om kleiner hoeveelhede aflaaibare kode te sien, maar daar is nie veel verskil in die hoeveelheid selfoon- en rekenaarkode nie.
Maar as jy die tyd wat nodig is om die kode te verwerk ontleed, word 'n baie groot gaping tussen mobiele en rekenaartoestelle opmerklik.
Toename in tyd (in persentasie) wat verband hou met skrifverwerking op mobiele toestelle in vergelyking met rekenaars
Persentiele
10
25
50
75
90
Alle werwe
144.1
172.8
185.5
208.5
224.0
jQuery-webwerwe
188.2
187.4
191.3
209.6
221.9
Vue-webwerwe
222.5
220.8
220.2
221.4
220.4
Hoekige webwerwe
205.1
206.0
201.6
210.4
218.7
Reageer webwerwe
431.5
386.8
337.9
242.6
179.6
Terwyl 'n mate van verskil in kodeverwerkingspoed tussen 'n foon en 'n skootrekenaar verwag kan word, vertel sulke groot getalle vir my dat moderne raamwerke nie genoeg op laekragtoestelle gerig is nie en die begeerte om die gaping wat geïdentifiseer is, te sluit. Selfs by die 10de persentiel spandeer React-webwerwe 431.5% meer tyd aan die mobiele hoofdraad as aan die rekenaarhoofdraad. jQuery het die kleinste gaping, maar selfs hier is die ooreenstemmende syfer 188.2%. Wanneer webwerf-ontwikkelaars hul projekte op so 'n manier maak dat hulle meer SVE-tyd benodig om dit te verwerk (en dit is wat gebeur, en dit word net erger met verloop van tyd), moet eienaars van laekragtoestelle daarvoor betaal.
Resultate van
Goeie raamwerke moet ontwikkelaars 'n goeie grondslag gee vir die bou van webprojekte (in terme van sekuriteit, toeganklikheid, werkverrigting), of moet ingeboude beperkings hê wat dit moeilik maak om iets te skep wat daardie beperkings oortree.
Dit blyk nie van toepassing te wees op die prestasie van webprojekte nie (en blykbaar vir hul ).
Dit is opmerklik dat net omdat React- of Angular-webwerwe meer SVE-tyd spandeer om kode voor te berei as ander, dit nie noodwendig beteken dat React-webwerwe meer SVE-intensief is as Vue-webwerwe wanneer hulle loop nie. Trouens, die data waarna ons gekyk het, sê baie min oor die operasionele prestasie van raamwerke en biblioteke. Hulle praat meer oor die ontwikkelingsbenaderings wat, bewustelik of nie, hierdie raamwerke programmeerders kan stoot. Ons praat van dokumentasie vir raamwerke, hul ekosisteem en algemene ontwikkelingstegnieke.
Dit is ook die moeite werd om iets te noem wat ons nie hier ontleed het nie, naamlik hoeveel tyd die toestel spandeer om JavaScript-kode uit te voer wanneer daar tussen bladsye van die webwerf oorgeskakel word. Die argument ten gunste van SPA is dat sodra die enkelbladsy-toepassing in die blaaier gelaai is, die gebruiker in teorie vinniger toegang tot die werf se bladsye sal kan kry. My eie ervaring sê vir my dat dit ver van 'n feit is. Maar ons het nie data om hierdie kwessie op te klaar nie.
Wat duidelik is, is dat as u 'n raamwerk of biblioteek gebruik om 'n webwerf te skep, u 'n kompromie aangaan in terme van die aanvanklike laai van die projek en om dit gereed te maak om te gaan. Dit geld selfs vir die mees positiewe scenario's.
Dit is moontlik om sekere kompromieë in toepaslike situasies aan te gaan, maar dit is belangrik dat ontwikkelaars bewustelik sulke kompromieë aangaan.
Maar ons het ook rede tot optimisme. Ek is bemoedig deur hoe nou die Chrome-ontwikkelaars saamwerk met diegene agter sommige van die voorkantnutsgoed wat ons gedek het om die werkverrigting van daardie nutsgoed te help verbeter.
Ek is egter 'n pragmatiese mens. Nuwe argitekture skep prestasieprobleme so dikwels as wat hulle dit oplos. En dit neem tyd om die tekortkominge uit te skakel. Net soos ons dit nie moet verwag nie alle prestasieprobleme sal oplos, moet jy dit nie van nuwe weergawes van ons gunsteling raamwerke verwag nie.
As jy een van die voorkantnutsmiddels wat in hierdie materiaal bespreek word wil gebruik, beteken dit dat jy bykomende pogings sal moet aanwend om te verseker dat jy terloops nie die prestasie van jou projek benadeel nie. Hier is 'n paar oorwegings wat u moet oorweeg voordat u 'n nuwe raamwerk begin gebruik:
- Kontroleer jouself met gesonde verstand. Moet jy regtig jou gekose raamwerk gebruik? Suiwer JavaScript kan vandag baie doen.
- Is daar 'n ligter alternatief vir die raamwerk van jou keuse (soos Preact, Svelte of iets anders) wat jou 90% van die vermoëns van daardie raamwerk kan gee?
- As jy reeds 'n raamwerk gebruik, dink daaraan of daar iets is wat beter, meer konserwatiewe standaardopsies bied (byvoorbeeld Nuxt.js in plaas van Vue, Next.js in plaas van React, ens.).
- Wat sal jou JavaScript prestasie?
- Hoe kan jy ontwikkelingsproses om dit moeiliker te maak om meer JavaScript-kode in 'n projek in te voer as wat absoluut nodig is?
- As jy 'n raamwerk gebruik vir gemak van ontwikkeling, oorweeg dit stuur raamwerkkode aan kliënte. Miskien kan jy al die probleme op die bediener oplos?
Gewoonlik is hierdie idees die moeite werd om nader te kyk, ongeag wat jy presies kies om die voorkant te ontwikkel. Maar hulle is veral belangrik wanneer jy aan 'n projek werk wat nie werkverrigting het om mee te begin nie.
Beste lesers! Wat sien jy as die ideale JavaScript-raamwerk?
Bron: will.com