Det er ingen raskere måte å redusere hastigheten på et nettsted (ingen ordspill) enn å kjøre en haug med JavaScript-kode på den. Når du bruker JavaScript, må du betale for det i prosjektytelse minst fire ganger. Her er hva nettstedets JavaScript-kode laster brukernes systemer med:
- Laster opp en fil over nettverket.
- Parsing og kompilering av den utpakkede kildekoden etter nedlasting.
- Utfører JavaScript-kode.
- Minneforbruk.
Denne kombinasjonen viser seg å være .
Og vi inkluderer mer og mer JS-kode i prosjektene våre. Ettersom organisasjoner beveger seg mot nettsteder drevet av rammeverk og biblioteker som React, Vue og andre, gjør vi kjernefunksjonaliteten til sidene veldig avhengig av JavaScript.
Jeg har sett mange veldig tunge nettsteder som bruker JavaScript-rammer. Men min visjon om problemet er sterkt partisk. Faktum er at selskapene jeg jobber med kommer til meg nettopp fordi de har komplekse ytelsesproblemer på nettstedet. Som et resultat ble jeg nysgjerrig på å vite hvor utbredt dette problemet er, og hvilke «bøter» vi betaler når vi velger et eller annet rammeverk som grunnlag for et bestemt nettsted.
Dette prosjektet hjalp meg å finne ut av dette. .
Data
HTTP Archive-prosjektet sporer totalt 4308655 5484239 XNUMX lenker til vanlige skrivebordssider og XNUMX XNUMX XNUMX lenker til mobilnettsteder. Blant de mange indikatorene knyttet til disse koblingene er en liste over teknologier som finnes på de tilsvarende nettstedene. Dette betyr at vi kan prøve tusenvis av nettsteder som bruker forskjellige rammeverk og biblioteker og lære hvor mye kode de sender til klienter og hvor mye belastning den koden legger på brukernes systemer.
Jeg samlet inn data fra mars 2020, som var de siste dataene jeg hadde tilgang til.
Jeg bestemte meg for å sammenligne de aggregerte HTTP-arkivdataene for alle nettsteder med data for nettsteder som ble funnet å bruke React, Vue og Angular, selv om jeg vurderte å bruke annet kildemateriale også.
For å gjøre det mer interessant, la jeg også til nettsteder som bruker jQuery til kildedatasettet. Dette biblioteket er fortsatt veldig populært. Den introduserer også en tilnærming til nettstedutvikling som skiller seg fra Single Page Application (SPA)-modellen som tilbys av React, Vue og Angular.
Lenker i HTTP-arkivet som representerer nettsteder som har vist seg å bruke teknologier av interesse for oss
Rammeverk eller bibliotek
Lenker til mobilnettsteder
Lenker til vanlige nettsteder
jQuery
4615474
3714643
Reager
489827
241023
Vue
85649
43691
Vinkel
19423
18088
Håp og drømmer
Før vi går videre til å analysere dataene, vil jeg snakke om hva jeg ønsker å håpe på.
Jeg tror at i en ideell verden vil rammeverk gå utover å møte behovene til utviklere og gi noen konkrete fordeler for de daglige brukerne av nettstedene våre. Produktivitet er bare en av disse fordelene. Tilgjengelighet og sikkerhet kommer også i tankene her. Men dette er bare det viktigste.
Så, i en ideell verden, bør et slags rammeverk gjøre det enklere å lage et nettsted med høy ytelse. Dette bør gjøres enten på grunn av at rammeverket gir utbygger et anstendig grunnlag å bygge et prosjekt på, eller på grunn av at det legger begrensninger på utbyggingen, stiller krav til det som gjør det vanskelig å utvikle noe. som viser seg å gå sakte.
De beste rammene bør gjøre begge deler: gi et godt grunnlag, og legge begrensninger på arbeidet som lar deg oppnå et anstendig resultat.
Å analysere medianverdiene til dataene vil ikke gi oss den informasjonen vi trenger. Og faktisk går denne tilnærmingen utenfor vår oppmerksomhet . I stedet utledet jeg prosentilskår fra dataene jeg hadde. Dette er 10, 25, 50 (median), 75, 90 persentilene.
Jeg er spesielt interessert i 10. og 90. persentil. Den 10. persentilen representerer den beste ytelsen (eller i det minste mer eller mindre nær den beste) for et bestemt rammeverk. Med andre ord betyr dette at bare 10 % av nettstedene som bruker et bestemt rammeverk når dette nivået, eller et høyere nivå. 90. persentilen er derimot den andre siden av medaljen – den viser oss hvor ille ting kan være. Den 90. persentilen er de etterfølgende nettstedene – de siste 10 % av nettstedene som har den største mengden JS-kode eller lengst tid som kreves for å behandle koden deres på hovedtråden.
Volumer av JavaScript-kode
Til å begynne med er det fornuftig å analysere størrelsen på JavaScript-koden som overføres av forskjellige nettsteder over nettverket.
Mengde JavaScript-kode (KB) overført til mobile enheter
Persentiler
10
25
50
75
90
Alle nettsteder
93.4
196.6
413.5
746.8
1201.6
jQuery-nettsteder
110.3
219.8
430.4
748.6
1162.3
Vue nettsteder
244.7
409.3
692.1
1065.5
1570.7
Kantete nettsteder
445.1
675.6
1066.4
1761.5
2893.2
Reager nettsteder
345.8
441.6
690.3
1238.5
1893.6
Mengde JavaScript-kode sendt til mobile enheter
Mengde JavaScript-kode (KB) overført til stasjonære enheter
Persentiler
10
25
50
75
90
Alle nettsteder
105.5
226.6
450.4
808.8
1267.3
jQuery-nettsteder
121.7
242.2
458.3
803.4
1235.3
Vue nettsteder
248.0
420.1
718.0
1122.5
1643.1
Kantete nettsteder
468.8
716.9
1144.2
1930.0
3283.1
Reager nettsteder
308.6
469.0
841.9
1472.2
2197.8
Mengde JavaScript-kode overført til stasjonære enheter
Hvis vi bare snakker om størrelsen på JS-koden som nettsteder sender til enheter, ser alt ut som du kanskje forventer. Nemlig, hvis ett av rammeverkene brukes, betyr dette at selv i en ideell situasjon vil volumet av JavaScript-kode for nettstedet øke. Dette er ikke overraskende - du kan ikke lage et JavaScript-rammeverk til grunnlaget for et nettsted og forvente at mengden JS-kode for prosjektet vil være veldig lav.
Det som er interessant med disse dataene er at noen rammeverk og biblioteker kan anses som bedre utgangspunkt for et prosjekt enn andre. Nettsteder med jQuery ser best ut. Desktop-nettstedene deres inneholder 15 % mer JavaScript enn alle nettsteder, og mobilnettstedene deres inneholder 18 % mer JavaScript. (Det er riktignok noe skjevhet i dataene her. Faktum er at jQuery finnes på mange sider, så det er naturlig at slike sider er nærmere knyttet til det totale antallet nettsteder enn andre. Dette påvirker imidlertid ikke hvordan kildedata sendes ut for hvert rammeverk.)
Mens 15-18% kodevekst er et betydelig tall, sammenlignet med andre rammeverk og biblioteker, er skatten som pålegges av jQuery svært lav. Vinkelnettsteder i den 10. persentilen sender 344 % mer data til stasjonære enheter enn alle nettsteder, og 377 % mer til mobile enheter. React-nettsteder er de nest tyngste, og sender 193 % mer kode til stasjonære enheter enn alle nettsteder, og 270 % mer til mobile enheter.
Jeg nevnte tidligere at selv om bruk av et rammeverk betyr at en viss mengde kode vil bli inkludert i prosjektet helt i begynnelsen av arbeidet med det, håper jeg at rammeverket på en eller annen måte kan begrense utvikleren. Spesielt snakker vi om å begrense maksimal mengde kode.
Det som er interessant er at jQuery-nettsteder følger denne ideen. Selv om de, på 10. persentilnivå, er litt tyngre enn alle nettsteder (med 15-18%), er de, på 90. persentilnivå, litt lettere enn alle nettsteder – med omtrent 3 % i både desktop- og mobilversjoner. Dette er ikke å si at dette er en veldig betydelig fordel, men det kan sies at jQuery-sider i det minste ikke har store JavaScript-kodestørrelser selv i de største versjonene.
Men det samme kan ikke sies om andre rammer.
Akkurat som i tilfellet med den 10. persentilen, skiller stedene på Angular og React seg på 90. persentilen fra andre nettsteder, men de skiller seg dessverre til det verre.
Ved den 90. persentilen sender Angular-nettsteder 141 % mer data til mobile enheter enn alle nettsteder, og 159 % mer til stasjonære enheter. React-nettsteder sender 73 % mer til stasjonære enheter enn alle nettsteder, og 58 % mer til mobile enheter. Kodestørrelsen til React-nettsteder ved den 90. persentilen er 2197.8 KB. Dette betyr at disse nettstedene sender 322.9 KB mer data til mobile enheter enn deres nærmeste Vue-baserte konkurrenter. Gapet mellom skrivebordssider basert på Angular og React og andre nettsteder er enda større. For eksempel sender React-stasjonære nettsteder 554.7 KB mer JS-kode til enheter enn lignende Vue-nettsteder.
Tid det tar å behandle JavaScript-kode på hovedtråden
Dataene ovenfor indikerer tydelig at nettstedene som bruker rammeverket og bibliotekene som er studert, inneholder store mengder JavaScript-kode. Men dette er selvfølgelig bare en del av ligningen vår.
Etter at JavaScript-koden har ankommet nettleseren, må den bringes i fungerende tilstand. Spesielt mange problemer er forårsaket av de handlingene som må utføres med kode i hovednettlesertråden. Hovedtråden er ansvarlig for å behandle brukerhandlinger, kalkulere stiler og bygge og vise sideoppsettet. Hvis du overvelder hovedtråden med JavaScript-oppgaver, vil den ikke ha mulighet til å fullføre andre oppgaver i tide. Dette fører til forsinkelser og "bremser" i driften av sider.
HTTP-arkivdatabasen inneholder informasjon om hvor lang tid det tar å behandle JavaScript-kode på hovedtråden til V8-motoren. Dette betyr at vi kan samle inn disse dataene og lære hvor mye tid hovedtråden tar å behandle JavaScript fra ulike nettsteder.
CPU-tid (i millisekunder) relatert til skriptbehandling på mobile enheter
Persentiler
10
25
50
75
90
Alle nettsteder
356.4
959.7
2372.1
5367.3
10485.8
jQuery-nettsteder
575.3
1147.4
2555.9
5511.0
10349.4
Vue nettsteder
1130.0
2087.9
4100.4
7676.1
12849.4
Kantete nettsteder
1471.3
2380.1
4118.6
7450.8
13296.4
Reager nettsteder
2700.1
5090.3
9287.6
14509.6
20813.3
CPU-tid relatert til skriptbehandling på mobile enheter
CPU-tid (i millisekunder) relatert til skriptbehandling på stasjonære enheter
Persentiler
10
25
50
75
90
Alle nettsteder
146.0
351.8
831.0
1739.8
3236.8
jQuery-nettsteder
199.6
399.2
877.5
1779.9
3215.5
Vue nettsteder
350.4
650.8
1280.7
2388.5
4010.8
Kantete nettsteder
482.2
777.9
1365.5
2400.6
4171.8
Reager nettsteder
508.0
1045.6
2121.1
4235.1
7444.3
CPU-tid relatert til skriptbehandling på stasjonære enheter
Her kan du se noe veldig kjent.
For det første bruker nettsteder med jQuery betydelig mindre på å behandle JavaScript på hovedtråden enn andre. Ved den 10. persentilen, sammenlignet med alle nettsteder, bruker jQuery-nettsteder på mobile enheter 61 % mer tid på å behandle JS-kode på hovedtråden. Når det gjelder desktop jQuery-nettsteder, øker behandlingstiden med 37 %. Ved 90. persentilen er poengsummen til jQuery-nettsteder veldig nær den samlede poengsummen. Nærmere bestemt bruker jQuery-nettsteder på mobile enheter 1.3 % mindre tid i hovedtråden enn alle nettsteder, og på stasjonære enheter bruker de 0.7 % mindre tid i hovedtråden.
På den andre siden av vår vurdering er rammer som er preget av størst belastning på hovedtråden. Dette er igjen Angular og React. Den eneste forskjellen mellom dem er at selv om Angular-nettsteder sender større mengder kode til nettlesere enn React-nettsteder, tar det mindre CPU-tid å behandle koden til Angular-nettsteder. Langt mindre.
Ved den 10. persentilen bruker Angular-stasjonære nettsteder 230 % mer tid på hovedtråden på å behandle JS-kode enn alle nettsteder. For mobilnettsteder er dette tallet 313 %. React-nettsteder har dårligst ytelse. På stasjonære enheter bruker de 248 % mer tid på å behandle kode enn alle nettsteder, og på mobile enheter bruker de 658 % mer tid på å behandle kode. 658 % er ikke en skrivefeil. Ved den 10. persentilen bruker React-nettsteder 2.7 sekunder av hovedtråden på å behandle sin eksisterende kode.
90. persentil-tallene ser i det minste litt bedre ut sammenlignet med disse enorme tallene. Kantede prosjekter, sammenlignet med alle nettsteder, bruker 29 % mer tid i hovedtråden på stasjonære enheter og 27 % mer tid på mobile enheter. Når det gjelder React-nettsteder, ser lignende indikatorer ut som henholdsvis 130 % og 98 %.
Avviksprosentene for den 90. persentilen ser bedre ut enn de tilsvarende verdiene for den 10. persentilen. Men her er det verdt å huske at tallene som indikerer tid virker ganske skumle. La oss si - 20.8 sekunder i hovedtråden til en mobilenhet for et nettsted bygget på React. (Jeg mener at historien om hva som faktisk skjer i løpet av denne tiden er verdig en egen artikkel).
Det er en potensiell komplikasjon her (takk for å trekke min oppmerksomhet til denne funksjonen, og for å nøye undersøke dataene fra dette synspunktet). Faktum er at mange nettsteder bruker flere front-end-verktøy. Spesielt har jeg sett mange nettsteder bruke jQuery sammen med React eller Vue ettersom disse sidene migrerer fra jQuery til andre rammeverk eller biblioteker. Som et resultat gikk jeg tilbake til databasen, denne gangen valgte jeg bare de koblingene som tilsvarte nettsteder som bare brukte React, jQuery, Angular eller Vue, men ikke noen kombinasjon av dem. Her er hva jeg fikk.
Prosessortid (i millisekunder) relatert til skriptbehandling på mobile enheter i situasjoner der nettsteder bruker bare ett rammeverk eller bare ett bibliotek
Persentiler
10
25
50
75
90
Nettsteder som bare bruker jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Nettsteder som kun bruker Vue
944.0
1716.3
3194.7
5959.6
9843.8
Nettsteder som bare bruker Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Nettsteder som kun bruker React
2443.2
4620.5
10061.4
17074.3
24956.3
Prosessortid relatert til behandling av skript på mobile enheter i en situasjon der nettsteder bruker bare ett rammeverk eller bare ett bibliotek
For det første, noe som ikke er overraskende: når et nettsted bare bruker ett rammeverk eller ett bibliotek, forbedres ytelsen til et slikt nettsted oftere enn ikke. Ytelsen for hvert instrument ser bedre ut på 10. og 25. persentil. Det gir mening. Et nettsted som er laget ved hjelp av ett rammeverk, bør være raskere enn et nettsted som er laget med to eller flere rammeverk eller biblioteker.
Faktisk så poengsummene for hvert front-end-verktøy vi undersøkte bedre ut i alle tilfeller, med ett merkelig unntak. Det som overrasket meg var at på 50. persentilen og over, fungerer nettsteder som bruker React dårligere når React er det eneste biblioteket de bruker. Dette var forresten grunnen til at jeg presenterer disse dataene her.
Dette er litt rart, men jeg skal likevel prøve å lete etter en forklaring på denne merkeligheten.
Hvis et prosjekt bruker både React og jQuery, er det prosjektet mest sannsynlig et sted halvveis i prosessen med å migrere fra jQuery til React. Kanskje han har en kodebase der disse bibliotekene er blandet. Siden vi allerede har sett at jQuery-nettsteder bruker mindre tid på hovedtråden enn React-sider, kan dette fortelle oss at implementering av noen funksjonalitet i jQuery bidrar til å forbedre nettstedets ytelse litt.
Men etter hvert som prosjektet går fra jQuery til React og stoler mer og mer på React, endrer situasjonen seg. Hvis siden er laget med virkelig høy kvalitet, og nettstedsutviklerne bruker React nøye, vil alt være bra med en slik side. Men for den gjennomsnittlige React-siden betyr utstrakt bruk av React at hovedtråden blir utsatt for økt belastning.
Gapet mellom mobile og stasjonære enheter
En annen måte jeg så på dataene var å utforske hvor stort gapet er mellom mobil- og skrivebordsopplevelser. Hvis vi snakker om å sammenligne volumene av JavaScript-kode, avslører ikke en slik sammenligning noe forferdelig. Selvfølgelig ville det vært fint å se mindre mengder nedlastbar kode, men det er ikke stor forskjell på mengden mobil- og desktop-kode.
Men hvis du analyserer tiden som kreves for å behandle koden, blir et veldig stort gap mellom mobile og stasjonære enheter merkbar.
Økning i tid (i prosent) relatert til skriptbehandling på mobile enheter sammenlignet med desktop
Persentiler
10
25
50
75
90
Alle nettsteder
144.1
172.8
185.5
208.5
224.0
jQuery-nettsteder
188.2
187.4
191.3
209.6
221.9
Vue nettsteder
222.5
220.8
220.2
221.4
220.4
Kantete nettsteder
205.1
206.0
201.6
210.4
218.7
Reager nettsteder
431.5
386.8
337.9
242.6
179.6
Mens en viss forskjell i kodebehandlingshastighet mellom en telefon og en bærbar PC er å forvente, forteller så store tall meg at moderne rammeverk ikke er rettet nok mot enheter med lav effekt og ønsket om å lukke gapet som er identifisert. Selv på den 10. persentilen bruker React-nettsteder 431.5 % mer tid på mobilens hovedtråd enn på skrivebordets hovedtråd. jQuery har det minste gapet, men også her er det tilsvarende tallet 188.2 %. Når nettstedsutviklere lager prosjektene sine på en slik måte at de krever mer CPU-tid for å behandle dem (og dette er hva som skjer, og det blir bare verre over tid), må eiere av enheter med lav effekt betale for det.
Resultater av
Gode rammeverk bør gi utviklere et godt grunnlag for å bygge nettprosjekter (med tanke på sikkerhet, tilgjengelighet, ytelse), eller bør ha innebygde restriksjoner som gjør det vanskelig å lage noe som bryter med disse begrensningene.
Dette ser ikke ut til å gjelde ytelsen til nettprosjekter (og tilsynelatende deres ).
Det er verdt å merke seg at bare fordi React- eller Angular-nettsteder bruker mer CPU-tid på å forberede kode enn andre, betyr det ikke nødvendigvis at React-nettsteder er mer CPU-intensive enn Vue-nettsteder når de kjører. Dataene vi så på sier faktisk veldig lite om den operasjonelle ytelsen til rammeverk og biblioteker. De snakker mer om utviklingstilnærmingene som, bevisst eller ikke, disse rammeverkene kan presse programmerere mot. Vi snakker om dokumentasjon for rammeverk, deres økosystem og vanlige utviklingsteknikker.
Det er også verdt å nevne noe som vi ikke analyserte her, nemlig hvor mye tid enheten bruker på å kjøre JavaScript-kode ved overgang mellom sidene på nettstedet. Argumentet til fordel for SPA er at når enkeltsideapplikasjonen er lastet inn i nettleseren, vil brukeren i teorien kunne få tilgang til sidens sider raskere. Min egen erfaring sier meg at dette er langt fra et faktum. Men vi har ikke data for å avklare dette problemet.
Det som er klart er at hvis du bruker et rammeverk eller et bibliotek for å lage et nettsted, inngår du et kompromiss når det gjelder innledningsvis å laste prosjektet og gjøre det klart. Dette gjelder selv de mest positive scenariene.
I de riktige situasjonene er det fullt mulig å inngå noen kompromisser, men det er viktig at utviklere gjør slike kompromisser bevisst.
Men vi har også grunn til optimisme. Jeg er oppmuntret over hvor tett Chrome-utviklerne jobber med de som står bak noen av front-end-verktøyene vi har dekket for å forbedre ytelsen til disse verktøyene.
Men jeg er en pragmatisk person. Nye arkitekturer skaper ytelsesproblemer så ofte de løser dem. Og det tar tid å eliminere manglene. Akkurat som vi ikke bør forvente det vil løse alle ytelsesproblemer, bør du ikke forvente dette fra nye versjoner av våre favorittrammeverk.
Hvis du vil bruke et av front-end-verktøyene som er omtalt i dette materialet, betyr dette at du må gjøre ekstra innsats for å sikre at du forresten ikke skader ytelsen til prosjektet ditt. Her er noen hensyn du bør vurdere før du begynner å bruke et nytt rammeverk:
- Sjekk deg selv med sunn fornuft. Trenger du virkelig å bruke ditt valgte rammeverk? Ren JavaScript kan gjøre mye i dag.
- Finnes det et lettere alternativ til rammeverket du velger (som Preact, Svelte eller noe annet) som kan gi deg 90 % av mulighetene til det rammeverket?
- Hvis du allerede bruker et rammeverk, tenk på om det er noe som tilbyr bedre, mer konservative standardalternativer (for eksempel Nuxt.js i stedet for Vue, Next.js i stedet for React, etc.).
- Hva vil din JavaScript ytelse?
- Hvordan kan du utviklingsprosess for å gjøre det vanskeligere å introdusere mer JavaScript-kode i et prosjekt enn det som er absolutt nødvendig?
- Hvis du bruker et rammeverk for enkel utvikling, vurder sende rammekode til klienter. Kanskje du kan løse alle problemene på serveren?
Vanligvis er disse ideene verdt å se nærmere på, uavhengig av hva akkurat du velger for å utvikle frontend. Men de er spesielt viktige når du jobber med et prosjekt som mangler ytelse til å begynne med.
Kjære lesere! Hva ser du på som det ideelle JavaScript-rammeverket?
Kilde: www.habr.com