Non esiste un modo più veloce per rallentare un sito Web (gioco di parole) piuttosto che utilizzare un mucchio di codice JavaScript su di esso. Quando usi JavaScript, devi pagare per questo con le prestazioni dei progetti non meno di quattro volte. Ecco come il codice JavaScript del sito carica i sistemi degli utenti:
- Download di un file sulla rete.
- Analisi e compilazione del codice sorgente decompresso dopo il download.
- Esecuzione del codice JavaScript.
- Consumo di memoria.
Questa combinazione risulta .
E includiamo sempre più codice JS nei nostri progetti. Man mano che le organizzazioni si spostano verso siti alimentati da framework e librerie come React, Vue e altri, stiamo rendendo le funzionalità di base dei siti fortemente dipendenti da JavaScript.
Ho visto molti siti molto pesanti che utilizzano framework JavaScript. Ma la mia visione della questione è molto parziale. Il fatto è che le aziende con cui collaboro si rivolgono a me proprio perché si trovano di fronte a problematiche complesse nel campo delle performance dei cantieri. Di conseguenza, sono diventato curioso di sapere quanto sia comune questo problema e che tipo di "penalità" paghiamo quando scegliamo l'uno o l'altro framework come base per un determinato sito.
Il progetto mi ha aiutato a capirlo. .
Dati
Il progetto HTTP Archive tiene traccia di un totale di 4308655 collegamenti a normali siti desktop e 5484239 collegamenti a siti mobili. Tra le molte metriche associate a questi link c'è un elenco di tecnologie trovate sui rispettivi siti. Ciò significa che possiamo campionare migliaia di siti che utilizzano vari framework e librerie e conoscere quanto codice inviano ai client e quanto carico crea questo codice sui sistemi degli utenti.
Ho raccolto i dati di marzo 2020, che erano i dati più recenti a cui ho avuto accesso.
Ho deciso di confrontare i dati aggregati dell'archivio HTTP su tutti i siti con i dati dei siti trovati utilizzando React, Vue e Angular, anche se ho preso in considerazione l'utilizzo di altro materiale di origine.
Per renderlo più interessante, ho aggiunto anche siti che utilizzano jQuery al set di dati di origine. Questa libreria è ancora molto popolare. Introduce inoltre un approccio diverso allo sviluppo web rispetto al modello Single Page Application (SPA) offerto da React, Vue e Angular.
Collegamenti nell'archivio HTTP che rappresentano siti che sono stati trovati per utilizzare tecnologie di interesse
Quadro o libreria
Collegamenti a siti per dispositivi mobili
Collegamenti a siti regolari
jQuery
4615474
3714643
Reagire
489827
241023
Vue
85649
43691
Angular
19423
18088
Speranze e sogni
Prima di passare all'analisi dei dati, voglio parlare di ciò che vorrei sperare.
Credo che in un mondo ideale, i framework dovrebbero andare oltre a soddisfare le esigenze degli sviluppatori e fornire alcuni vantaggi specifici all'utente medio che lavora con i nostri siti. Le prestazioni sono solo uno di questi vantaggi. È qui che entrano in gioco accessibilità e sicurezza. Ma questo è solo il più importante.
Quindi, in un mondo ideale, una sorta di framework dovrebbe semplificare la creazione di un sito ad alte prestazioni. Ciò dovrebbe essere fatto o perché il framework offre allo sviluppatore una base decente su cui costruire un progetto, o perché impone restrizioni allo sviluppo, propone requisiti che complicano lo sviluppo di qualcosa che gira essere lento.
I migliori framework dovrebbero fare entrambe le cose: dare una buona base e imporre restrizioni al lavoro, permettendoti di ottenere un risultato decente.
Analizzare i valori mediani dei dati non ci darà le informazioni di cui abbiamo bisogno. E, infatti, questo approccio lascia fuori dalla nostra attenzione . Invece, ho derivato le percentuali dai dati che avevo. Questi sono 10, 25, 50 (mediana), 75, 90 percentili.
Sono particolarmente interessato al 10° e 90° percentile. Il decimo percentile rappresenta la prestazione migliore (o almeno più o meno vicina alla migliore) per un particolare framework. In altre parole, ciò significa che solo il 10% dei siti che utilizzano un particolare framework arriva a questo livello o superiore. Il 10esimo percentile, d'altra parte, è l'altra faccia della medaglia: ci mostra quanto possono andare male le cose. Il 90° percentile è rappresentato dai siti che seguono: quel 90% inferiore di siti che hanno la maggior parte del codice JS o il tempo più lungo per elaborare il proprio codice sul thread principale.
Volumi di codice JavaScript
Per cominciare, ha senso analizzare la dimensione del codice JavaScript trasmesso da diversi siti sulla rete.
La quantità di codice JavaScript (Kb) trasferita ai dispositivi mobili
Percentili
10
25
50
75
90
Tutti i siti
93.4
196.6
413.5
746.8
1201.6
siti jQuery
110.3
219.8
430.4
748.6
1162.3
Vedi i siti
244.7
409.3
692.1
1065.5
1570.7
Siti angolari
445.1
675.6
1066.4
1761.5
2893.2
Siti di reazione
345.8
441.6
690.3
1238.5
1893.6
Quantità di codice JavaScript inviato ai dispositivi mobili
Quantità di codice JavaScript (Kb) trasferito ai dispositivi desktop
Percentili
10
25
50
75
90
Tutti i siti
105.5
226.6
450.4
808.8
1267.3
siti jQuery
121.7
242.2
458.3
803.4
1235.3
Vedi i siti
248.0
420.1
718.0
1122.5
1643.1
Siti angolari
468.8
716.9
1144.2
1930.0
3283.1
Siti di reazione
308.6
469.0
841.9
1472.2
2197.8
Quantità di codice JavaScript inviato ai dispositivi desktop
Se parliamo solo della dimensione del codice JS che i siti inviano ai dispositivi, allora tutto sembra come ci si potrebbe aspettare. Vale a dire, se viene utilizzato uno dei framework, ciò significa che anche in una situazione ideale, il volume del codice JavaScript del sito aumenterà. Ciò non sorprende: non è possibile creare un framework JavaScript come base di un sito e aspettarsi che il volume del codice JS del progetto sia molto basso.
Ciò che è notevole di questi dati è che alcuni framework e librerie possono essere considerati un punto di partenza migliore per un progetto rispetto ad altri. I siti con jQuery sembrano i migliori. Nelle versioni desktop dei siti contengono il 15% in più di JavaScript rispetto a tutti i siti e sui dispositivi mobili ne contengono il 18% in più. (Certo, qui c'è una certa corruzione dei dati. Il fatto è che jQuery è presente su molti siti, quindi è naturale che tali siti siano più strettamente associati di altri al numero totale di siti. Tuttavia, ciò non influisce sulla modalità grezza i dati vengono emessi per ogni framework.)
Sebbene l'aumento del 15-18% del volume del codice sia una cifra notevole, confrontandolo con altri framework e librerie, si può concludere che la "tassa" riscossa da jQuery è molto bassa. I siti angolari nel 10° percentile inviano il 344% in più di dati al desktop rispetto a tutti i siti e il 377% in più ai dispositivi mobili. I siti React sono i secondi più pesanti, inviando il 193% in più di codice sul desktop rispetto a tutti i siti e il 270% in più sui dispositivi mobili.
In precedenza, ho detto che sebbene l'utilizzo di un framework significhi che una certa quantità di codice sarà inclusa nel progetto, proprio all'inizio del lavoro su di esso, spero che il framework sia in grado di limitare in qualche modo lo sviluppatore. In particolare, stiamo parlando di limitare la quantità massima di codice.
È interessante notare che i siti jQuery seguono questa idea. Sebbene siano leggermente più pesanti di tutti i siti al 10° percentile (del 15-18%), sono leggermente più leggeri al 90° percentile, intorno al 3%, sia su desktop che su dispositivi mobili. Questo non vuol dire che questo sia un vantaggio molto significativo, ma si può dire che i siti jQuery, almeno, non hanno enormi dimensioni del codice JavaScript, anche nelle loro versioni più grandi.
Ma lo stesso non si può dire di altri framework.
Proprio come nel caso del 10° percentile, al 90° percentile i siti su Angular e React differiscono da altri siti, ma purtroppo differiscono in peggio.
Al 90° percentile, i siti Angular inviano il 141% in più di dati ai dispositivi mobili rispetto a tutti i siti e il 159% in più ai desktop. I siti React inviano il 73% in più al desktop rispetto a tutti i siti e il 58% in più ai dispositivi mobili. La dimensione del codice dei siti React al 90° percentile è di 2197.8 KB. Ciò significa che tali siti inviano 322.9 KB di dati in più ai dispositivi mobili rispetto ai loro concorrenti più vicini basati su Vue. Il divario tra i siti desktop basati su Angular e React e altri siti è ancora maggiore. Ad esempio, i siti React desktop inviano 554.7 KB di codice JS in più ai dispositivi rispetto ai siti Vue equivalenti.
Tempo impiegato per elaborare il codice JavaScript nel thread principale
I dati di cui sopra indicano chiaramente che i siti che utilizzano i framework e le librerie oggetto di studio contengono grandi quantità di codice JavaScript. Ma ovviamente, questa è solo una parte della nostra equazione.
Dopo che il codice JavaScript è arrivato nel browser, deve essere portato in uno stato funzionante. Soprattutto molti problemi sono causati da quelle azioni che devono essere eseguite con il codice nel thread principale del browser. Il thread principale è responsabile dell'elaborazione delle azioni dell'utente, del calcolo degli stili, della creazione e della visualizzazione del layout di pagina. Se sovraccarichi il thread principale con attività JavaScript, non avrà l'opportunità di completare il resto delle attività in tempo. Ciò porta a ritardi e "freni" nel lavoro delle pagine.
Il database HTTP Archive contiene informazioni sul tempo necessario per elaborare il codice JavaScript nel thread principale del motore V8. Ciò significa che possiamo raccogliere questi dati e scoprire quanto tempo impiega il thread principale per elaborare il JavaScript di vari siti.
Tempo del processore (in millisecondi) relativo all'elaborazione degli script sui dispositivi mobili
Percentili
10
25
50
75
90
Tutti i siti
356.4
959.7
2372.1
5367.3
10485.8
siti jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Vedi i siti
1130.0
2087.9
4100.4
7676.1
12849.4
Siti angolari
1471.3
2380.1
4118.6
7450.8
13296.4
Siti di reazione
2700.1
5090.3
9287.6
14509.6
20813.3
Tempo del processore relativo all'elaborazione degli script sui dispositivi mobili
Tempo del processore (in millisecondi) relativo all'elaborazione degli script sui dispositivi desktop
Percentili
10
25
50
75
90
Tutti i siti
146.0
351.8
831.0
1739.8
3236.8
siti jQuery
199.6
399.2
877.5
1779.9
3215.5
Vedi i siti
350.4
650.8
1280.7
2388.5
4010.8
Siti angolari
482.2
777.9
1365.5
2400.6
4171.8
Siti di reazione
508.0
1045.6
2121.1
4235.1
7444.3
Tempo del processore relativo all'elaborazione degli script sui dispositivi desktop
Qui puoi vedere qualcosa di molto familiare.
Per cominciare, i siti con jQuery spendono molto meno per l'elaborazione JavaScript sul thread principale rispetto ad altri siti. Al 10° percentile, rispetto a tutti i siti, i siti jQuery su dispositivi mobili impiegano il 61% in più di tempo per elaborare il codice JS sul thread principale. Nel caso dei siti desktop jQuery, il tempo di elaborazione aumenta del 37%. Al 90° percentile, i siti jQuery ottengono un punteggio molto vicino ai punteggi aggregati. Nello specifico, i siti jQuery sui dispositivi mobili trascorrono l'1.3% in meno di tempo sul thread principale rispetto a tutti i siti e lo 0.7% in meno sui dispositivi desktop.
Dall'altro lato della nostra valutazione ci sono i framework caratterizzati dal carico più elevato sulla filettatura principale. Questo è, ancora una volta, Angular e React. L'unica differenza tra i due è che mentre i siti Angular inviano più codice ai browser rispetto ai siti React, i siti Angular impiegano meno tempo della CPU per elaborare il codice. Molto meno.
Al 10° percentile, i siti Angular desktop trascorrono il 230% di tempo in più sul thread principale che elabora il codice JS rispetto a tutti i siti. Per i siti mobili, questa cifra è del 313%. I siti React sono i peggiori. Su desktop, impiegano il 248% in più di tempo per l'elaborazione del codice rispetto a tutti i siti e il 658% in più sui dispositivi mobili. Il 658% non è un errore di battitura. Al 10° percentile, i siti React impiegano 2.7 secondi del tempo del thread principale per elaborare il loro codice.
Il 90° percentile, rispetto a questi numeri enormi, sembra almeno un po' migliore. Rispetto a tutti i siti, i progetti Angular trascorrono il 29% in più di tempo sui dispositivi desktop nel thread principale e il 27% in più sui dispositivi mobili. Nel caso dei siti React, le stesse cifre sembrano rispettivamente del 130% e del 98%.
Le deviazioni percentuali per il 90° percentile sembrano migliori di valori simili per il 10° percentile. Ma qui vale la pena ricordare che i numeri che indicano l'ora sembrano piuttosto spaventosi. Diciamo 20.8 secondi sul thread mobile principale per un sito Web creato con React. (Penso che la storia di ciò che accade realmente in questo periodo sia degna di un articolo a parte).
C'è una potenziale complicazione qui (grazie per aver attirato la mia attenzione su questa caratteristica e per aver considerato attentamente i dati da questo punto di vista). Il fatto è che molti siti utilizzano diversi strumenti front-end. In particolare, ho visto molti siti che utilizzano jQuery insieme a React o Vue, poiché questi siti stanno migrando da jQuery ad altri framework o librerie. Di conseguenza, ho aperto nuovamente il database, questa volta selezionando solo quei collegamenti che corrispondono a siti che utilizzano solo React, jQuery, Angular o Vue, ma nessuna combinazione di essi. Ecco cosa ho ottenuto.
Tempo di elaborazione (in millisecondi) relativo all'elaborazione di script su dispositivi mobili in una situazione in cui i siti utilizzano un solo framework o una sola libreria
Percentili
10
25
50
75
90
Siti che utilizzano solo jQuery
542.9
1062.2
2297.4
4769.7
8718.2
I siti che utilizzano solo Vue
944.0
1716.3
3194.7
5959.6
9843.8
Siti che utilizzano solo Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Siti che utilizzano solo React
2443.2
4620.5
10061.4
17074.3
24956.3
Tempo di elaborazione relativo all'elaborazione di script su dispositivi mobili in una situazione in cui i siti utilizzano un solo framework o una sola libreria
Innanzitutto, qualcosa che non sorprende: quando un sito utilizza solo un framework o una libreria, le prestazioni di tale sito migliorano il più delle volte. Ogni strumento ha prestazioni migliori al 10° e al 25° percentile. Ha senso. Un sito realizzato utilizzando un framework dovrebbe funzionare meglio di un sito realizzato utilizzando due o più framework o librerie.
In effetti, le prestazioni di ogni strumento front-end studiato sembrano migliori in tutti i casi, ad eccezione di una curiosa eccezione. Ciò che mi ha sorpreso è stato che al 50° percentile e oltre, i siti che utilizzano React hanno prestazioni peggiori quando React è l'unica libreria che utilizzano. Questo, tra l'altro, è stato il motivo per cui presento questi dati qui.
Questo è un po' strano, ma cercherò comunque di cercare una spiegazione per questa stranezza.
Se un progetto utilizza sia React che jQuery, è probabile che quel progetto si trovi da qualche parte a metà della transizione da jQuery a React. Forse ha una base di codice in cui queste librerie sono miste. Poiché abbiamo già visto che i siti jQuery trascorrono meno tempo sul thread principale rispetto ai siti React, questo potrebbe dirci che l'implementazione di alcune funzionalità in jQuery aiuta il sito a funzionare un po' meglio.
Ma mentre il progetto passa da jQuery a React e si affida maggiormente a React, le cose stanno cambiando. Se il sito è davvero di alta qualità e gli sviluppatori del sito usano React con attenzione, allora andrà tutto bene con un sito del genere. Ma per il sito React medio, l'uso estensivo di React significa che il thread principale è sotto carico pesante.
Il divario tra dispositivi mobili e desktop
Un altro punto di vista da cui ho esaminato i dati ricercati è stato quello di studiare quanto sia grande il divario tra il lavoro con i siti su dispositivi mobili e desktop. Se parliamo di confrontare i volumi del codice JavaScript, un tale confronto non rivela nulla di terribile. Certo, sarebbe bello vedere quantità minori di codice scaricabile, ma non c'è molta differenza nella quantità di codice mobile e desktop.
Ma se analizziamo il tempo necessario per elaborare il codice, diventa evidente un divario molto ampio tra dispositivi mobili e desktop.
Aumento del tempo (percentuale) relativo all'elaborazione degli script su dispositivi mobili rispetto a desktop
Percentili
10
25
50
75
90
Tutti i siti
144.1
172.8
185.5
208.5
224.0
siti jQuery
188.2
187.4
191.3
209.6
221.9
Vedi i siti
222.5
220.8
220.2
221.4
220.4
Siti angolari
205.1
206.0
201.6
210.4
218.7
Siti di reazione
431.5
386.8
337.9
242.6
179.6
Sebbene ci si possa aspettare una certa differenza nella velocità di elaborazione del codice tra un telefono e un laptop, numeri così elevati mi dicono che i framework moderni non sono sufficientemente mirati ai dispositivi a bassa potenza e che si stanno sforzando di colmare il divario che hanno scoperto. Anche al 10° percentile, i siti React trascorrono il 431.5% di tempo in più sul thread principale mobile rispetto al thread principale desktop. jQuery ha il divario più piccolo, ma anche qui la cifra corrispondente è del 188.2%. Quando gli sviluppatori di siti Web realizzano i loro progetti in modo tale che la loro elaborazione richieda più tempo del processore (e succede, e peggiora solo nel tempo), i proprietari di dispositivi a bassa potenza devono pagare per questo.
Risultati di
I buoni framework dovrebbero fornire agli sviluppatori una buona base per la creazione di progetti Web (in termini di sicurezza, accessibilità, prestazioni), oppure dovrebbero avere restrizioni integrate che rendano difficile creare qualcosa che violi tali restrizioni.
Questo non sembra applicarsi alle prestazioni dei progetti web (e presumibilmente non ai loro ).
Vale la pena notare che solo perché i siti React o Angular impiegano più tempo della CPU a preparare il codice rispetto ad altri non significa necessariamente che i siti React utilizzino più CPU rispetto ai siti Vue durante l'esecuzione. In effetti, i dati che abbiamo esaminato dicono molto poco sulle prestazioni operative di framework e librerie. Parlano di più degli approcci di sviluppo che, consapevolmente o meno, questi framework possono spingere i programmatori. Stiamo parlando di documentazione per framework, del loro ecosistema, di tecniche di sviluppo comuni.
Vale anche la pena menzionare qualcosa che qui non abbiamo analizzato, ovvero quanto tempo il dispositivo impiega per eseguire il codice JavaScript durante la navigazione tra le pagine del sito. L'argomento a favore di SPA è che una volta caricata nel browser l'applicazione a pagina singola, l'utente sarà teoricamente in grado di aprire più velocemente le pagine del sito. La mia esperienza mi dice che questo è ben lungi dall'essere un dato di fatto. Ma non abbiamo dati per chiarire questo problema.
Ciò che è chiaro è che se stai utilizzando un framework o una libreria per creare un sito Web, stai facendo un compromesso in termini di caricamento iniziale del progetto e preparazione per l'avvio. Questo vale anche per gli scenari più positivi.
È perfettamente possibile scendere a compromessi in situazioni appropriate, ma è importante che gli sviluppatori facciano tali compromessi consapevolmente.
Ma abbiamo anche motivi per essere ottimisti. Sono entusiasta di vedere con quanta stretta collaborazione gli sviluppatori di Chrome collaborano con gli sviluppatori di alcuni degli strumenti front-end che abbiamo esaminato nel tentativo di migliorare le prestazioni di tali strumenti.
Tuttavia, sono una persona pragmatica. Le nuove architetture creano problemi di prestazioni ogni volta che li risolvono. E ci vuole tempo per correggere i bug. Proprio come non dovremmo aspettarci risolverà tutti i problemi di prestazioni, non dovresti aspettartelo dalle nuove versioni dei nostri framework preferiti.
Se desideri utilizzare uno degli strumenti front-end discussi in questo articolo, ciò significa che dovrai impegnarti ulteriormente per non danneggiare le prestazioni del tuo progetto nel frattempo. Ecco alcune considerazioni da considerare prima di iniziare un nuovo framework:
- Mettiti alla prova con il buon senso. Hai davvero bisogno di utilizzare il framework scelto? Pure JavaScript oggi è capace di molto.
- Esiste un'alternativa più leggera al framework scelto (come Preact, Svelte o qualcos'altro) che può darti il 90% delle capacità di questo framework?
- Se stai già utilizzando un framework, considera se c'è qualcosa che offre opzioni standard migliori, più conservative (ad esempio Nuxt.js invece di Vue, Next.js invece di React e così via).
- Cosa sarà il tuo Prestazioni JavaScript?
- Come puoi un processo di sviluppo per rendere più difficile l'inserimento di più codice JavaScript in un progetto di quanto sia assolutamente necessario?
- Se stai utilizzando un framework per facilitare lo sviluppo, considera inviare codice framework ai client. Forse puoi risolvere tutti i problemi sul server?
Di solito vale la pena esaminare queste idee, indipendentemente da cosa esattamente hai scelto per lo sviluppo front-end. Ma sono particolarmente importanti quando lavori a un progetto che manca di prestazioni fin dall'inizio.
Cari lettori! Come vedi il framework JavaScript ideale?
Fonte: habr.com