Home Blogs Ottimizzazione delle applicazioni React, Angular o Vue a pagina singola per le prestazioni
Applications

Ottimizzazione delle applicazioni React, Angular o Vue a pagina singola per le prestazioni

About The Author

Outline

In questo post, esamineremo come Vue, React e Angular si confrontano in termini di prestazioni e cosa si può fare per ottimizzare le spa di e-commerce in esecuzione su questi framework frontend per la migliore esperienza utente.

Quali sono le differenze tra Angular, React e Vue in termini di prestazioni

La gestione di un sito veloce porta a una crescita dei profitti grazie a un posizionamento SEO migliore, a un maggior numero di visitatori, a sessioni più lunghe e, di conseguenza, maggiori entrate. Molti leader dell’e-commerce che comprendono il ruolo della velocità si sono già spostati verso l’architettura del commercio senza testa, consentendo l’adozione di frontend moderni, come app Web e spa progressive. I frontali SPA leggeri stanno guadagnando popolarità perché rappresentano un modo sicuro per risolvere vari problemi di prestazioni inerenti alle moderne piattaforme di e-commerce, in modo che gli operatori possano offrire vetrine velocissime.

Beh, questa è la teoria. Per verificare queste elevate affermazioni, abbiamo eseguito una piccola analisi delle prestazioni in-House. A tal fine, abbiamo testato quasi 2.000 siti Web di e-commerce più diffusi in esecuzione sui principali framework frontend e ne abbiamo valutato le prestazioni in base ai punteggi di Lighthouse 6. I risultati sono stati sorprendenti: Il punteggio medio di Lighthouse per i frontends SPA testati era solo 24, con una mediana di 19 (su 100)! Per quanto possa sembrare basso, questo risultato era ancora del 26% superiore al punteggio medio per i principali 500 rivenditori Internet statunitensi in termini di ricavi.

I siti Vue.js sono stati i più veloci, con un punteggio medio di 27 con una media di 20. I siti web angolari hanno visto una media di 23; tuttavia, i loro punteggi di performance erano più dispersi, con una media di soli 18. I siti Web React sono stati i più lenti testati, con un punteggio medio di Lighthouse di 22 e una mediana di 18. Questo è stato sorprendente, soprattutto perché il framework è utilizzato da alcuni dei più grandi giocatori, tra cui siti come PayPal, Grammarly e Vimeo, per citarne alcuni.

La conclusione del test è stata piuttosto chiara: Mentre si pensa che le spa siano più veloci dei siti Web tradizionali, c’è ancora spazio per miglioramenti. Inoltre, Google Crux e altri strumenti di misurazione non monitorano le transizioni di pagina delle applicazioni a pagina singola (SPA), travisandole come molto più lente di quanto non siano e penalizzando i loro punteggi. Scriviamo di più su questo problema in un altro post sul blog.

L’impatto del tempo di avvio e delle prestazioni di runtime sui punteggi Lighthouse

Le prestazioni delle app sono definite da due metriche: Tempo di avvio e prestazioni di runtime. La dimensione del pacchetto di codice influenza principalmente il primo, cioè il codice dell’app e il codice del framework combinati. Le prestazioni di runtime dipendono dalle specifiche funzionalità di ottimizzazione del framework e dal modo in cui gestisce la manipolazione e l’aggiornamento DOM.

Dimensioni del pacchetto

Tutti e tre i framework hanno pacchetti di codice minimi e di dimensioni simili. Sebbene la dimensione del bundle del framework influisca sul tempo di avvio, la metrica non dovrebbe essere il punto focale principale nel confronto delle prestazioni di Angular, React e Vue.

Più precisamente, le dimensioni del bundle angolare sono leggermente più grandi delle dimensioni del bundle Vue e React, mentre i bundle Vue sono leggermente più piccoli dei bundle React. Inoltre, vale la pena notare che il team di sviluppo Angular ottimizza costantemente le dimensioni dei pacchetti di codice (sorgente).

