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 eCommerce in esecuzione su questi framework frontend per la migliore esperienza utente.
Come si confrontano Angular, React e Vue in termini di prestazioni
La gestione rapida di un sito porta a una crescita dei profitti grazie a un posizionamento SEO migliore, un maggior numero di visitatori, sessioni più lunghe e, di conseguenza, maggiori ricavi. Molti leader dell’e-commerce che comprendono il ruolo della velocità si sono già spostati verso un’architettura di commercio senza testa, consentendo l’adozione di frontend moderni, come app Web progressive e spa. I frontend SPA leggeri stanno acquisendo 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 fornire vetrine super veloci.
Beh, questa è la teoria. Per verificare queste elevate affermazioni, abbiamo eseguito una piccola analisi interna delle prestazioni. 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 frontend SPA testati è stato solo 24, con una media di 19 (su 100)! Per quanto possa sembrare basso, questo è stato ancora del 26% superiore al punteggio medio dei 500 principali retailer online statunitensi in termini di ricavi.
I siti Vue.js sono stati i più veloci, con un punteggio medio di 27 con una mediana di 20. I siti web angolari hanno visto una media di 23; tuttavia, i loro punteggi di performance erano più disparati, con una media di soli 18. I siti web di 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 migliorare. Inoltre, Google Crux e altri strumenti di misurazione non tengono traccia delle transizioni di pagina delle applicazioni a pagina singola (SPA), travisando le pagine 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 di 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, ossia il codice app e il codice framework combinati. Le prestazioni di runtime dipendono dalle specifiche funzioni 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 di dimensioni simili e minimi. Sebbene la dimensione del pacchetto del framework influisca sul tempo di avvio, la metrica non dovrebbe essere l’obiettivo principale quando si confrontano le prestazioni di Angular, React e Vue.
In termini più precisi, le dimensioni del pacchetto Angular sono leggermente più grandi di quelle dei pacchetti Vue e React, mentre i pacchetti Vue sono leggermente più piccoli dei pacchetti React. Inoltre, vale la pena notare che il team di sviluppo Angular sta ottimizzando costantemente le dimensioni dei pacchetti di codice (sorgente).
Vedere la tabella seguente per i numeri approssimativi.
Le metriche TTI e LCP di Lighthouse
Lighthouse è un ottimo strumento di test che fornisce preziose informazioni sulla velocità. Identifica i possibili problemi di performance e aiuta a ottimizzare i vari aspetti di un sito. Il punteggio di un faro viene calcolato in base a una media ponderata di più metriche (fare clic qui per un riepilogo completo). Tuttavia, i più grandi Contentful Paint (LCP), Time to Interactive (TTI) e Cumulative Layout Shift (CLS) sono molto probabilmente i più importanti dal punto di vista dell’utente. TTI e LCP sono collegati direttamente alla velocità di carico percepita. La TTI è una buona rappresentazione dell’impatto delle dimensioni del pacchetto di un quadro sulla velocità della SPA, in quanto il pacchetto deve essere valutato interamente prima che l’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, invece, misura il tempo necessario affinché l’elemento più grande del contenuto della pagina venga visualizzato sullo schermo.Lighthouse vs. Crux dati di navigazione reali
Vale la pena notare che gli strumenti sintetici di misurazione della velocità (come Lighthouse) non raccontano tutta la storia. La velocità del sito è più che altro su come il sito “si sente” quando gli utenti lo navigano. Un punteggio delle prestazioni di Lighthouse è un buon punto di riferimento, ma è un po’ arbitrario e difficile da correlare a un’esperienza del mondo reale. Ad esempio, è difficile tradurre quanto meglio sarebbe un punteggio di performance 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 anche 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, il caricamento pigro) che ogni framework utilizza per migliorare la velocità con cui il sito “si sente” per gli utenti. Nelle prossime sezioni, esamineremo le opportunità offerte da ciascuno di questi framework per migliorare le prestazioni del sito Web.Angolare
Angular estende il codice HTML con nuovi tag e attributi e interpreta gli attributi per eseguire l’associazione dei dati. Grazie alle sue funzionalità avanzate, l’applicazione funzionante potrebbe essere molto più grande (circa 500 KB) rispetto a Vue o React, con un impatto lieve sulle prestazioni.
Astrazione MVC di angular (fonte)
Ecco un breve riepilogo dei principali vantaggi di Angular.
- Generazione del codice. Angular genera codice altamente ottimizzato per le macchine virtuali JavaScript, offrendo i vantaggi del codice scritto a mano. I modelli HTML combinati con JavaScript aprono le porte a impossibili ottimizzazioni in altri framework, ad esempio React.
- Suddivisione del codice. Grazie a Component router, le applicazioni Angular si caricano rapidamente, offrendo la suddivisione automatica del codice. In questo modo, gli utenti caricano il codice necessario per eseguire il rendering della visualizzazione richiesta.
- DOM reale. Angular utilizza il DOM reale; pertanto, è più adatto per applicazioni a pagina singola in cui i contenuti vengono aggiornati solo di volta in volta, non quelli che cambiano di frequente, come la maggior parte dei siti di e-commerce. La manipolazione del DOM virtuale è molto più veloce perché non viene disegnato nulla sullo schermo.
Reagire
Creato e sviluppato da Facebook, React è uno dei framework di applicazioni mobili open source più diffusi. 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 nidificare i componenti figlio all’interno di componenti padre di ordine superiore.
React offre alcune funzioni interessanti, tra cui:
- DOM virtuale: I nodi vengono ri-rendering solo se necessario. React confronta i nuovi dati con il DOM originale e aggiorna automaticamente la vista. Ciò migliora le prestazioni delle applicazioni di tutte le dimensioni che richiedono aggiornamenti regolari dei contenuti.
- Associazione dati unidirezionale: React utilizza l’associazione dati unidirezionale con l’architettura dell’applicazione controlli flusso. ReactJS aiuta ad aggiornare la visualizzazione per l’utente e Flux controlla il flusso di lavoro dell’applicazione. Virtual DOM aggiunge vantaggi in quanto confronta i nuovi dati con il DOM originale e aggiorna automaticamente la vista.
- Supporto per il raggruppamento e il Tree-Shaking: Riduce al minimo il carico di risorse dell’utente finale.
- Supporto di rendering lato server (SSR): Offre vantaggi in termini di velocità in implementazioni specifiche.
“In misura maggiore rispetto a Angular e Vue, React utilizza determinate tecniche che rendono la pagina “più veloce” per gli utenti finali.” Ad esempio, il framework assegna la priorità all’input dell’utente rispetto al rendering del contenuto sulla pagina.
Vista
Vue è veloce e molto piccolo, con soli 30 KB (gzip), il che si traduce in un caricamento più rapido dei primi caricamenti. Questo lo rende il più piccolo di tutti e tre i framework e accelera notevolmente le prestazioni dei siti Web in esecuzione su Vue.
Vue offre:
- Rendering lato server (SSR)
- Scuotimento dell’albero
- Impacchettamento
- DOM virtuale: Le modifiche all’interno di un progetto non influenzano correttamente il DOM. La modifica del DOM reale è un’attività che richiede molte risorse, pertanto gli aggiornamenti vengono applicati prima al DOM virtuale.
Consultate questo report dettagliato di benchmark per confrontare i tempi di avvio, l’allocazione della memoria e la durata di operazioni specifiche tra i framework e le librerie JavaScript leader del settore. 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 figlio.
Ottimizzazione Vue vs. React vs. 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. Di seguito sono riportate alcune idee per ottimizzare la velocità di Vue, React e Angular Spa.
1. Rendering lato server (SSR)
Nel complesso, 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 immediatamente con esso). Senza SSR, gli utenti guardavano una schermata vuota, in attesa del caricamento e del rendering del contenuto 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 prima. Ma il vantaggio di utilizzare SSR è che molti altri motori di ricerca ancora non capiscono JavaScript e non riescono a eseguire correttamente la scansione dei siti ad alto contenuto di JavaScript.
- I social network spesso non sono in grado di visualizzare correttamente i contenuti condivisi dai siti SPA sottoposti a rendering client. Ad esempio, il raschiatore Facebook si basa solo sui meta tag impostati dal server e non funziona con i meta tag con rendering lato client. Per controllare meglio l’aspetto del sito SPA quando viene condiviso tramite Open Graph, SSR è un must.
- AMP accelera i primi caricamenti sui dispositivi mobili ma non ti consente di utilizzare JavaScript. È impossibile eseguire il rendering di AMP da React sul client, deve essere fatto sul server. Tuttavia, anche con SSR in atto, 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 di eCommerce SPA sono ancora memorizzabili nella cache, con l’infrastruttura giusta. Con Layer0, il contenuto viene eseguito sul lato server mobile e quindi memorizzato nella cache all’edge con il nostro CDN-as-JavaScript. In questo modo, i siti Web su larga scala basati su database, come le SPA di eCommerce con migliaia, se non milioni di pagine, la personalizzazione, l’inventario in tempo reale e altro ancora, possono soddisfare gli utenti con carichi di pagine di secondo, dall’arrivo 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à.
La rete Layer0 e gli strumenti di monitoraggio garantiscono che i dati dinamici vengano memorizzati nella cache almeno il 95% delle volte, proteggendo il database dalle richieste aggiuntive create dal precaricamento. In questo modo, puoi fornire caricamenti di pagine di secondo, offrendo ai tuoi visitatori un’esperienza fluida dall’atterraggio fino al pagamento.
Rete Layer0 e strumenti di monitoraggio
In generale, per quanto riguarda le funzionalità SSR e la documentazione dettagliata, Vue è superiore a React, che richiede librerie di terze parti (ad esempio Next.js) per eseguire il rendering delle pagine sul lato server.
2. AMP
AMP crea esperienze migliori e più veloci sul Web mobile semplificando l’HTML e applicando severe limitazioni a CSS e JavaScript. Queste pagine vengono quindi memorizzate nella cache e pre-rendering sul server Google, rendendo 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 caricamenti mediani di 500 ms per il traffico proveniente dal SERP di Google. Queste velocità sono possibili perché i server Google precaricano e prerender contenuti AMP nel browser di un utente prima di fare clic sul collegamento della pagina AMP. Il sito di e-commerce medio ottiene una grande fetta del suo traffico dalla ricerca di Google (sia organica che a pagamento), quindi questi guadagni possono avere un impatto enorme.
Anche i siti che utilizzano AMP sono soggetti a tassi di rimbalzo ridotti, in quanto gli utenti che in genere rimbalzano in attesa del caricamento di una pagina ora avranno un’esperienza estremamente veloce.
3. Suddivisione del codice
L’applicazione a pagina singola crescerà nel tempo man mano che si continuano ad aggiungere funzioni. Ma sappiamo che ogni applicazione ha alcune funzioni che non vengono utilizzate quasi mai e che rallentano inutilmente. È necessario implementare la suddivisione del codice per mantenere l’app il più rapidamente possibile.
La suddivisione del codice implica la creazione di bundle separati per ciascun componente di primo livello nell’app. Nel caso di una SPA eCommerce, 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 collegamento a un prodotto specifico, il browser non deve scaricare ed eseguire il codice per tutte le pagine precedenti, riducendo così i tempi di TTI e FID.
“Con la suddivisione del codice, l’app può “caricare” altri componenti della pagina in background e utilizzarli se l’utente decide di spostarli.” Ciò consente di risparmiare larghezza di banda e di ridurre il ritardo del primo input o FID (nota: Il FID è spesso approssimato dal tempo alla 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 tutti il caricamento lento, che, in combinazione con SSR, può fornire miglioramenti significativi in termini di velocità.
Il caricamento lento rappresenta una sfida quando si implementa SSR. Il server deve sapere quali componenti sono stati utilizzati per eseguire 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à FID (e TTI), il che potrebbe portare a contenuti flash o jank.
Caricamento lento e SSR collegati. La libreria scelta per il caricamento lento (ad esempio, React loadable) influenzerà il modo in cui si genera l’HTML finale inviato 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> nel 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 client di caricamento lento non sono ancora supportati a livello globale da tutti i browser, esistono un paio di soluzioni alternative per implementare senza problemi il caricamento lento.
Soluzione n. 1
Invece di eseguire il rendering delle immagini sul lato server, è possibile farle popolare sul lato client quando l’app viene montata.
Soluzione n. 2
“Utilizzare il caricamento lento solo per le immagini “sotto la piega”, ovvero quelle che si conoscono non saranno visibili subito 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 della categoria eCommerce, è possibile disattivare il caricamento lento per la prima serie di immagini del prodotto (probabilmente sono “sopra la piega”). Inoltre, per gli articoli che conoscete saranno sempre al di sopra della piega (ad esempio, intestazioni, logo aziendali, icone del carrello), non dovete comunque abilitare il carico pigro e potete sempre renderli lato server.
Soluzione n. 3
Il rilevamento dell’agente utente può aiutare a fornire una versione appropriata della pagina con rendering SSR. Il rilevamento dell’agente utente non è generalmente consigliato per l’implementazione di miglioramenti progressivi, ma esegue il trucco come soluzione temporanea mentre i browser recuperano e implementano suggerimenti client.
Questa soluzione richiede che le chiavi della cache vengano normalizzate in modo appropriato; in caso contrario, la cache potrebbe essere frammentata in modo significativo.
5. CDN moderno
L’ottimizzazione della SPA per la velocità e l’utilizzo di una CDN di buona qualità miglioreranno il tuo sito, ma non è sufficiente per raggiungere velocità inferiori a 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 di eCommerce SPA. Rendere questi siti più veloci richiede che diverse tecnologie web funzionino in modo efficiente all’unisono. A differenza di altre CDN, la CDN basata sulle applicazioni Layer0 funziona bene con le SPA di eCommerce. Ottimizza i rapporti di hit della cache a livelli mai visti e porta l’intelligenza all’edge. Ciò aiuta i proprietari di aziende a decifrare le tendenze e le opportunità di ottimizzazione classificando pagine simili come tali (ad esempio PDP, PLP e carrello) invece di visualizzare un elenco infinito di URL. In questo modo è possibile agire e vedere una differenza nei tempi di caricamento del sito Web.
Ma soprattutto, CDN-as-JavaScript utilizza tecniche avanzate di prefetching predittivo per trasmettere i dati memorizzati nella cache dall’edge della rete ai browser degli utenti prima che tocchino qualsiasi cosa. In questo modo, i siti Web vengono mantenuti 5 secondi prima dei tocchi degli acquirenti, consentendo loro di deliziare gli utenti con un’esperienza di navigazione istantanea.
6. Utensili 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 quali l’associazione dei dati, l’iniezione delle 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 React-like. Ciò significa che gli sviluppatori possono creare widget nativi al 100% che controllano il proprio stile. Il framework gestisce il livello View come output di stato puro, semplificando la creazione di app complementari per iOS/Android con un aspetto e prestazioni nativo.
Sebbene Vue sia in ritardo rispetto a React, offre comunque diverse soluzioni utili per lo sviluppo mobile. Ad esempio, NativeScript consente di scrivere applicazioni Vue e compilarle in applicazioni iOS/Android native.
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 presentano 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 porta a un’esperienza di navigazione più veloce e senza intoppi. Ma i frontend SPA moderni sono solo una parte della soluzione di velocità del sito, e un paio di problemi devono ancora essere affrontati:
- I benchmark di velocità sintetici e i test non raccontano necessariamente tutta la 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, centri benessere e AMP, possono migliorare notevolmente l’esperienza del cliente, la velocità del sito Web è un problema completo. Si estende su browser, edge e 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. Far funzionare tutte queste tecnologie è un’attività complessa che i team interni potrebbero non essere in grado di gestire (ad esempio, richiede la creazione di un livello Node.js).
Layer0: Rendere il Web istantaneo e semplice
Layer0 è una soluzione completa per rendere i siti Web di e-commerce veloci e facili da sviluppare. Combina tecniche di ottimizzazione avanzate per velocizzare siti Web su larga scala basati su database, come le SPA di eCommerce, insieme a potenti strumenti che consentono agli sviluppatori di tornare un giorno alla settimana mettendo il codice al centro dei flussi di lavoro. Layer0 porta essenzialmente Jamstack su grandi siti di e-commerce.
Instant: Combinando frontend moderni con un CDN-as-JavaScript con un tasso di hit della cache del 95% per contenuti dinamici all’edge della rete e un backend Node.js per frontend, Layer0 aiuta i siti Web complessi a ottimizzare la velocità in tutto lo stack. È l’unica piattaforma che garantisce tempi mediani inferiori al secondo per la creazione di contenuti più grandi (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:
- Utilizzare Jamstack per l’e-commerce 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 edge localmente e in pre-prod
- Crea URL di anteprima da GitHub, GitLab o Bitbucket con ogni nuova diramazione e push
- Eseguire splits all’edge della rete 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 una gimmick elegante. In fin dei conti, non stai solo cercando di stupire i tuoi utenti, ma stai 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.
Sebbene si possa dire molto sulle prestazioni di ciascun framework, ci sono tre punti da ricordare:
- 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.
- Che tu sia su Angular, Vue o React, c’è ancora molto spazio per il miglioramento.
Per velocizzare i centri benessere è necessaria una combinazione di tecnologie Web avanzate che funzionano all’unisono e i team interni potrebbero non essere in grado di implementarli in modo efficiente. Per fortuna alcuni fornitori all’avanguardia, tra cui Layer0, hanno fatto il lavoro pesante per voi.
Layer0 combina il rendering lato server con il pre-caricamento predittivo avanzato e il pre-caching all’edge della rete. Poiché i dati dinamici vengono memorizzati nella cache almeno il 95% delle volte, il database è protetto dalle richieste aggiuntive create mediante il precaricamento. Il service worker di 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 di sottosecondo su applicazioni a pagina singola, offrendo ai visitatori un’esperienza fluida dall’arrivo alla cassa.
