Applicazione a pagina singola
Poiché la SPA è un’evoluzione lontana dal modello di ridisegno delle pagine stateless per cui i browser sono stati originariamente progettati, sono emerse alcune nuove sfide. Le possibili soluzioni (di varia complessità, completezza e controllo dell’autore) includono:
- Librerie JavaScript lato client.
- Framework web lato server specializzati nel modello SPA.
- L’evoluzione dei browser e la specifica HTML5, progettata per il modello SPA.,
Search-engine optimizationEdit
A causa della mancanza di esecuzione di JavaScript sui crawler di alcuni popolari motori di ricerca Web, SEO (Search engine optimization) ha storicamente presentato un problema per i siti Web pubblici che desiderano adottare il modello SPA.
Tra il 2009 e il 2015, Google Webmaster Central ha proposto e quindi raccomandato uno “schema di scansione AJAX” utilizzando un punto esclamativo iniziale negli identificatori di frammenti per le pagine AJAX stateful (#!)., Comportamento speciale deve essere implementato dal sito SPA per consentire l”estrazione dei metadati rilevanti da crawler del motore di ricerca. Per i motori di ricerca che non supportano questo schema di hash URL, gli URL con hash del centro benessere rimangono invisibili. Questi URI “hash-bang” sono stati considerati problematici da un certo numero di scrittori tra cui Jeni Tennison al W3C perché rendono le pagine inaccessibili a coloro che non hanno JavaScript attivato nel proprio browser. Rompono anche le intestazioni del referer HTTP poiché i browser non sono autorizzati a inviare l’identificatore del frammento nell’intestazione del Referer., Nel 2015, Google deprecato loro hash-bang AJAX strisciando proposta.
In alternativa, le applicazioni possono eseguire il rendering del caricamento della prima pagina sul server e dei successivi aggiornamenti della pagina sul client. Questo è tradizionalmente difficile, perché il codice di rendering potrebbe dover essere scritto in una lingua o un framework diverso sul server e nel client. L’utilizzo di modelli senza logica, la compilazione incrociata da una lingua all’altra o l’utilizzo della stessa lingua sul server e sul client possono aiutare ad aumentare la quantità di codice che può essere condiviso.,
Nel 2018, Google ha introdotto il rendering dinamico come un’altra opzione per i siti che desiderano offrire ai crawler una versione pesante non JavaScript di una pagina a scopo di indicizzazione. Il rendering dinamico consente di passare da una versione di una pagina renderizzata lato client a una versione pre-renderizzata per specifici interpreti. Questo approccio prevede che il server Web rilevi i crawler (tramite l’agente utente) e li instrada a un renderer, da cui viene quindi fornita una versione più semplice del contenuto HTML.,
Poiché la compatibilità SEO non è banale nelle SPA, vale la pena notare che le SPA non sono comunemente utilizzate in un contesto in cui l’indicizzazione dei motori di ricerca è un requisito o desiderabile. I casi d’uso includono applicazioni che presentano dati privati nascosti dietro un sistema di autenticazione. Nei casi in cui queste applicazioni sono prodotti di consumo, spesso un classico modello “pagina ridisegnare” viene utilizzato per le applicazioni landing page e sito di marketing, che fornisce abbastanza metadati per l’applicazione di apparire come un colpo in una query del motore di ricerca., Blog, forum di supporto e altri artefatti di ridisegno delle pagine tradizionali spesso siedono intorno alla SPA che può seminare i motori di ricerca con termini pertinenti.
Un altro approccio utilizzato dai framework web server-centrici come l’ItsNat basato su Java è quello di rendere qualsiasi ipertesto sul server utilizzando lo stesso linguaggio e la stessa tecnologia di template. In questo approccio, il server conosce con precisione lo stato DOM sul client, qualsiasi aggiornamento di pagina grande o piccola richiesto viene generato nel server e trasportato da Ajax, il codice JavaScript esatto per portare la pagina client al nuovo stato eseguendo metodi DOM., Gli sviluppatori possono decidere quali stati della pagina devono essere scansionabili dagli spider Web per SEO ed essere in grado di generare lo stato richiesto al momento del caricamento generando HTML semplice anziché JavaScript. Nel caso del framework ItsNat, questo è automatico perché ItsNat mantiene l’albero DOM client nel server come un albero DOM Java W3C; il rendering di questo albero DOM nel server genera HTML semplice al momento del caricamento e azioni DOM JavaScript per le richieste Ajax., Questa dualità è molto importante per SEO perché gli sviluppatori possono costruire con lo stesso codice Java e puro basato su HTML templating lo stato DOM desiderato nel server; al momento del caricamento della pagina, HTML convenzionale è generato da ItsNat rendendo questo stato DOM SEO-compatibile.
A partire dalla versione 1.,3, ItsNat fornisce una nuova modalità stateless, e il client DOM non è mantenuto sul server in quanto, con l’apolide modalità client, DOM è stato parzialmente o completamente ricostruito sul server durante l’elaborazione di qualsiasi richiesta Ajax basata sulla richiesta dati inviati dal client di informare il server di corrente DOM stato; le modalità stateless può essere anche SEO-compatibile perché il SEO di compatibilità accade al momento del caricamento della pagina iniziale influenzato da stateful o apolide, modalità., Un’altra scelta possibile è framework come PreRender, Puppeteer, Rendertron che possono essere facilmente integrati in qualsiasi sito Web come middleware con configurazione del server Web che consente alle richieste bot (Google bot e altri) di essere servite dal middleware mentre le richieste non bot sono servite come al solito. Questi framework memorizzano periodicamente le pagine del sito Web pertinenti per consentire alle versioni più recenti di essere disponibili per i motori di ricerca. Questi framework sono stati ufficialmente approvati da Google.
Ci sono un paio di soluzioni alternative per far sembrare che il sito web sia crawlable., Entrambi implicano la creazione di pagine HTML separate che rispecchiano il contenuto della SPA. Il server potrebbe creare una versione basata su HTML del sito e consegnarlo ai crawler, oppure è possibile utilizzare un browser senza testa come PhantomJS per eseguire l”applicazione JavaScript e l” output HTML risultante.
Entrambi richiedono un po ‘ di sforzo e possono finire per dare un mal di testa di manutenzione per i grandi siti complessi. Ci sono anche potenziali insidie SEO. Se l’HTML generato dal server viene ritenuto troppo diverso dal contenuto SPA, il sito verrà penalizzato., L’esecuzione di PhantomJS per l’output dell’HTML può rallentare la velocità di risposta delle pagine, che è qualcosa per cui i motori di ricerca – Google in particolare – declassano le classifiche.
partitioningEdit codice client/server
Un modo per aumentare la quantità di codice che può essere condiviso tra server e client è quello di utilizzare un linguaggio di template logic-less come Baffi o manubrio. Tali modelli possono essere resi da diverse lingue host, come Ruby sul server e JavaScript nel client., Tuttavia, la semplice condivisione dei modelli richiede in genere la duplicazione della logica di business utilizzata per scegliere i modelli corretti e popolarli con i dati. Il rendering dai modelli può avere effetti negativi sulle prestazioni quando si aggiorna solo una piccola parte della pagina, ad esempio il valore di un input di testo all’interno di un modello di grandi dimensioni. La sostituzione di un intero modello potrebbe anche disturbare la selezione di un utente o la posizione del cursore, dove l ” aggiornamento solo il valore modificato potrebbe non., Per evitare questi problemi, le applicazioni possono utilizzare i binding dei dati dell’interfaccia utente o la manipolazione DOM granulare per aggiornare solo le parti appropriate della pagina invece di eseguire nuovamente il rendering di interi modelli.
Cronologia del browserEdit
Con una SPA che è, per definizione, “una singola pagina”, il modello interrompe il design del browser per la navigazione della cronologia delle pagine utilizzando i pulsanti”avanti “o” indietro”., Questo presenta un impedimento di usabilità quando un utente preme il pulsante indietro, aspettandosi lo stato dello schermo precedente all”interno della SPA, ma invece, singola pagina dell”applicazione scarica e la pagina precedente nella storia del browser è presentato.
La soluzione tradizionale per le SPA è stata quella di modificare l’identificatore del frammento di hash dell’URL del browser in accordo con lo stato corrente dello schermo. Questo può essere ottenuto con JavaScript e fa sì che gli eventi della cronologia URL vengano compilati all’interno del browser., Finché la SPA è in grado di resuscitare lo stesso stato dello schermo dalle informazioni contenute nell’hash URL, viene mantenuto il comportamento del pulsante indietro previsto.
Per risolvere ulteriormente questo problema, la specifica HTML5 ha introdotto pushState e replaceState che forniscono l’accesso programmatico all’URL effettivo e alla cronologia del browser.
AnalyticsEdit
Gli strumenti di analisi come Google Analytics si basano pesantemente sul caricamento di intere nuove pagine nel browser, avviato da un nuovo caricamento della pagina. Le TERME non funzionano in questo modo.,
Dopo il caricamento della prima pagina, tutte le successive modifiche di pagina e contenuto vengono gestite internamente dall’applicazione, che dovrebbe semplicemente chiamare una funzione per aggiornare il pacchetto Analytics. Non riuscendo a chiamare detta funzione, il browser non innesca mai un nuovo caricamento della pagina, nulla viene aggiunto alla cronologia del browser e il pacchetto Analytics non ha idea di chi stia facendo cosa sul sito.
Aggiunta di carichi di pagina a un SPAEdit
È possibile aggiungere eventi di caricamento della pagina a un centro benessere utilizzando l’API cronologia HTML5; questo aiuterà a integrare analytics., La difficoltà viene nella gestione di questo e garantire che tutto viene monitorato con precisione-questo comporta il controllo per i rapporti mancanti e doppie voci.Alcuni framework forniscono integrazioni di analisi open source indirizzate alla maggior parte dei principali provider di analisi. Gli sviluppatori possono integrarli nell’applicazione e assicurarsi che tutto funzioni correttamente, ma non è necessario fare tutto da zero.
Velocità di caricamento inizialeedit
Le applicazioni a pagina singola hanno un caricamento della prima pagina più lento rispetto alle applicazioni basate su server., Questo perché il primo carico deve abbattere il framework e il codice dell’applicazione prima di rendere la vista richiesta come HTML nel browser. Un’applicazione basata su server deve solo spingere l’HTML richiesto al browser, riducendo la latenza e il tempo di download.
Accelerare il caricamento della pagineedit
Ci sono alcuni modi per accelerare il carico iniziale di una SPA, come un approccio pesante al caching e ai moduli di caricamento pigro quando necessario., Ma non è possibile allontanarsi dal fatto che ha bisogno di scaricare il quadro, almeno una parte del codice dell “applicazione, e molto probabilmente ha colpito un” API per i dati prima di visualizzare qualcosa nel browser. Questo è uno scenario di trade-off “pay me now, or pay me later”. La questione delle prestazioni e dei tempi di attesa rimane una decisione che lo sviluppatore deve prendere.