Vedere la tabella seguente per i numeri approssimativi.

Angular, React e Vue offrono tutte prestazioni di runtime eccellenti e ciascuno di essi è ugualmente adatto per essere la spina dorsale di siti Web complessi e generatori di entrate con traffico intenso.

Le metriche TTI e LCP di Lighthouse

Lighthouse è un ottimo strumento di test che restituisce preziose informazioni sulla velocità. Identifica i possibili problemi di prestazioni e aiuta a ottimizzare i vari aspetti di un sito. Il punteggio del faro viene calcolato in base alla media ponderata di più metriche (fare clic qui per un riepilogo completo). Tuttavia, il più grande Contentful Paint (LCP), il Time to Interactive (TTI) e il Cumulative Layout Shift (CLS) sono molto probabilmente i più importanti dal punto di vista dell’utente. TTI e LCP sono direttamente collegati alla velocità di carico percepita.

Il TTI è una buona rappresentazione dell’impatto delle dimensioni del bundle di un framework sulla velocità del centro di assistenza tecnica, in quanto il bundle deve essere valutato interamente prima che un utente possa interagire con l’app. I siti con un TTI lungo mostreranno varie parti del sito durante il caricamento, ma non consentiranno agli utenti di interagire con esso, il che potrebbe portare alla frustrazione.

La metrica LCP, d’altra parte, misura il tempo necessario prima che l’elemento più grande del contenuto della pagina venga visualizzato sullo schermo.

Lighthouse e dati di navigazione reali

Vale la pena notare che gli strumenti di misurazione della velocità sintetica (come Lighthouse) non raccontano tutta la storia. La velocità del sito è più su come il sito “si sente” quando gli utenti lo navigano. Un punteggio relativo alle prestazioni di Lighthouse è un buon punto di riferimento, ma è un po’ arbitrario e difficile da correlare a un’esperienza reale. Ad esempio, è difficile tradurre quanto migliore sarebbe un punteggio di prestazioni di 60, in termini di esperienza utente, rispetto a un punteggio di 50.

I test sintetici tendono anche a simulare dispositivi e connessioni meno recenti (ad esempio, Lighthouse simula connessioni 3G), mentre in realtà la maggior parte degli utenti mobili utilizza reti LTE veloci o addirittura 5G.

Un sito in esecuzione su un framework specifico può “sentirsi” più veloce ma perdere rispetto ad altri siti per quanto riguarda il suo punteggio di performance grezzo e viceversa. Ciò è dovuto principalmente a trucchi specifici (ad esempio, caricamento pigro) che ogni framework utilizza per migliorare la velocità del sito “si sente” per gli utenti.

Nelle sezioni successive esamineremo le opportunità offerte da ciascuno di questi framework per migliorare le prestazioni dei siti Web.

Angolare

Angle estende il codice HTML con nuovi tag e attributi e interpreta gli attributi per eseguire l’associazione dei dati.

Grazie alle sue ricche funzionalità, l’applicazione funzionante potrebbe essere molto più grande (circa 500 KB) rispetto a Vue o React, con un impatto leggermente sulle prestazioni.

Astrazione MVC di angular (source)

Ecco un breve riepilogo dei principali vantaggi di Angular.

  • Generazione del codice. Angle genera codice altamente ottimizzato per le macchine virtuali JavaScript, offrendo i vantaggi del codice scritto a mano. I modelli HTML combinati con JavaScript aprono la strada a ottimizzazioni impossibili in altri framework, ad esempio React.
  • Suddivisione del codice. Grazie a Component router, le app angolari vengono caricate rapidamente, offrendo la suddivisione automatica del codice. In questo modo, gli utenti caricano il codice necessario per eseguire il rendering della vista richiesta.
  • Vero DOM. Angle utilizza DOM reale; pertanto, è più adatto per le applicazioni a pagina singola in cui i contenuti vengono aggiornati solo di volta in volta, non quelli che cambiano frequentemente, come la maggior parte dei siti di e-commerce. La manipolazione del DOM virtuale è molto più veloce perché non viene disegnato nulla sullo schermo.

