Der er ingen hurtigere måde at sænke et websted (pun intended) på end at bruge en masse JavaScript-kode på det. Når du bruger JavaScript, skal du betale for det med udførelsen af projekter ikke mindre end fire gange. Her er, hvordan webstedets JavaScript-kode indlæser brugernes systemer:
- Download af en fil over netværket.
- Parsing og kompilering af udpakket kildekode efter download.
- Udførelse af JavaScript-kode.
- Hukommelsesforbrug.
Denne kombination viser sig .
Og vi inkluderer mere og mere JS-kode i vores projekter. Efterhånden som organisationer bevæger sig mod websteder drevet af rammer og biblioteker som React, Vue og andre, gør vi kernefunktionaliteten af websteder meget afhængig af JavaScript.
Jeg har set mange meget tunge websteder, der bruger JavaScript-rammer. Men min vision af spørgsmålet er meget forudindtaget. Faktum er, at de virksomheder, jeg arbejder med, henvender sig til mig, netop fordi de står med komplekse problemer inden for site performance. Det resulterede i, at jeg blev nysgerrig på, hvor almindeligt dette problem er, og på hvilken slags "bøder" vi betaler, når vi vælger et eller andet framework som grundlag for en bestemt side.
Projektet hjalp mig med at finde ud af dette. .
Data
HTTP Archive-projektet sporer i alt 4308655 links til almindelige desktop-websteder og 5484239 links til mobilwebsteder. Blandt de mange målinger forbundet med disse links er en liste over teknologier, der findes på de respektive websteder. Det betyder, at vi kan prøve tusindvis af websteder, der bruger forskellige rammer og biblioteker, og lære om, hvor meget kode de sender til klienter, og hvor meget belastning denne kode skaber på brugernes systemer.
Jeg indsamlede data fra marts 2020, som var de seneste data, jeg havde adgang til.
Jeg besluttede at sammenligne aggregerede HTTP-arkivdata på tværs af alle websteder med data fra websteder fundet ved hjælp af React, Vue og Angular, selvom jeg også overvejede at bruge andet kildemateriale.
For at gøre det mere interessant tilføjede jeg også websteder, der bruger jQuery, til kildedatasættet. Dette bibliotek er stadig meget populært. Den introducerer også en anden tilgang til webudvikling end Single Page Application (SPA)-modellen, der tilbydes af React, Vue og Angular.
Links i HTTP-arkivet, der repræsenterer websteder, der har vist sig at bruge teknologier af interesse
Ramme eller bibliotek
Links til mobilwebsteder
Links til almindelige websteder
jQuery
4615474
3714643
Reagerer
489827
241023
Vue
85649
43691
Vinkelforskydning
19423
18088
Håb og drømme
Inden vi går videre til dataanalyse, vil jeg tale om, hvad jeg gerne vil håbe på.
Jeg tror på, at rammerne i en ideel verden bør gå ud over at opfylde udviklernes behov og give nogle specifikke fordele for den gennemsnitlige bruger, der arbejder med vores websteder. Ydeevne er blot en af disse fordele. Det er her tilgængelighed og sikkerhed spiller ind. Men dette er kun det vigtigste.
Så i en ideel verden burde en eller anden form for ramme gøre det nemt at skabe et højtydende websted. Dette bør enten ske på grund af, at rammeværket giver bygherren et anstændigt grundlag at bygge et projekt på, eller fordi det sætter begrænsninger for udviklingen, stiller krav til det, der komplicerer udviklingen af noget, der vender. ude at være langsom.
De bedste rammer bør gøre begge dele: give et godt grundlag og pålægge begrænsninger for arbejdet, så du kan opnå et anstændigt resultat.
At analysere medianværdierne af dataene vil ikke give os den information, vi har brug for. Og faktisk udelader denne tilgang vores opmærksomhed . I stedet udledte jeg procenter fra de data, jeg havde. Disse er 10, 25, 50 (median), 75, 90 percentiler.
Jeg er især interesseret i 10. og 90. percentilen. Den 10. percentil repræsenterer den allerbedste præstation (eller i det mindste mere eller mindre tæt på den bedste) for en bestemt ramme. Med andre ord betyder det, at kun 10 % af websteder, der bruger en bestemt ramme, når dette niveau eller højere. 90. percentilen er på den anden side den anden side af medaljen – den viser os, hvor galt det kan gå. Den 90. percentil er de websteder, der er bagud - de nederste 10 % af webstederne, der har mest JS-kode eller længst tid til at behandle deres kode på hovedtråden.
Mængder af JavaScript-kode
Til at begynde med giver det mening at analysere størrelsen af JavaScript-koden, der transmitteres af forskellige websteder over netværket.
Mængden af JavaScript-kode (Kb), der overføres til mobile enheder
Percentiler
10
25
50
75
90
Alle websteder
93.4
196.6
413.5
746.8
1201.6
jQuery websteder
110.3
219.8
430.4
748.6
1162.3
Vue websteder
244.7
409.3
692.1
1065.5
1570.7
Vinkelpladser
445.1
675.6
1066.4
1761.5
2893.2
Reager websteder
345.8
441.6
690.3
1238.5
1893.6
Mængden af JavaScript-kode sendt til mobile enheder
Mængden af JavaScript-kode (Kb) overført til desktop-enheder
Percentiler
10
25
50
75
90
Alle websteder
105.5
226.6
450.4
808.8
1267.3
jQuery websteder
121.7
242.2
458.3
803.4
1235.3
Vue websteder
248.0
420.1
718.0
1122.5
1643.1
Vinkelpladser
468.8
716.9
1144.2
1930.0
3283.1
Reager websteder
308.6
469.0
841.9
1472.2
2197.8
Mængden af JavaScript-kode sendt til stationære enheder
Hvis vi kun taler om størrelsen af den JS-kode, som websteder sender til enheder, så ser alt ud, som du kunne forvente. Hvis et af rammerne bruges, betyder det nemlig, at selv i en ideel situation vil volumen af sidens JavaScript-kode stige. Dette er ikke overraskende – du kan ikke lave en JavaScript-ramme til grundlaget for et websted og forvente, at volumen af projektets JS-kode vil være meget lav.
Det bemærkelsesværdige ved disse data er, at nogle rammer og biblioteker kan betragtes som et bedre udgangspunkt for et projekt end andre. Websteder med jQuery ser bedst ud. På desktopversioner af websteder indeholder de 15 % mere JavaScript end alle websteder, og på mobil indeholder de 18 % mere. (Ganske vist er der noget datakorruption her. Faktum er, at jQuery er til stede på mange sider, så det er helt naturligt, at sådanne sider er tættere forbundet end andre med det samlede antal sider. Dette påvirker dog ikke, hvor råt data er output for hver ramme.)
Mens stigningen på 15-18% i kodevolumen er et bemærkelsesværdigt tal, sammenligner man dette med andre rammer og biblioteker, kan man konkludere, at "skatten" pålagt af jQuery er meget lav. Vinkelwebsteder i 10. percentil sender 344 % flere data til desktop end alle websteder og 377 % mere til mobil. React-websteder er de næsttungeste og sender 193 % mere kode til desktop end alle websteder og 270 % mere til mobil.
Tidligere nævnte jeg, at selvom brugen af et framework betyder, at en vis mængde kode vil blive inkluderet i projektet, håber jeg helt i begyndelsen af arbejdet med det, at frameworket på en eller anden måde er i stand til at begrænse udvikleren. Vi taler især om at begrænse den maksimale mængde kode.
Interessant nok følger jQuery-websteder denne idé. Selvom de er lidt tungere end alle websteder ved den 10. percentil (med 15-18 %), er de lidt lettere ved 90. percentilen med omkring 3 % på både desktop og mobil. Dette er ikke at sige, at dette er en meget væsentlig fordel, men det kan siges, at jQuery-websteder i det mindste ikke har store JavaScript-kodestørrelser, selv i deres største versioner.
Men det samme kan ikke siges om andre rammer.
Ligesom i tilfældet med 10. percentilen adskiller stederne på Angular og React sig på 90. percentilen fra andre steder, men de adskiller sig desværre til det værre.
Ved 90. percentilen sender Angular-websteder 141 % flere data til mobilenheder end alle websteder og 159 % mere til computere. React-websteder sender 73 % mere til desktop end alle websteder og 58 % mere til mobil. Kodestørrelsen for React-steder ved den 90. percentil er 2197.8 KB. Det betyder, at sådanne websteder sender 322.9 KB flere data til mobile enheder end deres nærmeste konkurrenter baseret på Vue. Kløften mellem desktop-websteder baseret på Angular og React og andre websteder er endnu større. For eksempel sender desktop React-websteder 554.7 KB mere JS-kode til enheder end tilsvarende Vue-websteder.
Det tager tid at behandle JavaScript-kode i hovedtråden
Ovenstående data indikerer tydeligt, at websteder, der bruger de undersøgte rammer og biblioteker, indeholder store mængder JavaScript-kode. Men det er selvfølgelig kun en del af vores ligning.
Når JavaScript-koden er ankommet til browseren, skal den bringes i en brugbar tilstand. Især mange problemer er forårsaget af de handlinger, der skal udføres med koden i hovedbrowsertråden. Hovedtråden er ansvarlig for at behandle brugerhandlinger, for at beregne stilarter, for at opbygge og vise sidelayoutet. Hvis du overvælder hovedtråden med JavaScript-opgaver, vil den ikke have mulighed for at færdiggøre resten af opgaverne i tide. Dette fører til forsinkelser og "bremser" i arbejdet med siderne.
HTTP-arkivdatabasen har information om, hvor lang tid det tager at behandle JavaScript-kode i hovedtråden i V8-motoren. Det betyder, at vi kan indsamle disse data og finde ud af, hvor lang tid hovedtråden tager at behandle JavaScript fra forskellige websteder.
Processortid (i millisekunder) relateret til scriptbehandling på mobile enheder
Percentiler
10
25
50
75
90
Alle websteder
356.4
959.7
2372.1
5367.3
10485.8
jQuery websteder
575.3
1147.4
2555.9
5511.0
10349.4
Vue websteder
1130.0
2087.9
4100.4
7676.1
12849.4
Vinkelpladser
1471.3
2380.1
4118.6
7450.8
13296.4
Reager websteder
2700.1
5090.3
9287.6
14509.6
20813.3
Processortid relateret til scriptbehandling på mobile enheder
CPU-tid (i millisekunder) relateret til scriptbehandling på stationære enheder
Percentiler
10
25
50
75
90
Alle websteder
146.0
351.8
831.0
1739.8
3236.8
jQuery websteder
199.6
399.2
877.5
1779.9
3215.5
Vue websteder
350.4
650.8
1280.7
2388.5
4010.8
Vinkelpladser
482.2
777.9
1365.5
2400.6
4171.8
Reager websteder
508.0
1045.6
2121.1
4235.1
7444.3
Processortid relateret til scriptbehandling på stationære enheder
Her kan du se noget meget velkendt.
For det første bruger websteder med jQuery betydeligt mindre på JavaScript-behandling på hovedtråden end andre websteder. Ved den 10. percentil, sammenlignet med alle websteder, bruger jQuery-websteder på mobil 61 % mere tid på at behandle JS-kode på hovedtråden. I tilfælde af desktop jQuery-websteder øges behandlingstiden med 37 %. Ved 90. percentilen scorer jQuery-websteder meget tæt på de samlede scores. Specifikt bruger jQuery-websteder på mobile enheder 1.3 % mindre tid på hovedtråden end alle websteder og 0.7 % mindre tid på desktop-enheder.
På den anden side af vores vurdering er de rammer, der er kendetegnet ved den højeste belastning på hovedtråden. Dette er igen Angular og React. Den eneste forskel mellem de to er, at mens Angular-websteder sender mere kode til browsere end React-websteder, tager Angular-websteder mindre CPU-tid at behandle kode. Langt mindre.
Ved den 10. percentil bruger Angular-computerwebsteder 230 % mere tid på hovedtråden på at behandle JS-kode end alle websteder. For mobilsites er dette tal 313 %. React-sites klarer sig dårligst. På computer bruger de 248 % mere tid på at behandle kode end alle websteder og 658 % mere på mobilenheder. 658% er ikke en tastefejl. Ved den 10. percentil bruger React-websteder 2.7 sekunders hovedtrådstid på at behandle deres kode.
Den 90. percentil, sammenlignet med disse enorme tal, ser i det mindste lidt bedre ud. Sammenlignet med alle websteder bruger Angular-projekter 29 % mere tid på stationære enheder i hovedtråden og 27 % mere tid på mobile enheder. I tilfælde af React-sites ser de samme tal ud på henholdsvis 130 % og 98 %.
Procentvise afvigelser for den 90. percentil ser bedre ud end tilsvarende værdier for den 10. percentil. Men her er det værd at huske på, at tallene, der angiver tidspunktet, virker ret skræmmende. Lad os sige 20.8 sekunder på hovedmobiltråden for en hjemmeside bygget med React. (Jeg synes, at historien om, hvad der faktisk sker i løbet af denne tid, er værdig til en separat artikel).
Der er en potentiel komplikation her (tak for at henlede min opmærksomhed på dette træk og for nøje at overveje dataene fra dette synspunkt). Faktum er, at mange websteder bruger flere frontend-værktøjer. Især har jeg set mange websteder, der bruger jQuery sammen med React eller Vue, da disse websteder migrerer fra jQuery til andre rammer eller biblioteker. Som et resultat ramte jeg databasen igen, denne gang valgte jeg kun de links, der svarer til websteder, der kun bruger React, jQuery, Angular eller Vue, men ikke nogen kombination af dem. Her er hvad jeg fik.
Processortid (i millisekunder) relateret til behandling af scripts på mobile enheder i en situation, hvor websteder kun bruger én ramme eller kun ét bibliotek
Percentiler
10
25
50
75
90
Websteder, der kun bruger jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Websteder, der kun bruger Vue
944.0
1716.3
3194.7
5959.6
9843.8
Websteder, der kun bruger Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Websteder, der kun bruger React
2443.2
4620.5
10061.4
17074.3
24956.3
Processortid relateret til behandling af scripts på mobile enheder i en situation, hvor websteder kun bruger én ramme eller kun ét bibliotek
For det første noget, der ikke er overraskende: Når et websted kun bruger én ramme eller ét bibliotek, forbedres ydeevnen af et sådant websted oftere end ikke. Hvert instrument klarer sig bedre ved 10. og 25. percentil. Det giver mening. Et websted, der er lavet ved hjælp af en ramme, bør yde bedre end et websted, der er lavet ved hjælp af to eller flere rammer eller biblioteker.
Faktisk ser ydeevnen af hvert undersøgt front-end-værktøj bedre ud i alle tilfælde, bortset fra en mærkelig undtagelse. Det, der overraskede mig, var, at på 50. percentilen og derover klarer websteder, der bruger React, sig dårligere, når React er det eneste bibliotek, de bruger. Dette var i øvrigt grunden til, at jeg præsenterer disse data her.
Det er lidt mærkeligt, men jeg vil alligevel forsøge at lede efter en forklaring på denne mærkelighed.
Hvis et projekt bruger både React og jQuery, så er det projekt sandsynligvis et sted halvvejs i overgangen fra jQuery til React. Måske har den en kodebase, hvor disse biblioteker er blandet. Da vi allerede har set, at jQuery-websteder bruger mindre tid på hovedtråden end React-websteder, kan dette fortælle os, at implementering af nogle funktioner i jQuery hjælper webstedet med at præstere en smule bedre.
Men efterhånden som projektet går fra jQuery til React og stoler mere på React, ændrer tingene sig. Hvis siden er af virkelig høj kvalitet, og sideudviklerne bruger React omhyggeligt, så vil alt være fint med sådan en side. Men for den gennemsnitlige React-side betyder omfattende brug af React, at hovedtråden er under hård belastning.
Gabet mellem mobile og stationære enheder
Et andet synspunkt, hvorfra jeg så på de undersøgte data, var at undersøge, hvor stor forskellen er mellem at arbejde med websteder på mobile og stationære enheder. Hvis vi taler om at sammenligne mængderne af JavaScript-kode, så afslører en sådan sammenligning ikke noget forfærdeligt. Det ville selvfølgelig være rart at se mindre mængder af kode, der kan downloades, men der er ikke den store forskel i mængden af mobil- og desktopkode.
Men hvis vi analyserer den tid, der kræves til at behandle koden, bliver en meget stor kløft mellem mobile og stationære enheder mærkbar.
Forøgelse i tid (procent) relateret til behandling af scripts på mobile enheder sammenlignet med desktop
Percentiler
10
25
50
75
90
Alle websteder
144.1
172.8
185.5
208.5
224.0
jQuery websteder
188.2
187.4
191.3
209.6
221.9
Vue websteder
222.5
220.8
220.2
221.4
220.4
Vinkelpladser
205.1
206.0
201.6
210.4
218.7
Reager websteder
431.5
386.8
337.9
242.6
179.6
Mens der kan forventes en vis forskel i kodebehandlingshastighed mellem en telefon og en bærbar computer, fortæller så store tal mig, at moderne rammer ikke er tilstrækkeligt målrettet mod enheder med lav effekt, og at de stræber efter at lukke det hul, de har opdaget. Selv ved 10. percentilen bruger React-websteder 431.5 % mere tid på den mobile hovedtråd end på desktop-hovedtråden. jQuery har det mindste hul, men selv her er det tilsvarende tal 188.2%. Når webstedsudviklere laver deres projekter på en sådan måde, at deres behandling kræver mere processortid (og det sker, og det bliver kun værre med tiden), skal ejerne af enheder med lav effekt betale for det.
Resultaterne af
Gode rammer bør give udviklere et godt grundlag for at bygge webprojekter (i forhold til sikkerhed, tilgængelighed, ydeevne), eller de bør have indbyggede begrænsninger, der gør det svært at bygge noget, der overtræder disse begrænsninger.
Dette lader ikke til at gælde for udførelsen af webprojekter (og formentlig ikke for deres ).
Det er værd at bemærke, at bare fordi React- eller Angular-websteder bruger mere CPU-tid på at forberede kode end andre, betyder det ikke nødvendigvis, at React-websteder er mere CPU-intensive end Vue-websteder, mens de kører. Faktisk siger de data, vi har gennemgået, meget lidt om den operationelle ydeevne af rammer og biblioteker. De taler mere om de udviklingstilgange, som disse rammer, bevidst eller ej, kan presse programmører. Vi taler om dokumentation for rammer, om deres økosystem, om fælles udviklingsteknikker.
Det er også værd at nævne noget, som vi ikke har analyseret her, nemlig hvor meget tid enheden bruger på at udføre JavaScript-kode, når den navigerer mellem siderne på webstedet. Argumentet til fordel for SPA er, at når enkeltsideapplikationen er indlæst i browseren, vil brugeren teoretisk set være i stand til at åbne siderne på siden hurtigere. Min egen erfaring siger mig, at dette langt fra er en kendsgerning. Men vi har ikke data til at afklare dette problem.
Det, der er klart, er, at hvis du bruger et framework eller et bibliotek til at oprette en hjemmeside, indgår du et kompromis med hensyn til indledningsvis at indlæse projektet og gøre det klar til at gå. Dette gælder selv de mest positive scenarier.
Det er udmærket muligt at indgå nogle kompromiser i passende situationer, men det er vigtigt, at udviklere indgår sådanne kompromiser bevidst.
Men vi har også grund til optimisme. Jeg er spændt på at se, hvor tæt Chrome-udviklerne arbejder sammen med udviklerne af nogle af de frontend-værktøjer, vi har gennemgået i et forsøg på at hjælpe med at forbedre ydeevnen af disse værktøjer.
Jeg er dog en pragmatisk person. Nye arkitekturer skaber præstationsproblemer lige så ofte, som de løser dem. Og det tager tid at rette fejl. Ligesom vi ikke skal forvente vil løse alle problemer med ydeevnen, bør du ikke forvente dette fra nye versioner af vores foretrukne rammer.
Hvis du vil bruge et af de frontend-værktøjer, der er diskuteret i denne artikel, betyder det, at du skal lægge ekstra kræfter i ikke at skade dit projekts ydeevne i mellemtiden. Her er nogle overvejelser, du skal overveje, før du starter en ny ramme:
- Test dig selv med sund fornuft. Skal du virkelig bruge den valgte ramme? Ren JavaScript i dag er i stand til meget.
- Er der et lettere alternativ til det valgte framework (som Preact, Svelte eller noget andet), der kan give dig 90% af mulighederne i dette framework?
- Hvis du allerede bruger et framework, så overvej om der er noget, der tilbyder bedre, mere konservative standardmuligheder (f.eks. Nuxt.js i stedet for Vue, Next.js i stedet for React, og så videre).
- Hvad vil din JavaScript ydeevne?
- Hvordan kan du en udviklingsproces for at gøre det sværere at injicere mere JavaScript-kode i et projekt, end det er højst nødvendigt?
- Hvis du bruger en ramme for at lette udviklingen, så overvej sende rammekode til kunder. Måske kan du løse alle problemerne på serveren?
Normalt er disse ideer værd at se på, uanset hvad du præcist har valgt til frontend-udvikling. Men de er især vigtige, når du arbejder på et projekt, der mangler præstation helt fra begyndelsen.
Kære læsere! Hvordan ser du den ideelle JavaScript-ramme?
Kilde: www.habr.com