Der er ingen hurtigere måde at gøre et websted langsommere (ordspil tilsigtet) end ved at bruge en masse JavaScript på det. Når du bruger JavaScript, skal du betale for dette i form af projektydelse mindst fire gange. Her er hvad webstedets JavaScript-kode indlæser brugernes systemer med:
- Download af en fil over netværket.
- Parsing og kompilering af den udpakkede kildekode efter download.
- Udførelse af JavaScript-kode.
- Hukommelsesforbrug.
Denne kombination viser sig at være .
Og vi inkluderer mere og mere JS-kode i vores projekter. I takt med at organisationer bevæger sig mod websteder, der drives af frameworks og biblioteker som React, Vue og andre, gør vi kernewebstedsfunktionaliteten i høj grad afhængig af JavaScript.
Jeg har set mange meget tunge hjemmesider, der bruger JavaScript-frameworks. Men mit syn på problemstillingen er meget partisk. Sagen er, at de virksomheder, jeg arbejder med, henvender sig til mig specifikt, fordi de står over for komplekse problemer med hjemmesidens ydeevne. Som følge heraf blev jeg nysgerrig efter, hvor udbredt dette problem er, og hvilke "straffe" vi betaler, når vi vælger det ene eller andet framework som grundlag for et bestemt websted.
Projektet hjalp mig med at finde ud af dette .
Data
HTTP Archive-projektet sporer i alt 4308655 links til desktop-specifikke websteder og 5484239 links til mobilwebsteder. Blandt de mange indikatorer, der er knyttet til disse links, er en liste over teknologier, der findes på de tilsvarende websteder. Det betyder, at vi kan bygge en stikprøve på tusindvis af websteder, der bruger forskellige frameworks og biblioteker, og lære om, hvor meget kode de sender til klienter, og den belastning, som koden lægger på brugernes systemer.
Jeg indsamlede data for marts 2020, hvilket var de seneste data, jeg havde adgang til.
Jeg besluttede at sammenligne aggregerede HTTP-arkivdata for alle websteder med data for websteder, der brugte React, Vue og Angular, selvom jeg også overvejede at bruge andet kildemateriale.
For at gøre det mere interessant har jeg også tilføjet websteder, der bruger jQuery, til kildedatasættet. Dette bibliotek er stadig ekstremt populært. Det repræsenterer også en tilgang til hjemmesideudvikling, der er forskellig fra Single Page Application (SPA)-modellen, der tilbydes af React, Vue og Angular.
HTTP-arkivlinks, der repræsenterer websteder, der bruger de teknologier, der er af interesse
Framework eller bibliotek
Links til mobilwebsteder
Links til almindelige hjemmesider
jQuery
4615474
3714643
Reagerer
489827
241023
Vue
85649
43691
Vinkelforskydning
19423
18088
Håb og drømme
Før vi går i gang med dataanalysen, vil jeg gerne tale om, hvad jeg gerne vil forvente.
Jeg mener, at i en ideel verden bør frameworks gå ud over blot at opfylde udviklernes behov og give nogle konkrete fordele til de almindelige brugere, der interagerer med vores websteder. Produktivitet er blot én af disse fordele. Tilgængelighed og sikkerhed er også en faktor, der kommer i betragtning. Men dette er kun det vigtigste.
Så i en ideel verden burde et framework gøre det nemt at oprette en højtydende hjemmeside. Dette bør enten ske ved, at rammerne giver bygherren et ordentligt grundlag at bygge et projekt på, eller ved at pålægge restriktioner for udviklingen og fremsætte krav, der komplicerer udviklingen af noget, der vil vise sig at være langsomt.
De bedste rammer bør gøre begge dele: give et godt fundament og pålægge arbejdet begrænsninger, så det kan opnå et anstændigt resultat.
Analyse af medianværdierne af dataene vil ikke give os den information, vi har brug for. Og faktisk lader denne tilgang være uden for vores opmærksomhed . I stedet udledte jeg percentilrangeringer ud fra de data, jeg havde. Disse er 10, 25, 50 (median), 75, 90 percentiler.
Jeg er især interesseret i den 10. og 90. percentil. Den 10. percentil repræsenterer den bedste ydeevne (eller i det mindste mere eller mindre tæt på den bedste) for et bestemt framework. Med andre ord betyder det, at kun 10% af de websteder, der bruger et bestemt framework, når dette niveau eller højere. 90-percentilen er derimod bagsiden af medaljen - den viser os, hvor slemt det kan blive. Den 90. percentil er de websteder, der ligger nederst i bunken - de sidste 10% af webstederne, der har de største mængder JS-kode eller den længste tid, det tager at behandle deres kode på hovedtråden.
JavaScript-kodevolumener
Til at begynde med giver det mening at analysere størrelsen af den JavaScript-kode, der transmitteres af forskellige websteder over netværket.
JavaScript-kodestørrelse (KB) overført til mobile enheder
Percentiler
10
25
50
75
90
Alle websteder
93.4
196.6
413.5
746.8
1201.6
jQuery-sider
110.3
219.8
430.4
748.6
1162.3
Vue-websteder
244.7
409.3
692.1
1065.5
1570.7
Angular-sider
445.1
675.6
1066.4
1761.5
2893.2
React-sider
345.8
441.6
690.3
1238.5
1893.6
Mængden af JavaScript-kode, der vises til mobile enheder
JavaScript-kodestørrelse (KB) overført til stationære enheder
Percentiler
10
25
50
75
90
Alle websteder
105.5
226.6
450.4
808.8
1267.3
jQuery-sider
121.7
242.2
458.3
803.4
1235.3
Vue-websteder
248.0
420.1
718.0
1122.5
1643.1
Angular-sider
468.8
716.9
1144.2
1930.0
3283.1
React-sider
308.6
469.0
841.9
1472.2
2197.8
Mængden af JavaScript-kode, der vises til stationære enheder
Hvis vi kun taler om størrelserne af JS-kode, som websteder sender til enheder, så ser alt ud som forventet. Nemlig, hvis et af frameworksene anvendes, betyder det, at selv i en ideel situation vil mængden af JavaScript-kode på webstedet stige. Det er ikke overraskende - man kan ikke lave et JavaScript-framework som grundlag for et websted og forvente, at mængden af JS-kode til projektet vil være meget lav.
Det bemærkelsesværdige ved disse data er, at nogle frameworks og biblioteker kan betragtes som et bedre udgangspunkt for et projekt end andre. Hjemmesider med jQuery ser bedst ud. På desktop-sider indeholder de 15 % mere JavaScript end alle andre sider, og på mobil indeholder de 18 % mere. (Det skal indrømmes, at der er en vis dataforvrængning her. Sagen er, at jQuery findes på mange websteder, så det er naturligt, at disse websteder er tættere relateret til det samlede antal websteder end andre. Dette påvirker dog ikke, hvordan de rå data leveres for hvert framework.)
Selvom en stigning i kodestørrelse på 15-18% er et betydeligt tal, kan man sammenlignet med andre frameworks og biblioteker konkludere, at den "skat", som jQuery pålægger, er meget lav. Angular-websteder i den 10. percentil sender 344 % mere data til stationære enheder end alle websteder, og 377 % mere til mobile enheder. React-sider er de næsttungeste og sender 193% mere kode end alle andre sider til desktop-enheder og 270% mere til mobile enheder.
Jeg har før nævnt, at selvom brugen af et framework betyder, at et projekt vil have en vis mængde kode inkluderet, når det først startes, håber jeg, at frameworket vil være i stand til at begrænse udvikleren på en eller anden måde. Vi taler især om at begrænse den maksimale mængde kode.
Det interessante er, at jQuery-sider følger denne idé. Selvom de på 10. percentilniveau er en smule tungere end alle websteder (med 15-18%), er de på 90. percentilniveau en smule lettere end alle websteder - med omkring 3% på både desktop og mobil. Det er ikke fordi, det er en kæmpe fordel, men man kan roligt sige, at jQuery-sider i det mindste ikke har enorme JavaScript-kodestørrelser, selv i deres største versioner.
Men det samme kan ikke siges om andre rammer.
Ligesom med den 10. percentil, er Angular- og React-websteder ved den 90. percentil forskellige fra andre websteder, men de er desværre anderledes til det værre.
Ved den 90. percentil sender Angular-websteder 141 % mere data til mobil end alle websteder, og 159 % mere til desktop. React-sider sender 73% flere besøg til desktop-enheder end alle andre sider, og 58% flere til mobile enheder. Kodestørrelsen for React-sider ved den 90. percentil er 2197.8 KB. Det betyder, at disse websteder sender 322.9 KB mere data til mobile enheder end deres nærmeste Vue-baserede konkurrenter. Kløften mellem desktop-sider bygget på Angular og React og andre sider er endnu større. For eksempel sender React-websteder til desktops 554.7 KB mere JS-kode til enheder end lignende Vue-websteder.
Tid brugt på at behandle JavaScript-kode i hovedtråden
Ovenstående data viser tydeligt, at websteder, der bruger de undersøgte frameworks og biblioteker, indeholder store mængder JavaScript-kode. Men dette er selvfølgelig kun én del af vores ligning.
Når JavaScript-koden er ankommet til browseren, skal den gøres brugbar. Særligt problematiske er de handlinger, der skal udføres med kode i browserens hovedtråd. Hovedtråden er ansvarlig for at behandle brugerhandlinger, beregne stilarter og konstruere og vise sidelayoutet. Hvis du overbelaster hovedtråden med JavaScript-opgaver, vil den ikke være i stand til at løse andre opgaver rettidigt. Dette fører til forsinkelser og "afmatninger" i sidernes drift.
HTTP-arkivet-databasen indeholder oplysninger om, hvor lang tid det tager at behandle JavaScript-kode på V8-motorens hovedtråd. Det betyder, at vi kan indsamle disse data og lære om, hvor lang tid hovedtråden bruger på at behandle JavaScript for forskellige websteder.
CPU-tid (i millisekunder) brugt på at behandle scripts på mobile enheder
Percentiler
10
25
50
75
90
Alle websteder
356.4
959.7
2372.1
5367.3
10485.8
jQuery-sider
575.3
1147.4
2555.9
5511.0
10349.4
Vue-websteder
1130.0
2087.9
4100.4
7676.1
12849.4
Angular-sider
1471.3
2380.1
4118.6
7450.8
13296.4
React-sider
2700.1
5090.3
9287.6
14509.6
20813.3
CPU-tid relateret til scriptbehandling på mobile enheder
CPU-tid (i millisekunder) brugt på at behandle scripts på stationære enheder
Percentiler
10
25
50
75
90
Alle websteder
146.0
351.8
831.0
1739.8
3236.8
jQuery-sider
199.6
399.2
877.5
1779.9
3215.5
Vue-websteder
350.4
650.8
1280.7
2388.5
4010.8
Angular-sider
482.2
777.9
1365.5
2400.6
4171.8
React-sider
508.0
1045.6
2121.1
4235.1
7444.3
CPU-tid brugt på at behandle scripts på stationære enheder
Du kan se noget meget velkendt her.
Til at begynde med bruger jQuery-drevne websteder betydeligt mindre tid på at behandle JavaScript på hovedtråden end andre. Ved den 10. percentil bruger jQuery-sider på mobil 61 % mere tid på at behandle JS-kode på hovedtråden sammenlignet med alle andre websteder. For desktop jQuery-websteder øges behandlingstiden med 37 %. Ved den 90. percentil præsterer jQuery-sider meget tæt på de samlede scorer. Specifikt bruger jQuery-sider på mobil 1.3 % mindre tid på hovedtråden end alle andre sider, og på desktop 0.7 % mindre tid.
På den anden side af vores vurdering er der frameworks, der er karakteriseret ved den største belastning på hovedtråden. Dette er, igen, Angular og React. Den eneste forskel mellem dem er, at mens Angular-sider sender større mængder kode til browsere end React-sider, bruger Angular-sider mindre CPU-tid på at behandle koden. Meget mindre.
Ved den 10. percentil bruger Angular-websteder til desktops 230 % mere tid på at behandle JS-kode i hovedtråde end alle andre websteder. For mobilsider er dette tal 313 %. React-sider klarer sig dårligst. På desktop bruger de 248 % mere tid på at behandle kode end alle websteder tilsammen, og på mobil bruger de 658 % mere tid. 658% er ikke en tastefejl. Ved den 10. percentil bruger React-sider 2.7 sekunder af hovedtrådens tid på at behandle den kode, de indeholder.
90. percentil-scorerne ser i det mindste lidt bedre ud sammenlignet med disse enorme tal. Angular-projekter bruger 29% mere tid i hovedtråden på desktop-enheder og 27% mere tid på mobile enheder sammenlignet med alle andre websteder. I tilfælde af React-sider ser de tilsvarende tal ud til at være henholdsvis 130 % og 98 %.
De procentvise afvigelsesværdier for 90. percentilen ser bedre ud end dem for 10. percentilen. Men her er det værd at huske, at tallene, der angiver tiden, virker ret skræmmende. Lad os sige 20.8 sekunder på hovedtråden på en mobilenhed for et websted bygget på React. (Jeg mener, at historien om, hvad der rent faktisk sker i denne periode, fortjener en separat artikel.)
Der er én potentiel komplikation her (tak for at have henledt min opmærksomhed på denne funktion og for at have fået mig til at overveje dataene nøje fra dette synspunkt). Sagen er, at mange hjemmesider bruger flere frontend-værktøjer. Især har jeg set mange websteder, der bruger jQuery sammen med React eller Vue, efterhånden som disse websteder migrerer fra jQuery til andre frameworks eller biblioteker. Så jeg gik tilbage til databasen igen, denne gang valgte jeg kun de links, der svarede til websteder, der kun brugte React, jQuery, Angular eller Vue, men ikke nogen kombination af dem. Det her er, hvad jeg fik.
CPU-tid (i millisekunder) relateret til scriptbehandling på mobile enheder i en situation, hvor websteder kun bruger ét framework 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
CPU-tid relateret til scriptbehandling på mobile enheder i en situation, hvor websteder kun bruger ét framework eller kun ét bibliotek
For det første, noget der ikke burde komme som en overraskelse: når et websted kun bruger ét framework eller ét bibliotek, forbedres webstedets ydeevne oftere end ikke. Hvert instruments præstation ser bedre ud ved den 10. og 25. percentil. Det giver mening. Et websted, der er bygget ved hjælp af ét framework, bør være mere effektivt end et websted, der er bygget ved hjælp af to eller flere frameworks eller biblioteker.
Faktisk ser tallene for alle de frontend-værktøjer, vi har set på, bedre ud i alle tilfælde, med én mærkelig undtagelse. Det, der overraskede mig, var, at websteder, der bruger React, klarer sig dårligere ved 50. percentil og derover, når React er det eneste bibliotek, de bruger. Det er i øvrigt grunden til, at jeg præsenterer disse data her.
Det er lidt mærkeligt, men jeg vil alligevel forsøge at finde en forklaring på denne besynderlighed.
Hvis et projekt bruger både React og jQuery, er projektet sandsynligvis et sted midt i en migrering fra jQuery til React. Det er muligt, at den har en kodebase, der blander disse biblioteker. Da vi allerede har set, at jQuery-sider bruger mindre tid på hovedtråden end React-sider, kan dette fortælle os, at implementering af nogle funktioner i jQuery hjælper med at forbedre webstedets metrics en smule.
Men efterhånden som projektet bevæger sig fra jQuery til React og i højere og højere grad er afhængig af React, ændrer tingene sig. Hvis siden er lavet rigtig godt, og sidens udviklere bruger React omhyggeligt, så vil alt være fint med sådan en side. Men for den gennemsnitlige React-hjemmeside betyder den store brug af React, at hovedtråden er under øget belastning.
Forskellen mellem mobile og stationære enheder
En anden vinkel, jeg tog ud fra de data, jeg undersøgte, var at undersøge, hvor stor forskellen var mellem mobil- og desktopoplevelsen. Hvis vi taler om at sammenligne mængderne af JavaScript-kode, afslører en sådan sammenligning ikke noget forfærdeligt. Det ville selvfølgelig være rart at se mindre mængder kode blive downloadet, men der er ingen væsentlig forskel i mængden af kode mellem mobil og desktop.
Men hvis man analyserer den tid, det tager at behandle koden, bliver der en meget stor forskel mellem mobile og stationære enheder mærkbar.
Stigning i tid (i procent) brugt på behandling af scripts på mobile enheder sammenlignet med stationære enheder
Percentiler
10
25
50
75
90
Alle websteder
144.1
172.8
185.5
208.5
224.0
jQuery-sider
188.2
187.4
191.3
209.6
221.9
Vue-websteder
222.5
220.8
220.2
221.4
220.4
Angular-sider
205.1
206.0
201.6
210.4
218.7
React-sider
431.5
386.8
337.9
242.6
179.6
Selvom der kan forventes en vis forskel i kodebehandlingshastigheden mellem en telefon og en bærbar computer, fortæller sådanne store tal mig, at moderne frameworks ikke er tilstrækkeligt fokuseret på enheder med lavt strømforbrug og ikke stræber efter at lukke det hul, der er blevet opdaget. Selv ved den 10. percentil bruger React-sider 431.5 % mere tid i den mobile hovedtråd end i den desktop-baserede hovedtråd. Det mindste hul ses med jQuery, men selv her er det tilsvarende tal 188.2%. Når webudviklere laver deres projekter, så de kræver mere processortid at behandle (og det sker, og det bliver kun værre med tiden), skal ejerne af enheder med lavt strømforbrug betale for det.
Resultaterne af
Gode frameworks bør give udviklere et godt fundament at bygge webprojekter på (med hensyn til sikkerhed, tilgængelighed, ydeevne), eller de bør have indbyggede begrænsninger, der gør det vanskeligt at bygge noget, der overtræder disse begrænsninger.
Dette ser ikke ud til at gælde for webprojekters ydeevne (og formodentlig for deres ).
Det er værd at bemærke, at blot 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, når de kører, end Vue-websteder. Faktisk fortæller de data, vi har set på, os meget lidt om, hvordan frameworks og biblioteker fungerer. De taler mere om de udviklingsmetoder, som disse frameworks bevidst eller ubevidst kan opfordre programmører til at anvende. Vi taler om dokumentation for frameworks, deres økosystem og almindelige 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 skifter mellem websider. Argumentet for SPA er, at når SPA'en er indlæst i browseren, vil brugeren teoretisk set kunne tilgå webstedets sider hurtigere. Min egen erfaring siger mig, at dette langt fra er sikkert. Men vi har ingen data til at afklare dette problem.
Det er klart, at hvis du bruger et framework eller et bibliotek til at bygge en hjemmeside, indgår du et kompromis med hensyn til, hvordan du i første omgang starter projektet op og gør det klar til brug. Dette gælder selv de mest positive scenarier.
I passende situationer er det fuldt ud muligt at indgå nogle kompromiser, men det er vigtigt, at udviklere indgår sådanne kompromiser bevidst.
Men vi har også grund til optimisme. Jeg er opmuntret af, hvor tæt Chrome-udviklerne arbejder sammen med folkene bag nogle af de front-end-værktøjer, vi har undersøgt for at forbedre ydeevnen af disse værktøjer.
Jeg er dog en pragmatisk person. Nye arkitekturer skaber ydeevneproblemer lige så ofte, som de løser dem. Og det tager tid at udbedre manglerne. Ligesom vi ikke bør forvente det løse alle ydeevneproblemer, bør du ikke forvente dette fra nye versioner af vores yndlingsframeworks.
Hvis du vil bruge et af de frontend-værktøjer, der er omtalt i denne artikel, betyder det, at du bliver nødt til at gøre en ekstra indsats for at sikre, at du ikke skader dit projekts ydeevne i processen. Her er nogle overvejelser, du bør overveje, før du begynder at bruge et nyt framework:
- Tjek dig selv ud fra et sundt fornufts synspunkt. Har du virkelig brug for det framework, du vælger? Ren JavaScript kan meget i disse dage.
- Findes der et lettere alternativ til dit valgte framework (som Preact, Svelte eller noget andet), der kan give dig 90% af mulighederne i det pågældende framework?
- Hvis du allerede bruger et framework, så overvej om der findes noget, der tilbyder bedre, mere konservative standardindstillinger (f.eks. Nuxt.js i stedet for Vue, Next.js i stedet for React osv.).
- Hvordan vil din være? JavaScript-ydeevne?
- Hvordan kan du udviklingsproces med det mål at gøre det vanskeligere at inkorporere mere JavaScript-kode i et projekt end absolut nødvendigt?
- Hvis du bruger et framework for at lette udviklingen, bør du overveje sende framework-kode til klienter. Måske kan du løse alle problemerne på serveren?
Det er generelt idéer, der er værd at se nærmere på, uanset hvad du vælger at gøre med din frontend-udvikling. Men de er især vigtige, når du arbejder på et projekt, der mangler produktivitet fra starten.
Kære læsere! Hvad ser du som det ideelle JavaScript-framework?
Kilde: www.habr.com