Reagisci

Creato e sviluppato da Facebook, React è uno dei framework di applicazioni mobili open source più popolari. Non fornisce una vasta gamma di librerie; quindi, la sua dimensione è significativamente più piccola di quella di Angular.

Con i dati a direzione singola, React consente un migliore controllo sul progetto: Durante la progettazione di un’app, gli sviluppatori React possono annidare i componenti figlio all’interno di componenti padre di ordine superiore.

React offre alcune caratteristiche interessanti, tra cui:

  • DOM virtuale: Il rendering dei nodi viene eseguito solo se necessario. React confronta i nuovi dati con il DOM originale e aggiorna automaticamente la visualizzazione. Ciò migliora le prestazioni delle applicazioni di tutte le dimensioni che necessitano di aggiornamenti regolari dei contenuti.
  • Associazione dati unidirezionale: React utilizza l’associazione dati unidirezionale con l’architettura applicativa dei controlli Flux. ReactJS consente di aggiornare la visualizzazione per l’utente e Flux controlla il flusso di lavoro dell’applicazione. Il DOM virtuale aggiunge vantaggi in quanto confronta i nuovi dati con il DOM originale e aggiorna automaticamente la visualizzazione.
  • Supporto per il raggruppamento e l’agitazione degli alberi: Riduce al minimo il carico delle risorse dell’utente finale.
  • Supporto del rendering lato server (SSR): Offre un aumento della velocità in implementazioni specifiche.

“In misura maggiore rispetto ad Angular e Vue, React utilizza alcune tecniche che rendono la pagina “sensibile” più veloce per gli utenti finali.” Ad esempio, il framework assegna la priorità all’input dell’utente rispetto al rendering del contenuto nella pagina.

Vue

Vue è veloce e molto piccolo, con una capacità di circa 30 KB (gzip), il che si traduce in un caricamento più veloce dei primi caricamenti. Questo lo rende il più piccolo di tutti e tre i framework e accelera significativamente le prestazioni dei siti Web in esecuzione su Vue.

Vue offre:

  • Rendering lato server (SSR)
  • Tremolio
  • Impacchettamento
  • DOM virtuale: I cambiamenti all’interno di un progetto non influenzano correttamente il DOM. La modifica del DOM reale è un’attività ad uso intensivo di risorse, pertanto gli aggiornamenti vengono prima applicati al DOM virtuale.

Consultate questo rapporto dettagliato sui benchmark per confrontare i tempi di avvio, l’allocazione della memoria e la durata di operazioni specifiche nei principali framework e librerie JavaScript. Rispetto a React, Vue è leggermente migliore in termini di allocazione della memoria e tempi di avvio, sebbene React sia un po’ più veloce in termini di runtime.

Angular e Vue utilizzano modelli HTML combinati con JavaScript. Questo dà loro ulteriore spazio per l’ottimizzazione che React non offre. Ad esempio, Vue tiene traccia delle dipendenze evitando rendering non necessari dei componenti secondari.

Vue vs. React vs. Ottimizzazione SPA angolare

Sappiamo che i benchmark e i punteggi delle prestazioni non raccontano tutta la storia. La velocità del sito Web può variare a seconda delle dimensioni dell’applicazione e delle attività di ottimizzazione. Ecco alcune idee per ottimizzare le spa Vue, React e Angular per la velocità.

1. Rendering lato server (SSR)

