Er is geen snellere manier om een website te vertragen (bedoelde woordspeling) dan door er een heleboel JavaScript-code op te gebruiken. Bij het gebruik van JavaScript moet je er maar liefst vier keer voor betalen met de uitvoering van projecten. Hier is hoe de JavaScript-code van de site de systemen van gebruikers laadt:
- Een bestand downloaden via het netwerk.
- Parseren en compileren van uitgepakte broncode na download.
- Uitvoering van JavaScript-code.
- Geheugenverbruik.
Deze combinatie blijkt .
En we nemen steeds meer JS-code op in onze projecten. Naarmate organisaties evolueren naar sites die worden aangedreven door frameworks en bibliotheken zoals React, Vue en andere, maken we de kernfunctionaliteit van sites zeer sterk afhankelijk van JavaScript.
Ik heb veel zeer zware sites gezien die JavaScript-frameworks gebruiken. Maar mijn visie op de kwestie is erg bevooroordeeld. Feit is dat de bedrijven waar ik mee werk zich juist tot mij wenden omdat ze te maken hebben met complexe problemen op het gebied van site performance. Als gevolg hiervan werd ik nieuwsgierig naar hoe vaak dit probleem voorkomt en naar wat voor soort "sancties" we betalen als we een of ander framework kiezen als basis voor een bepaalde site.
Het project heeft me geholpen om dit uit te zoeken. .
Gegevens
Het HTTP Archive-project volgt in totaal 4308655 links naar gewone desktopsites en 5484239 links naar mobiele sites. Een van de vele statistieken die aan deze links zijn gekoppeld, is een lijst met technologieën die op de respectieve sites zijn gevonden. Dit betekent dat we duizenden sites kunnen testen die verschillende frameworks en bibliotheken gebruiken en leren hoeveel code ze naar klanten sturen en hoeveel belasting deze code veroorzaakt op de systemen van gebruikers.
Ik heb gegevens van maart 2020 verzameld, de meest recente gegevens waartoe ik toegang had.
Ik besloot om geaggregeerde HTTP-archiefgegevens van alle sites te vergelijken met gegevens van sites gevonden met React, Vue en Angular, hoewel ik overwoog om ook ander bronmateriaal te gebruiken.
Om het interessanter te maken, heb ik ook sites die jQuery gebruiken toegevoegd aan de brongegevensset. Deze bibliotheek is nog steeds erg populair. Het introduceert ook een andere benadering van webontwikkeling dan het Single Page Application (SPA)-model dat wordt aangeboden door React, Vue en Angular.
Links in het HTTP-archief die sites vertegenwoordigen waarvan is vastgesteld dat ze interessante technologieën gebruiken
Kader of bibliotheek
Links naar mobiele sites
Links naar reguliere sites
jQuery
4615474
3714643
Reageren
489827
241023
Vue
85649
43691
Angular
19423
18088
Hoop en dromen
Voordat we verder gaan met data-analyse, wil ik het hebben over waar ik op zou willen hopen.
Ik ben van mening dat in een ideale wereld frameworks verder moeten gaan dan alleen voldoen aan de behoeften van ontwikkelaars en een specifiek voordeel moeten bieden aan de gemiddelde gebruiker die met onze sites werkt. Prestaties zijn slechts een van die voordelen. Dit is waar toegankelijkheid en veiligheid een rol spelen. Maar dit is alleen het belangrijkste.
Dus in een ideale wereld zou een soort framework het gemakkelijk moeten maken om een krachtige site te maken. Dit moet worden gedaan ofwel vanwege het feit dat het raamwerk de ontwikkelaar een behoorlijke basis geeft om een project op te bouwen, ofwel vanwege het feit dat het beperkingen oplegt aan de ontwikkeling, eisen stelt die de ontwikkeling bemoeilijken van iets dat verandert uit om langzaam te zijn.
De beste frameworks zouden beide moeten doen: een goede basis geven, en beperkingen opleggen aan het werk, waardoor je een fatsoenlijk resultaat kunt behalen.
Het analyseren van de mediaanwaarden van de gegevens geeft ons niet de informatie die we nodig hebben. En in feite gaat deze benadering buiten onze aandacht . In plaats daarvan heb ik percentages afgeleid uit de gegevens die ik had. Dit zijn 10, 25, 50 (mediaan), 75, 90 percentielen.
Ik ben vooral geïnteresseerd in het 10e en 90e percentiel. Het 10e percentiel vertegenwoordigt de allerbeste prestatie (of in ieder geval min of meer dicht bij de beste) voor een bepaald raamwerk. Met andere woorden, dit betekent dat slechts 10% van de sites die een bepaald framework gebruiken dit niveau of hoger halen. Het 90e percentiel daarentegen is de andere kant van de medaille - het laat ons zien hoe erg dingen kunnen worden. Het 90e percentiel zijn de sites die achterblijven: de onderste 10% van de sites met de meeste JS-code of de langste tijd om hun code op de hoofdthread te verwerken.
Volumes JavaScript-code
Om te beginnen is het zinvol om de grootte van de JavaScript-code die door verschillende sites via het netwerk wordt verzonden, te analyseren.
De hoeveelheid JavaScript-code (Kb) die is overgedragen naar mobiele apparaten
Percentielen
10
25
50
75
90
Alle locaties
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
Hoekige sites
445.1
675.6
1066.4
1761.5
2893.2
Reageer sites
345.8
441.6
690.3
1238.5
1893.6
Hoeveelheid JavaScript-code die naar mobiele apparaten is verzonden
Hoeveelheid JavaScript-code (Kb) die is overgedragen naar desktopapparaten
Percentielen
10
25
50
75
90
Alle locaties
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
Hoekige sites
468.8
716.9
1144.2
1930.0
3283.1
Reageer sites
308.6
469.0
841.9
1472.2
2197.8
Hoeveelheid JavaScript-code die naar desktopapparaten is verzonden
Als we het alleen hebben over de grootte van de JS-code die sites naar apparaten sturen, dan ziet alles er ongeveer uit zoals je zou verwachten. Als een van de frameworks wordt gebruikt, betekent dit namelijk dat zelfs in een ideale situatie het volume van de JavaScript-code van de site zal toenemen. Dit is niet verrassend - u kunt een JavaScript-framework niet tot basis van een site maken en verwachten dat het volume van de JS-code van het project erg laag zal zijn.
Het opmerkelijke aan deze gegevens is dat sommige frameworks en bibliotheken als een beter startpunt voor een project kunnen worden beschouwd dan andere. Sites met jQuery zien er het beste uit. Op desktopversies van sites bevatten ze 15% meer JavaScript dan alle sites, en op mobiele apparaten bevatten ze 18% meer. (Toegegeven, er is hier enige datacorruptie. Feit is dat jQuery op veel sites aanwezig is, dus het is niet meer dan normaal dat dergelijke sites nauwer verbonden zijn dan andere met het totale aantal sites. Dit heeft echter geen invloed op hoe onbewerkt gegevens worden uitgevoerd voor elk raamwerk.)
Hoewel de toename van het codevolume met 15-18% een opmerkelijk cijfer is, kan men in vergelijking met andere frameworks en bibliotheken concluderen dat de "belasting" die door jQuery wordt geheven erg laag is. Hoekige sites in het 10e percentiel sturen 344% meer data naar desktop dan alle sites, en 377% meer naar mobiel. React-sites zijn de op een na zwaarste, ze sturen 193% meer code naar desktop dan alle sites, en 270% meer naar mobiel.
Eerder heb ik gezegd dat hoewel het gebruik van een raamwerk betekent dat een bepaalde hoeveelheid code in het project wordt opgenomen, ik hoop dat het raamwerk de ontwikkelaar aan het begin van het werk op de een of andere manier kan beperken. We hebben het met name over het beperken van de maximale hoeveelheid code.
Interessant is dat jQuery-sites dit idee volgen. Hoewel ze iets zwaarder zijn dan alle sites in het 10e percentiel (met 15-18%), zijn ze iets lichter in het 90e percentiel met ongeveer 3% op zowel desktop als mobiel. Dit wil niet zeggen dat dit een zeer belangrijk voordeel is, maar er kan wel worden gezegd dat jQuery-sites in ieder geval geen enorme JavaScript-codegroottes hebben, zelfs niet in hun grootste versies.
Maar hetzelfde kan niet gezegd worden over andere kaders.
Net als in het geval van het 10e percentiel, verschillen sites op Angular en React bij het 90e percentiel van andere sites, maar ze verschillen helaas ten kwade.
Op het 90e percentiel sturen Angular-sites 141% meer data naar mobiel dan alle sites, en 159% meer naar desktop. React-sites sturen 73% meer naar desktop dan alle sites, en 58% meer naar mobiel. De codegrootte van React-sites in het 90e percentiel is 2197.8 KB. Dit betekent dat dergelijke sites 322.9 KB meer data naar mobiele apparaten sturen dan hun naaste concurrenten op basis van Vue. De kloof tussen desktopsites op basis van Angular en React en andere sites is nog groter. Desktop React-sites sturen bijvoorbeeld 554.7 KB meer JS-code naar apparaten dan vergelijkbare Vue-sites.
Tijd die nodig is om JavaScript-code in de hoofdthread te verwerken
De bovenstaande gegevens geven duidelijk aan dat sites die gebruikmaken van de onderzochte frameworks en bibliotheken grote hoeveelheden JavaScript-code bevatten. Maar dat is natuurlijk slechts een deel van onze vergelijking.
Nadat de JavaScript-code in de browser is aangekomen, moet deze in een werkbare staat worden gebracht. Vooral veel problemen worden veroorzaakt door die acties die moeten worden uitgevoerd met de code in de hoofdbrowserthread. De rode draad is verantwoordelijk voor het verwerken van gebruikersacties, voor het berekenen van stijlen, voor het bouwen en weergeven van de paginalay-out. Als je de hoofdthread overweldigt met JavaScript-taken, heeft deze niet de mogelijkheid om de rest van de taken op tijd af te ronden. Dit leidt tot vertragingen en "remmen" in het werk van de pagina's.
De HTTP Archive-database bevat informatie over hoe lang het duurt om JavaScript-code te verwerken in de hoofdthread van de V8-engine. Dit betekent dat we deze gegevens kunnen verzamelen en kunnen achterhalen hoeveel tijd de hoofdthread nodig heeft om de JavaScript van verschillende sites te verwerken.
Processortijd (in milliseconden) gerelateerd aan scriptverwerking op mobiele apparaten
Percentielen
10
25
50
75
90
Alle locaties
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
Hoekige sites
1471.3
2380.1
4118.6
7450.8
13296.4
Reageer sites
2700.1
5090.3
9287.6
14509.6
20813.3
Processortijd gerelateerd aan scriptverwerking op mobiele apparaten
Processortijd (in milliseconden) gerelateerd aan scriptverwerking op desktopapparaten
Percentielen
10
25
50
75
90
Alle locaties
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
Hoekige sites
482.2
777.9
1365.5
2400.6
4171.8
Reageer sites
508.0
1045.6
2121.1
4235.1
7444.3
Processortijd gerelateerd aan scriptverwerking op desktopapparaten
Hier zie je iets heel bekends.
Om te beginnen besteden sites met jQuery aanzienlijk minder aan JavaScript-verwerking op de hoofdthread dan andere sites. Op het 10e percentiel, vergeleken met alle sites, besteden jQuery-sites op mobiel 61% meer tijd aan het verwerken van JS-code op de hoofdthread. In het geval van desktop jQuery-sites neemt de verwerkingstijd toe met 37%. Op het 90e percentiel scoren jQuery-sites zeer dicht bij de totale scores. In het bijzonder besteden jQuery-sites op mobiele apparaten 1.3% minder tijd aan de hoofdthread dan alle sites, en 0.7% minder tijd op desktopapparaten.
Aan de andere kant van onze beoordeling staan de frames die worden gekenmerkt door de hoogste belasting op de rode draad. Dit is wederom Angular en React. Het enige verschil tussen de twee is dat terwijl Angular-sites meer code naar browsers sturen dan React-sites, Angular-sites minder CPU-tijd nodig hebben om code te verwerken. Veel minder.
Op het 10e percentiel besteden desktop Angular-sites 230% meer tijd aan de hoofdthread die JS-code verwerkt dan alle sites. Voor mobiele sites is dit cijfer 313%. React-sites presteren het slechtst. Op desktop besteden ze 248% meer tijd aan het verwerken van code dan alle sites, en 658% meer op mobiel. 658% is geen typefout. Op het 10e percentiel besteden React-sites 2.7 seconden van de hoofdthreadtijd aan het verwerken van hun code.
Het 90e percentiel ziet er in vergelijking met deze enorme aantallen in ieder geval iets beter uit. In vergelijking met alle sites besteden Angular-projecten 29% meer tijd op desktopapparaten in de hoofdthread en 27% meer tijd op mobiele apparaten. In het geval van React-sites zien dezelfde cijfers eruit als respectievelijk 130% en 98%.
Procentuele afwijkingen voor het 90e percentiel zien er beter uit dan vergelijkbare waarden voor het 10e percentiel. Maar hier is het de moeite waard eraan te denken dat de cijfers die de tijd aangeven nogal eng lijken. Laten we zeggen 20.8 seconden op de belangrijkste mobiele thread voor een website gebouwd met React. (Ik denk dat het verhaal van wat er werkelijk gebeurt in deze tijd een apart artikel waard is).
Er is hier een mogelijke complicatie (bedankt voor het vestigen van mijn aandacht op dit kenmerk en voor het zorgvuldig overwegen van de gegevens vanuit dit oogpunt). Feit is dat veel sites meerdere front-end tools gebruiken. Ik heb met name veel sites gezien die jQuery gebruiken naast React of Vue, aangezien die sites migreren van jQuery naar andere frameworks of bibliotheken. Als gevolg hiervan ging ik opnieuw naar de database, waarbij ik deze keer alleen die links selecteerde die overeenkomen met sites die alleen React, jQuery, Angular of Vue gebruiken, maar geen combinatie daarvan. Dit is wat ik heb.
Processortijd (in milliseconden) gerelateerd aan het verwerken van scripts op mobiele apparaten in een situatie waarin sites slechts één framework of slechts één bibliotheek gebruiken
Percentielen
10
25
50
75
90
Sites die alleen jQuery gebruiken
542.9
1062.2
2297.4
4769.7
8718.2
Sites die alleen Vue gebruiken
944.0
1716.3
3194.7
5959.6
9843.8
Sites die alleen Angular gebruiken
1328.9
2151.9
3695.3
6629.3
11607.7
Sites die alleen React gebruiken
2443.2
4620.5
10061.4
17074.3
24956.3
Processortijd gerelateerd aan het verwerken van scripts op mobiele apparaten in een situatie waarin sites slechts één framework of slechts één bibliotheek gebruiken
Ten eerste iets dat niet verrassend is: wanneer een site slechts één framework of één bibliotheek gebruikt, verbeteren de prestaties van zo'n site vaker wel dan niet. Elk instrument presteert beter op het 10e en 25e percentiel. Het is logisch. Een site die met één framework is gemaakt, zou beter moeten presteren dan een site die met twee of meer frameworks of bibliotheken is gemaakt.
In feite zien de prestaties van elke bestudeerde front-endtool er in alle gevallen beter uit, behalve één merkwaardige uitzondering. Wat me verbaasde was dat sites die React gebruiken bij het 50e percentiel en hoger slechter presteren als React de enige bibliotheek is die ze gebruiken. Dit was trouwens de reden dat ik deze gegevens hier presenteer.
Dit is een beetje vreemd, maar ik zal toch proberen een verklaring voor deze vreemdheid te zoeken.
Als een project zowel React als jQuery gebruikt, bevindt dat project zich waarschijnlijk ergens halverwege de overgang van jQuery naar React. Misschien heeft het een codebase waar deze bibliotheken gemengd zijn. Aangezien we al hebben gezien dat jQuery-sites minder tijd besteden aan de hoofdthread dan React-sites, zou dit ons kunnen vertellen dat het implementeren van bepaalde functionaliteit in jQuery de site een beetje beter laat presteren.
Maar naarmate het project overgaat van jQuery naar React en meer vertrouwt op React, veranderen de dingen. Als de site echt van hoge kwaliteit is en de site-ontwikkelaars React zorgvuldig gebruiken, dan komt alles goed met zo'n site. Maar voor de gemiddelde React-site betekent uitgebreid gebruik van React dat de rode draad zwaar wordt belast.
De kloof tussen mobiele en desktop-apparaten
Een ander standpunt van waaruit ik naar de onderzochte data heb gekeken, was om te onderzoeken hoe groot de kloof is tussen het werken met sites op mobiele en desktop-apparaten. Als we het hebben over het vergelijken van de volumes JavaScript-code, dan onthult zo'n vergelijking niets vreselijks. Het zou natuurlijk leuk zijn om kleinere hoeveelheden downloadbare code te zien, maar er is niet veel verschil in de hoeveelheid mobiele en desktopcode.
Maar als we de tijd analyseren die nodig is om de code te verwerken, wordt een zeer grote kloof tussen mobiele apparaten en desktopapparaten merkbaar.
Toename in tijd (percentage) gerelateerd aan het verwerken van scripts op mobiele apparaten in vergelijking met desktop
Percentielen
10
25
50
75
90
Alle locaties
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
Hoekige sites
205.1
206.0
201.6
210.4
218.7
Reageer sites
431.5
386.8
337.9
242.6
179.6
Hoewel er enig verschil in codeverwerkingssnelheid tussen een telefoon en een laptop te verwachten is, vertellen zulke grote aantallen me dat moderne frameworks niet voldoende gericht zijn op apparaten met een laag vermogen en dat ze ernaar streven de kloof die ze hebben ontdekt te dichten. Zelfs op het 10e percentiel besteden React-sites 431.5% meer tijd aan de mobiele hoofdthread dan aan de desktopthread. jQuery heeft de kleinste kloof, maar zelfs hier is het overeenkomstige cijfer 188.2%. Wanneer website-ontwikkelaars hun projecten zo maken dat hun verwerking meer processortijd vereist (en het gebeurt, en het wordt alleen maar erger in de loop van de tijd), moeten de eigenaren van apparaten met een laag vermogen ervoor betalen.
Resultaten van
Goede frameworks moeten ontwikkelaars een goede basis geven voor het bouwen van webprojecten (in termen van beveiliging, toegankelijkheid, prestaties), of ze moeten ingebouwde beperkingen hebben die het moeilijk maken om iets te bouwen dat deze beperkingen schendt.
Dit lijkt niet van toepassing te zijn op de prestaties van webprojecten (en vermoedelijk ook niet op hun ).
Het is vermeldenswaard dat alleen omdat React- of Angular-sites meer CPU-tijd besteden aan het voorbereiden van code dan andere, niet noodzakelijkerwijs betekent dat React-sites meer CPU-intensief zijn dan Vue-sites tijdens het uitvoeren. In feite zeggen de gegevens die we hebben beoordeeld heel weinig over de operationele prestaties van frameworks en bibliotheken. Ze praten meer over de ontwikkelingsbenaderingen die, bewust of onbewust, deze frameworks programmeurs kunnen pushen. We hebben het over documentatie voor frameworks, over hun ecosysteem, over gemeenschappelijke ontwikkelingstechnieken.
Het is ook de moeite waard iets te vermelden dat we hier niet hebben geanalyseerd, namelijk hoeveel tijd het apparaat besteedt aan het uitvoeren van JavaScript-code bij het navigeren tussen pagina's van de site. Het argument voor SPA is dat als de applicatie met één pagina eenmaal in de browser is geladen, de gebruiker in theorie de pagina's van de site sneller kan openen. Mijn eigen ervaring leert me dat dit verre van een feit is. Maar we hebben geen gegevens om dit probleem op te lossen.
Wat duidelijk is, is dat als je een framework of bibliotheek gebruikt om een website te maken, je een compromis sluit wat betreft het in eerste instantie laden van het project en het gebruiksklaar maken ervan. Dit geldt zelfs voor de meest positieve scenario's.
Het is perfect mogelijk om in gepaste situaties compromissen te sluiten, maar het is belangrijk dat ontwikkelaars dergelijke compromissen bewust maken.
Maar we hebben ook reden tot optimisme. Ik ben verheugd om te zien hoe nauw de Chrome-ontwikkelaars samenwerken met de ontwikkelaars van enkele van de front-end-tools die we hebben beoordeeld om de prestaties van die tools te helpen verbeteren.
Ik ben echter een pragmatisch persoon. Nieuwe architecturen creëren net zo vaak prestatieproblemen als ze oplossen. En het kost tijd om bugs op te lossen. Precies zoals we niet mogen verwachten zal alle prestatieproblemen oplossen, dit mag je niet verwachten van nieuwe versies van onze favoriete frameworks.
Als je een van de front-end tools wilt gebruiken die in dit artikel worden besproken, betekent dit dat je extra moeite moet doen om de prestaties van je project in de tussentijd niet te schaden. Hier zijn enkele overwegingen waarmee u rekening moet houden voordat u aan een nieuw raamwerk begint:
- Test jezelf met gezond verstand. Moet u het gekozen raamwerk echt gebruiken? Pure JavaScript is tegenwoordig tot veel in staat.
- Is er een lichter alternatief voor het gekozen raamwerk (zoals Preact, Svelte of iets anders) dat u 90% van de mogelijkheden van dit raamwerk kan bieden?
- Als je al een framework gebruikt, overweeg dan of er iets is dat betere, conservatievere standaardopties biedt (bijv. Nuxt.js in plaats van Vue, Next.js in plaats van React, enzovoort).
- Wat zal jouw JavaScript-prestaties?
- Hoe kun je een ontwikkelingsproces om het moeilijker te maken om meer JavaScript-code in een project te injecteren dan absoluut noodzakelijk is?
- Als u een raamwerk gebruikt voor het gemak van ontwikkeling, overweeg dan raamwerkcode naar klanten sturen. Misschien kun je alle problemen op de server oplossen?
Meestal zijn deze ideeën het bekijken waard, ongeacht wat je precies hebt gekozen voor front-end ontwikkeling. Maar ze zijn vooral belangrijk wanneer u aan een project werkt dat vanaf het begin niet goed presteert.
Beste lezers! Hoe ziet u het ideale JavaScript-framework?
Bron: www.habr.com