Det finns inget snabbare sätt att sakta ner en webbplats (ordlek) än att använda en massa JavaScript-kod på den. När du använder JavaScript måste du betala för det med utförandet av projekt inte mindre än fyra gånger. Så här laddar webbplatsens JavaScript-kod in användarnas system:
- Ladda ner en fil över nätverket.
- Parsar och kompilerar uppackad källkod efter nedladdning.
- Utförande av JavaScript-kod.
- Minnesförbrukning.
Denna kombination visar sig .
Och vi inkluderar mer och mer JS-kod i våra projekt. När organisationer går mot webbplatser som drivs av ramverk och bibliotek som React, Vue och andra, gör vi kärnfunktionaliteten för webbplatser mycket beroende av JavaScript.
Jag har sett många mycket tunga webbplatser som använder JavaScript-ramverk. Men min syn på frågan är väldigt partisk. Faktum är att de företag jag jobbar med vänder sig till mig just för att de ställs inför komplexa problem inom området webbplatsprestanda. Det gjorde att jag blev nyfiken på hur vanligt det här problemet är, och på vilken typ av "böter" vi betalar när vi väljer ett eller annat ramverk som grund för en viss sajt.
Projektet hjälpte mig att ta reda på detta. .
Data
HTTP Archive-projektet spårar totalt 4308655 5484239 XNUMX länkar till vanliga datorwebbplatser och XNUMX XNUMX XNUMX länkar till mobilwebbplatser. Bland de många mätvärden som är förknippade med dessa länkar finns en lista över tekniker som finns på respektive webbplats. Det innebär att vi kan ta prov på tusentals sajter som använder olika ramverk och bibliotek och lära oss om hur mycket kod de skickar till kunder och hur mycket belastning denna kod skapar på användarnas system.
Jag samlade in data för mars 2020, vilket var den senaste informationen jag hade tillgång till.
Jag bestämde mig för att jämföra aggregerade HTTP-arkivdata över alla webbplatser med data från webbplatser som hittats med React, Vue och Angular, även om jag övervägde att använda annat källmaterial också.
För att göra det mer intressant lade jag också till webbplatser som använder jQuery till källdatauppsättningen. Detta bibliotek är fortfarande mycket populärt. Den introducerar också ett annat tillvägagångssätt för webbutveckling än Single Page Application (SPA)-modellen som erbjuds av React, Vue och Angular.
Länkar i HTTP-arkivet som representerar webbplatser som har visat sig använda teknik av intresse
Ram eller bibliotek
Länkar till mobilsajter
Länkar till vanliga sajter
jQuery
4615474
3714643
Reagera
489827
241023
Vue
85649
43691
Vinkel
19423
18088
Hopp och drömmar
Innan vi går vidare till dataanalys vill jag prata om vad jag skulle vilja hoppas på.
Jag tror att i en idealisk värld bör ramverk sträcka sig längre än att möta utvecklarnas behov och ge en viss fördel för den genomsnittliga användaren som arbetar med våra webbplatser. Prestanda är bara en av dessa fördelar. Det är här tillgänglighet och säkerhet spelar in. Men detta är bara det viktigaste.
Så i en idealisk värld borde någon form av ramverk göra det enkelt att skapa en högpresterande webbplats. Detta bör göras antingen på grund av att ramverket ger byggherren en anständig bas att bygga ett projekt på, eller på grund av att det sätter begränsningar för utvecklingen, ställer krav på det som försvårar utvecklingen av något som vänder ut att vara långsam.
De bästa ramarna bör göra både och: ge en bra bas och införa begränsningar för arbetet, så att du kan uppnå ett anständigt resultat.
Att analysera medianvärdena för datan kommer inte att ge oss den information vi behöver. Och i själva verket lämnar detta tillvägagångssätt ur vår uppmärksamhet . Istället härledde jag procentsatser från den data jag hade. Dessa är 10, 25, 50 (median), 75, 90 percentiler.
Jag är särskilt intresserad av 10:e och 90:e percentilen. Den 10:e percentilen representerar det allra bästa resultatet (eller åtminstone mer eller mindre nära det bästa) för ett visst ramverk. Med andra ord betyder det att endast 10 % av webbplatserna som använder ett visst ramverk når den här nivån eller högre. Den 90:e percentilen, å andra sidan, är den andra sidan av myntet – den visar oss hur illa det kan gå. Den 90:e percentilen är webbplatserna som ligger efter – de lägsta 10 % av webbplatserna som har mest JS-kod eller längst tid att bearbeta sin kod i huvudtråden.
Volymer av JavaScript-kod
Till att börja med är det vettigt att analysera storleken på JavaScript-koden som överförs av olika webbplatser över nätverket.
Mängden JavaScript-kod (Kb) som överförs till mobila enheter
Percentiler
10
25
50
75
90
Alla sajter
93.4
196.6
413.5
746.8
1201.6
jQuery-webbplatser
110.3
219.8
430.4
748.6
1162.3
Vue webbplatser
244.7
409.3
692.1
1065.5
1570.7
Kantiga platser
445.1
675.6
1066.4
1761.5
2893.2
Reagera webbplatser
345.8
441.6
690.3
1238.5
1893.6
Mängden JavaScript-kod som skickas till mobila enheter
Mängden JavaScript-kod (Kb) överförd till stationära enheter
Percentiler
10
25
50
75
90
Alla sajter
105.5
226.6
450.4
808.8
1267.3
jQuery-webbplatser
121.7
242.2
458.3
803.4
1235.3
Vue webbplatser
248.0
420.1
718.0
1122.5
1643.1
Kantiga platser
468.8
716.9
1144.2
1930.0
3283.1
Reagera webbplatser
308.6
469.0
841.9
1472.2
2197.8
Mängden JavaScript-kod som skickas till stationära enheter
Om vi bara pratar om storleken på JS-koden som sajter skickar till enheter, så ser allt ut ungefär som du kan förvänta dig. Om något av ramverken används innebär det nämligen att även i en ideal situation kommer volymen på sajtens JavaScript-kod att öka. Detta är inte förvånande – du kan inte göra ett JavaScript-ramverk till grunden för en webbplats och förvänta dig att volymen på projektets JS-kod kommer att vara mycket låg.
Det som är anmärkningsvärt med denna data är att vissa ramverk och bibliotek kan anses vara en bättre utgångspunkt för ett projekt än andra. Webbplatser med jQuery ser bäst ut. På stationära versioner av webbplatser innehåller de 15 % mer JavaScript än alla webbplatser, och på mobila enheter innehåller de 18 % mer. (Det finns visserligen en viss datakorruption här. Faktum är att jQuery finns på många sajter, så det är bara naturligt att sådana sajter är mer förknippade än andra med det totala antalet sajter. Detta påverkar dock inte hur rått data matas ut för varje ramverk.)
Medan ökningen på 15-18% i kodvolym är en anmärkningsvärd siffra, kan man jämföra detta med andra ramverk och bibliotek, dra slutsatsen att "skatten" som tas ut av jQuery är mycket låg. Vinklade webbplatser i den 10:e percentilen skickar 344 % mer data till datorer än alla webbplatser och 377 % mer till mobila enheter. React-webbplatser är de näst tyngsta och skickar 193 % mer kod till datorer än alla webbplatser och 270 % mer till mobila enheter.
Tidigare nämnde jag att även om användningen av ett ramverk innebär att en viss mängd kod kommer att ingå i projektet, hoppas jag i början av arbetet med det att ramverket på något sätt kan begränsa utvecklaren. I synnerhet talar vi om att begränsa den maximala mängden kod.
Intressant nog följer jQuery-webbplatser denna idé. Även om de är något tyngre än alla webbplatser vid den 10:e percentilen (med 15-18 %), är de något lättare vid den 90:e percentilen med cirka 3 % på både datorer och mobiler. Detta är inte att säga att detta är en mycket betydande fördel, men det kan sägas att jQuery-sajter åtminstone inte har enorma JavaScript-kodstorlekar, inte ens i sina största versioner.
Men detsamma kan inte sägas om andra ramverk.
Precis som i fallet med den 10:e percentilen, vid den 90:e percentilen skiljer sig platserna på Angular och React från andra sajter, men de skiljer sig tyvärr till det sämre.
Vid den 90:e percentilen skickar Angular-webbplatser 141 % mer data till mobila enheter än alla webbplatser och 159 % mer till datorer. React-webbplatser skickar 73 % mer till datorer än alla webbplatser och 58 % mer till mobila enheter. Kodstorleken för React-sajter vid den 90:e percentilen är 2197.8 KB. Detta innebär att sådana sajter skickar 322.9 KB mer data till mobila enheter än deras närmaste konkurrenter baserat på Vue. Gapet mellan stationära sajter baserade på Angular och React och andra sajter är ännu större. Till exempel, stationära React-webbplatser skickar 554.7 KB mer JS-kod till enheter än motsvarande Vue-sajter.
Det tar tid att bearbeta JavaScript-koden i huvudtråden
Ovanstående data indikerar tydligt att webbplatser som använder ramarna och biblioteken som studeras innehåller stora mängder JavaScript-kod. Men det är naturligtvis bara en del av vår ekvation.
Efter att JavaScript-koden har anlänt till webbläsaren måste den föras till ett fungerande tillstånd. Särskilt många problem orsakas av de åtgärder som måste utföras med koden i huvudwebbläsarens tråd. Huvudtråden är ansvarig för att bearbeta användaråtgärder, för att beräkna stilar, för att bygga och visa sidlayouten. Om du översköljer huvudtråden med JavaScript-uppgifter kommer den inte att ha möjlighet att slutföra resten av uppgifterna i tid. Detta leder till förseningar och "bromsar" i sidornas arbete.
HTTP Archive-databasen har information om hur lång tid det tar att bearbeta JavaScript-kod i V8-motorns huvudtråd. Detta innebär att vi kan samla in denna data och ta reda på hur lång tid huvudtråden tar att bearbeta JavaScript från olika webbplatser.
Processortid (i millisekunder) relaterad till skriptbehandling på mobila enheter
Percentiler
10
25
50
75
90
Alla sajter
356.4
959.7
2372.1
5367.3
10485.8
jQuery-webbplatser
575.3
1147.4
2555.9
5511.0
10349.4
Vue webbplatser
1130.0
2087.9
4100.4
7676.1
12849.4
Kantiga platser
1471.3
2380.1
4118.6
7450.8
13296.4
Reagera webbplatser
2700.1
5090.3
9287.6
14509.6
20813.3
Processortid relaterad till skriptbehandling på mobila enheter
Processortid (i millisekunder) relaterad till skriptbehandling på stationära enheter
Percentiler
10
25
50
75
90
Alla sajter
146.0
351.8
831.0
1739.8
3236.8
jQuery-webbplatser
199.6
399.2
877.5
1779.9
3215.5
Vue webbplatser
350.4
650.8
1280.7
2388.5
4010.8
Kantiga platser
482.2
777.9
1365.5
2400.6
4171.8
Reagera webbplatser
508.0
1045.6
2121.1
4235.1
7444.3
Processortid relaterad till skriptbehandling på stationära enheter
Här kan du se något mycket välbekant.
Till att börja med spenderar webbplatser med jQuery betydligt mindre på JavaScript-bearbetning på huvudtråden än andra webbplatser. Vid den 10:e percentilen, jämfört med alla webbplatser, spenderar jQuery-webbplatser på mobil 61 % mer tid på att bearbeta JS-kod på huvudtråden. När det gäller stationära jQuery-webbplatser ökar bearbetningstiden med 37 %. Vid den 90:e percentilen får jQuery-webbplatserna mycket nära de sammanlagda poängen. Specifikt spenderar jQuery-webbplatser på mobila enheter 1.3 % mindre tid på huvudtråden än alla webbplatser och 0.7 % mindre tid på stationära enheter.
På andra sidan av vårt betyg finns de ramverk som kännetecknas av den högsta belastningen på huvudtråden. Det här är återigen Angular och React. Den enda skillnaden mellan de två är att medan Angular-webbplatser skickar mer kod till webbläsare än React-webbplatser, tar Angular-webbplatser mindre CPU-tid att bearbeta kod. Mycket mindre.
Vid den 10:e percentilen spenderar Angular-webbplatser för stationära datorer 230 % mer tid på huvudtråden för att bearbeta JS-kod än alla webbplatser. För mobilsajter är denna siffra 313 %. React-sajter är de sämst presterande. På datorer spenderar de 248 % mer tid på att bearbeta kod än alla webbplatser och 658 % mer på mobilen. 658% är inget stavfel. Vid den 10:e percentilen tillbringar React-sajter 2.7 sekunders huvudtrådstid på att bearbeta sin kod.
Den 90:e percentilen, jämfört med dessa enorma siffror, ser åtminstone lite bättre ut. Jämfört med alla webbplatser spenderar Angular-projekt 29 % mer tid på stationära enheter i huvudtråden och 27 % mer tid på mobila enheter. När det gäller React-sajter ser samma siffror ut som 130% respektive 98%.
Procentuella avvikelser för den 90:e percentilen ser bättre ut än liknande värden för den 10:e percentilen. Men här är det värt att komma ihåg att siffrorna som anger tiden verkar ganska skrämmande. Låt oss säga 20.8 sekunder på den huvudsakliga mobiltråden för en webbplats byggd med React. (Jag tycker att historien om vad som faktiskt händer under den här tiden är värd en separat artikel).
Det finns en potentiell komplikation här (tack för att jag uppmärksammat detta särdrag och noggrant övervägt uppgifterna ur denna synvinkel). Faktum är att många webbplatser använder flera front-end-verktyg. I synnerhet har jag sett många sajter som använder jQuery tillsammans med React eller Vue, eftersom dessa sajter migrerar från jQuery till andra ramverk eller bibliotek. Som ett resultat slog jag databasen igen, den här gången valde jag bara de länkar som motsvarar webbplatser som bara använder React, jQuery, Angular eller Vue, men inte någon kombination av dem. Här är vad jag fick.
Processortid (i millisekunder) relaterad till bearbetning av skript på mobila enheter i en situation där webbplatser bara använder ett ramverk eller bara ett bibliotek
Percentiler
10
25
50
75
90
Webbplatser som bara använder jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Webbplatser som endast använder Vue
944.0
1716.3
3194.7
5959.6
9843.8
Webbplatser som endast använder Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Webbplatser som endast använder React
2443.2
4620.5
10061.4
17074.3
24956.3
Processortid relaterad till bearbetning av skript på mobila enheter i en situation där webbplatser bara använder ett ramverk eller bara ett bibliotek
För det första, något som inte är förvånande: när en webbplats bara använder ett ramverk eller ett bibliotek, förbättras prestandan för en sådan webbplats oftare än inte. Varje instrument presterar bättre vid 10:e och 25:e percentilen. Det är vettigt. En webbplats som är gjord med ett ramverk bör prestera bättre än en webbplats som är gjord med två eller flera ramverk eller bibliotek.
I själva verket ser prestandan för varje studerat front-end-verktyg bättre ut i alla fall, med undantag för ett konstigt undantag. Det som förvånade mig var att på den 50:e percentilen och däröver presterar webbplatser som använder React sämre när React är det enda biblioteket de använder. Detta var förresten anledningen till att jag presenterar denna data här.
Det här är lite konstigt, men jag ska ändå försöka leta efter en förklaring till denna konstighet.
Om ett projekt använder både React och jQuery, är det projektet troligen någonstans halvvägs genom övergången från jQuery till React. Kanske har den en kodbas där dessa bibliotek är blandade. Eftersom vi redan har sett att jQuery-sajter spenderar mindre tid på huvudtråden än React-sajter, kan detta berätta för oss att implementering av viss funktionalitet i jQuery hjälper sajten att prestera lite bättre.
Men när projektet övergår från jQuery till React och förlitar sig mer på React, förändras saker och ting. Om sajten håller riktigt hög kvalitet, och sajtutvecklarna använder React noggrant, så kommer allt att bli bra med en sådan sida. Men för den genomsnittliga React-sajten innebär omfattande användning av React att huvudtråden är hårt belastad.
Gapet mellan mobila och stationära enheter
En annan synvinkel från vilken jag tittade på den undersökta datan var att studera hur stor klyftan är mellan att arbeta med sajter på mobila och stationära enheter. Om vi pratar om att jämföra volymerna av JavaScript-kod, så avslöjar inte en sådan jämförelse något hemskt. Visst skulle det vara trevligt att se mindre mängder nedladdningsbar kod, men det är inte så stor skillnad i mängden mobil- och datorkod.
Men om vi analyserar tiden som krävs för att bearbeta koden blir ett mycket stort gap mellan mobila och stationära enheter märkbar.
Ökning av tid (procent) relaterad till bearbetning av skript på mobila enheter jämfört med stationära datorer
Percentiler
10
25
50
75
90
Alla sajter
144.1
172.8
185.5
208.5
224.0
jQuery-webbplatser
188.2
187.4
191.3
209.6
221.9
Vue webbplatser
222.5
220.8
220.2
221.4
220.4
Kantiga platser
205.1
206.0
201.6
210.4
218.7
Reagera webbplatser
431.5
386.8
337.9
242.6
179.6
Även om en viss skillnad i kodbehandlingshastighet mellan en telefon och en bärbar dator kan förväntas, säger så stora siffror för mig att moderna ramverk inte är tillräckligt inriktade på enheter med låg effekt, och att de strävar efter att överbrygga det gap de har upptäckt. Även vid den 10:e percentilen spenderar React-sajter 431.5 % mer tid på den mobila huvudtråden än på den stationära huvudtråden. jQuery har det minsta gapet, men även här är motsvarande siffra 188.2%. När webbplatsutvecklare gör sina projekt på ett sådant sätt att deras bearbetning kräver mer processortid (och det händer, och det blir bara värre med tiden), måste ägare av lågeffektsenheter betala för det.
Resultat av
Bra ramverk bör ge utvecklare en bra grund för att bygga webbprojekt (när det gäller säkerhet, tillgänglighet, prestanda), eller så bör de ha inbyggda begränsningar som gör det svårt att bygga något som bryter mot dessa begränsningar.
Detta verkar inte gälla prestanda för webbprojekt (och förmodligen inte för deras ).
Det är värt att notera att bara för att React- eller Angular-sajter spenderar mer CPU-tid på att förbereda kod än andra betyder det inte nödvändigtvis att React-sajter är mer CPU-intensiva än Vue-sajter när de körs. Faktum är att de data vi har granskat säger väldigt lite om den operativa prestandan för ramverk och bibliotek. De pratar mer om de utvecklingsmetoder som, medvetet eller inte, dessa ramverk kan pusha programmerare. Vi pratar om dokumentation för ramverk, om deras ekosystem, om vanliga utvecklingstekniker.
Det är också värt att nämna något som vi inte analyserade här, nämligen hur mycket tid enheten lägger på att exekvera JavaScript-kod när den navigerar mellan sidorna på sajten. Argumentet för SPA är att när ensidesapplikationen väl har laddats in i webbläsaren kommer användaren teoretiskt sett att kunna öppna sidorna på sajten snabbare. Min egen erfarenhet säger mig att detta är långt ifrån ett faktum. Men vi har inga uppgifter för att klargöra denna fråga.
Vad som är tydligt är att om du använder ett ramverk eller ett bibliotek för att skapa en webbplats, gör du en kompromiss när det gäller att initialt ladda projektet och göra det klart. Detta gäller även för de mest positiva scenarierna.
Det är fullt möjligt att göra vissa kompromisser i lämpliga situationer, men det är viktigt att utvecklare gör sådana kompromisser medvetet.
Men vi har också anledning till optimism. Jag är spännande att se hur nära Chrome-utvecklarna arbetar med utvecklarna av några av de frontend-verktyg som vi har granskat i ett försök att hjälpa till att förbättra prestandan för dessa verktyg.
Däremot är jag en pragmatisk person. Nya arkitekturer skapar prestandaproblem så ofta som de löser dem. Och det tar tid att fixa buggar. Precis som vi inte borde förvänta oss kommer att lösa alla prestandaproblem, bör du inte förvänta dig detta från nya versioner av våra favoritramverk.
Om du vill använda ett av de front-end-verktyg som diskuteras i den här artikeln, betyder det att du måste lägga extra kraft på att inte skada prestandan för ditt projekt under tiden. Här är några överväganden att tänka på innan du startar ett nytt ramverk:
- Testa dig själv med sunt förnuft. Behöver du verkligen använda det valda ramverket? Ren JavaScript idag klarar mycket.
- Finns det ett lättare alternativ till det valda ramverket (som Preact, Svelte eller något annat) som kan ge dig 90 % av kapaciteten i detta ramverk?
- Om du redan använder ett ramverk, fundera på om det finns något som erbjuder bättre, mer konservativa standardalternativ (t.ex. Nuxt.js istället för Vue, Next.js istället för React, och så vidare).
- Vad kommer din JavaScript prestanda?
- Hur kan du en utvecklingsprocess för att göra det svårare att injicera mer JavaScript-kod i ett projekt än vad som är absolut nödvändigt?
- Om du använder ett ramverk för enkel utveckling, överväg skicka ramkod till kunder. Kanske kan du lösa alla problem på servern?
Vanligtvis är dessa idéer värda att titta på, oavsett vad exakt du har valt för frontend-utveckling. Men de är särskilt viktiga när du arbetar med ett projekt som saknar prestanda redan från början.
Kära läsare! Hur ser du på det perfekta JavaScript-ramverket?
Källa: will.com