In generale, l’utilizzo di SSR con i siti SPA presenta quattro vantaggi principali:

  • SSR consente di caricare rapidamente un modello SPA e di visualizzare il contenuto per l’utente (anche se l’utente potrebbe non essere in grado di interagire con esso immediatamente). Senza SSR, gli utenti guardano una schermata vuota, in attesa del caricamento del contenuto e del rendering nel browser.
  • SSR riduce il carico sulla macchina dell’utente finale.
  • Dal momento che Google ora può eseguire correttamente la scansione dei contenuti SPA, il rendering lato server potrebbe non essere così importante per SEO come un tempo. Ma il vantaggio dell’utilizzo di SSR è che molti altri motori di ricerca ancora non comprendono JavaScript e non riescono a eseguire correttamente il crawl dei siti pesanti di JavaScript.
  • I social network spesso non riescono a visualizzare correttamente i contenuti condivisi dai siti SPA client-renderizzati. Ad esempio, lo scraper di Facebook si basa solo sui meta tag impostati dal server e non funziona con meta tag rendering lato client. Per controllare meglio l’aspetto del sito SPA quando condiviso tramite Open Graph (grafico aperto), SSR è indispensabile.
  • AMP accelera i primi carichi sui dispositivi mobili ma non ti consente di utilizzare JavaScript. È impossibile eseguire il rendering AMP da React sul client, deve essere fatto sul server. Tuttavia, anche con SSR in uso, ci sono molti passaggi da eseguire per convertire un’app React in un’app AMP valida. Fortunatamente, alcuni framework frontend, come React Storefront, possono gestire tutto per voi.

SSR funziona meglio per i siti statici, ma i siti Web eCommerce SPA sono ancora memorizzabili nella cache, con la giusta infrastruttura. Con Layer0, il rendering del contenuto viene eseguito sul lato server mobile e quindi memorizzato nella cache sull’edge con il nostro CDN-as-JavaScript. In questo modo, i siti Web basati su database su larga scala, come le spa e-commerce con migliaia, se non milioni di pagine, la personalizzazione, l’inventario in tempo reale e altro ancora, possono deliziare gli utenti con caricamenti di pagine inferiori alla seconda, dall’atterraggio alla cassa.

Il service worker CDN-as-JavaScript (chiamato Layer0 Workers) recupera in modo intelligente i dati dinamici dall’edge prima che il visitatore tocchi un collegamento e li riproduca nel browser, in base a ciò che probabilmente toccherà.

Gli strumenti di monitoraggio e di rete Layer0 assicurano che i dati dinamici vengano memorizzati nella cache almeno il 95% del tempo, proteggendo il database dalle richieste aggiuntive create tramite il precaricamento. In questo modo, è possibile fornire caricamenti di pagine inferiori al secondo, offrendo ai visitatori un’esperienza fluida dall’atterraggio al checkout.

Strumenti di monitoraggio e rete Layer0

In generale, per quanto riguarda le funzionalità SSR e la documentazione dettagliata, Vue è superiore a React, che necessita di librerie di terze parti (ad esempio Next.js) per il rendering delle pagine lato server.

2. AMP

AMP crea esperienze migliori e più veloci sul Web mobile semplificando l’HTML e applicando rigide limitazioni su CSS e JavaScript. Queste pagine vengono quindi memorizzate nella cache e pre-renderizzate sul server Google, il che rende la transizione all’app quasi istantanea.

Lo svantaggio è che è diverso da come si scrive una PWA/SPA e significa una riscrittura completa dell’app a meno che non si utilizzi un framework dedicato con supporto AMP integrato, come React Storefront.

Le pagine AMP hanno un carico di pagine mediano di 500 ms per il traffico proveniente dal SERP di Google. Queste velocità sono possibili perché i server di Google precaricano e prerender i contenuti AMP nel browser di un utente prima di fare clic sul collegamento alla pagina AMP. Il sito di e-commerce medio riceve una grande parte del suo traffico dalla ricerca di Google (sia organica che a pagamento), quindi questi guadagni possono avere un impatto enorme.

I siti che utilizzano AMP vedono anche una riduzione delle velocità di rimbalzo, poiché gli utenti che solitamente potrebbero rimbalzare in attesa del caricamento di una pagina ora potranno contare su un’esperienza estremamente veloce.

3. Suddivisione del codice

L’applicazione a pagina singola crescerà nel tempo man mano che si continuano ad aggiungere funzioni. Tuttavia, sappiamo che ogni applicazione ha alcune funzioni che non vengono utilizzate e rallentano inutilmente. È necessario implementare la suddivisione del codice per mantenere l’app il più velocemente possibile.

La suddivisione del codice comporta la creazione di pacchetti separati per ciascun componente di primo livello nell’app. Nel caso di una eCommerce SPA, saranno disponibili pacchetti separati per la home page, gli elenchi dei prodotti e le pagine di descrizione dei prodotti. In questo modo, quando un utente arriva alla tua app tramite un link a un prodotto specifico, il browser non ha bisogno di scaricare ed eseguire il codice per tutte le pagine precedenti, riducendo così i tempi TTI e FID.

Con la suddivisione del codice, l’app può “caricare pigro” altri componenti della pagina in background e utilizzarli se l’utente decide di navigare. In questo modo si risparmia larghezza di banda e si riduce il ritardo del primo input o FID (nota: Il FID viene spesso approssimato in base al tempo impiegato per la metrica interattiva o TTI), migliorando la velocità del sito Web e il posizionamento dei motori di ricerca.

4. Carico lento

Vue, React e Angular supportano il caricamento lento, che, in combinazione con SSR, può fornire miglioramenti significativi della velocità.

Il caricamento pigro rappresenta una sfida quando si implementa SSR. Il server dovrebbe sapere quali componenti sono stati utilizzati per il rendering dell’HTML in uscita e inviare il codice per tali componenti insieme all’HTML. In caso contrario, l’app dovrà essere installata nel browser ed eseguire due cicli di rendering prima che sia pronta per essere interattiva, il che aumenterà il FID (e il TTI), il che potrebbe portare a contenuti flash o jank.

Caricamento lento e SSR collegati. La libreria scelta per il caricamento pigro (ad esempio, React caricabile) influenzerà il modo in cui si genera l’HTML finale restituito nella risposta. Per acquisire i pacchetti che devono essere caricati per idratare l’HTML che è stato reso sul server, è necessario aggiungere <loadable.capture></loadable.capture> al codice SSR, quindi utilizzare la funzione getBundles di React loadable per capire quale <script><i tag /script> devono essere aggiunti al corpo del documento.

Poiché i suggerimenti del client di caricamento pigro non sono ancora supportati a livello globale da tutti i browser, esistono un paio di soluzioni alternative per implementare il caricamento pigro senza problemi.

Soluzione n. 1

Invece di eseguire il rendering delle immagini sul lato server, è possibile lasciare che vengano popolate sul lato client quando l’applicazione viene montata.

Soluzione n. 2

Utilizzare solo il caricamento pigro per le immagini “sotto la piega”, cioè, quelle che si conosce non saranno visibili immediatamente dopo il caricamento. Questo è difficile perché la linea di piegatura può spostarsi verso l’alto e verso il basso a seconda del dispositivo dell’utente e delle dimensioni del display. Tuttavia, alcuni euristici aiutano. “Ad esempio, in una pagina di categoria e-commerce, potresti disattivare il caricamento pigro per la prima serie di immagini del prodotto (è probabile che siano “sopra la piega”).” E per gli articoli che sai essere sempre al di sopra della piega (ad esempio, intestazioni, loghi aziendali, icone del carrello), non dovresti comunque attivare il carico pigro e puoi sempre renderli lato server.

Soluzione n. 3

Il rilevamento dell’agente utente può aiutare a fornire una versione appropriata della pagina resa SSR. Il rilevamento degli agenti utente non è generalmente consigliato per implementare miglioramenti progressivi, ma il trucco è una soluzione temporanea mentre i browser si aggiornano e implementano suggerimenti client.

Questa soluzione richiede di normalizzare le chiavi della cache in modo appropriato; in caso contrario, si potrebbe frammentare la cache in modo significativo.

5. CDN moderno

L’ottimizzazione della SPA in termini di velocità e l’utilizzo di una buona CDN in aggiunta a ciò migliorerà il sito, ma non è sufficiente raggiungere velocità inferiori ai secondi. Questo perché la maggior parte delle CDN tradizionali sono bravi solo a memorizzare nella cache i file statici, ma nel complesso non riescono a gestire così bene i dati JSON/HTML/SSR, mentre è esattamente ciò di cui sono fatti i siti eCommerce SPA. Per rendere più veloci questi siti è necessario che diverse tecnologie web funzionino in modo efficiente all’unisono. A differenza di altre CDN, Layer0 application-aware CDN funziona bene con le spa eCommerce. Ottimizza i rapporti di hit della cache a livelli inauditi e porta l’intelligenza ai margini della rete. In questo modo, i proprietari delle aziende decifrano le tendenze e le opportunità di ottimizzazione classificando pagine simili come tali (ad esempio PDP, PLP e carrello) invece di visualizzare semplicemente un elenco infinito di URL. In questo modo è possibile agire e vedere una differenza nei tempi di caricamento dei siti Web.

Ma soprattutto, CDN-as-JavaScript utilizza tecniche avanzate di precaricamento predittivo per trasmettere i dati memorizzati nella cache dall’edge ai browser degli utenti prima che tocchino qualsiasi cosa. In questo modo, i siti Web vengono mantenuti 5 secondi in anticipo rispetto ai tocchi degli acquirenti, consentendo loro di deliziare gli utenti con un’esperienza di navigazione istantanea.

6. Attrezzi mobili

Angle è ideale per la creazione di app mobili. È possibile utilizzare il framework per creare un’applicazione Web eseguibile su qualsiasi dispositivo o sviluppare applicazioni native iOS e Android combinando Angular con NativeScrip. Ciò consente di riutilizzare concetti angolari come l’associazione dei dati, l’iniezione di dipendenze, i servizi e l’instradamento.

React Native è considerato il re dello sviluppo multipiattaforma. Consente agli sviluppatori di riutilizzare fino al 99% del codice JavaScript tra Android e iOS con componenti simili a React. Ciò significa che gli sviluppatori possono creare widget nativi al 100% che controllano il proprio stile. Il framework gestisce il livello Visualizza come un output di stato puro, semplificando così la creazione di app complementari per iOS/Android con un aspetto nativo e prestazioni.

Sebbene sia in ritardo rispetto a React, Vue offre ancora diverse soluzioni preziose per lo sviluppo mobile. Ad esempio, NativeScript consente di scrivere applicazioni Vue e compilarle in applicazioni native iOS/Android.

Poi arriva Vue Native. Il framework combina i vantaggi degli ecosistemi Vue e RN, il rendering dichiarativo, l’associazione bidirezionale e una serie di componenti di base per la creazione di un’app nativa multipiattaforma.

I centri benessere sono più veloci, ma hanno ancora problemi di velocità

Il fascino originale di un’applicazione a pagina singola è che le pagine successive non si ricaricano durante la navigazione, il che consente un’esperienza di navigazione più veloce e senza problemi. Ma i moderni frontali SPA sono solo una parte della soluzione di velocità del sito e un paio di problemi devono ancora essere affrontati:

  • I benchmark e i test di velocità sintetici non raccontano necessariamente l’intera storia. La velocità di questi framework può variare a seconda delle dimensioni dell’applicazione e delle attività di ottimizzazione.
  • Mentre varie tecnologie frontend all’avanguardia, tra cui app Web progressive, spa e AMP, possono migliorare notevolmente l’esperienza del cliente, la velocità del sito Web è un problema di stack completo. Copre il browser, l’edge e il server. Per questo motivo è necessaria una soluzione full-stack per velocizzare qualsiasi sito Web, SPA e applicazione multipagina.
  • Tutte queste tecnologie possono migliorare la velocità ma funzionano meglio se applicate all’unisono. La compatibilità di tutte queste tecnologie è un’attività complessa che i team interni potrebbero non essere in grado di gestire (ad esempio, è necessario creare un livello Node.js).

Layer0: Rendere il Web immediato e semplice

Layer0 è una soluzione completa per rendere i siti Web di e-commerce più veloci e facili da sviluppare. Combina tecniche di ottimizzazione avanzate per velocizzare i siti Web su larga scala basati su database, come le spa e-commerce, insieme a potenti strumenti che consentono agli sviluppatori di tornare indietro un giorno alla settimana mettendo il codice al centro dei loro flussi di lavoro. Layer0 porta essenzialmente Jamstack a grandi siti di eCommerce.

Instant: Combinando frontends moderni con CDN-as-JavaScript con un tasso di hit cache del 95% per i contenuti dinamici all’edge e un backend-for-frontend Node.js, Layer0 aiuta i siti Web complessi a ottimizzare la velocità su tutto lo stack. È l’unica piattaforma che garantisce tempi mediani inferiori al secondo più grande Content Paint (LCP) per i siti Web di e-commerce su larga scala.

Semplice: Layer0 (ora Edgio) è la piattaforma all-in-one per sviluppare, distribuire, visualizzare in anteprima, sperimentare, monitorare, ed eseguire il frontend che consente di:

  • Utilizza Jamstack per l’eCommerce tramite rendering pre e just-in-time
  • Abilitare il networking a latenza zero tramite il precaricamento dei dati dalle API del catalogo dei prodotti
  • Configurare Edge in modo nativo nell’app (CDN-as-JavaScript)
  • Eseguire le regole del bordo localmente e in fase di pre-produzione
  • Crea URL di anteprima da GitHub, GitLab o Bitbucket con ogni nuova diramazione e push
  • Eseguire le divisioni all’edge per test A/B performanti, implementazioni canary e personalizzazione
  • JavaScript senza server molto più semplice e affidabile di AWS Lambda

Conclusione

Gestire un sito più veloce non è solo un trucco elegante. In fin dei conti, non state solo cercando di stupire i vostri utenti, ma anche cercando di soddisfare il più grande motore di ricerca del mondo. Poiché la classifica di Google sarà presto determinata, in parte, dalla velocità della pagina, non può essere presa alla leggera. Un sito veloce significa incrementare le classifiche SEO e le conversioni, che, a loro volta, generano maggiori entrate.

Anche se si può dire molto sulle prestazioni di ogni framework, ci sono tre punti da ricordare:

  1. Le differenze reali nelle prestazioni del framework possono essere minime. Le prestazioni dei siti SPA dipendono da così tante variabili che è impossibile confrontare questi framework fianco a fianco in modo significativo.
  2. Che tu sia su Angular, Vue o React, c’è ancora molto spazio per il miglioramento.

Rendere più veloci i centri termali richiede una combinazione di tecnologie Web avanzate che lavorano all’unisono e i team interni potrebbero non essere in grado di implementarli in modo efficiente. Per fortuna alcuni fornitori lungimiranti, tra cui Layer0, hanno fatto il lavoro pesante per voi.

Layer0 combina il rendering lato server con il prefetching predittivo avanzato e il pre-caching all’edge. Poiché i dati dinamici vengono memorizzati nella cache per almeno il 95% del tempo, il database è protetto dalle richieste aggiuntive create dal precaricamento. Il service worker Layer0 CDN-as-JavaScript recupera in modo intelligente le pagine dinamiche prima che il visitatore tocchi un collegamento. In questo modo, è possibile fornire caricamenti di pagine inferiori alla seconda su applicazioni a pagina singola, offrendo ai visitatori un’esperienza fluida dall’atterraggio al checkout.