Problemi e soluzioni alternative per la creazione di app web progressive in siti con più origini.
Sfondo
In passato, l'utilizzo di architetture multi-origine presentava alcuni vantaggi, ma per le Progressive Web App questo approccio presenta molte sfide. In particolare, il criterio della stessa origine impone limitazioni per la condivisione di elementi come service worker e cache, autorizzazioni e per ottenere un'esperienza autonoma su più origini. Questo articolo descrive gli usi positivi e negativi di più origini e spiega le sfide e le soluzioni alternative per la creazione di app web progressive in siti con più origini.
Utilizzi positivi e negativi di più origini
Esistono alcuni motivi legittimi per cui i siti utilizzano un'architettura multi-origine, principalmente per fornire un insieme indipendente di applicazioni web o per creare esperienze completamente isolate l'una dall'altra. Esistono anche utilizzi che devono essere evitati.
Il buono
Vediamo prima i motivi utili:
Localizzazione / lingua: utilizza un dominio di primo livello con codice paese per separare i siti da pubblicare in paesi diversi (ad es.
https://www.google.com.ar) o utilizza sottodomini per suddividere i siti scelti come target in località diverse (ad es.https://newyork.craigslist.org) o per offrire contenuti in una lingua specifica (ad es.https://en.wikipedia.org).Web app indipendenti:utilizza sottodomini diversi per offrire esperienze il cui scopo è molto diverso da quello del sito nell'origine principale. Ad esempio, in un sito di notizie, la web app di parole crociate potrebbe essere pubblicata intenzionalmente da
https://crosswords.example.com, installata e utilizzata come PWA indipendente, senza dover condividere risorse o funzionalità con il sito web principale.
Aspetti negativi
Se non esegui nessuna di queste operazioni, è probabile che l'utilizzo di un'architettura multi-origine rappresenti uno svantaggio durante la creazione di app web progressive.
Nonostante ciò, molti siti continuano a essere strutturati in questo modo senza un motivo particolare o per motivi "legacy". Un esempio è l'utilizzo di sottodomini per separare arbitrariamente parti di un sito che dovrebbero far parte di un'esperienza unificata.
Ad esempio, i seguenti pattern sono sconsigliati:
Sezioni del sito:separazione delle diverse sezioni di un sito in sottodomini. Nei siti di notizie, non è raro trovare la home page all'indirizzo
https://www.example.com, mentre la sezione sportiva è all'indirizzohttps://sports.example.com, quella politica all'indirizzohttps://politics.example.come così via. Nel caso di un sito di e-commerce, puoi utilizzare ad esempiohttps://category.example.comper le categorie di prodotti,https://product.example.comper le pagine dei prodotti e così via.Flusso utente:un altro approccio sconsigliato è separare parti diverse e più piccole del sito, ad esempio le pagine per i flussi di accesso o di acquisto nei sottodomini. Ad esempio, utilizzando
https://login.example.comehttps://checkout.example.com.
Nei casi in cui non sia possibile eseguire la migrazione a una singola origine, di seguito è riportato un elenco di problemi e (se possibile) soluzioni alternative che possono essere prese in considerazione durante la creazione di app web progressive.
Problemi e soluzioni alternative per le PWA in origini diverse
Quando si crea un sito web su più origini, fornire un'esperienza PWA unificata è complicato, soprattutto a causa del rispetto delle norme relative alla stessa origine, che impone una serie di vincoli. Vediamole una alla volta.
Service worker
L'origine dell'URL dello script del worker del servizio deve essere la stessa dell'origine della pagina che chiama register(). Ciò significa che, ad esempio, una pagina all'URL https://www.example.com non può chiamare register() con un URL del worker del servizio all'URL https://section.example.com.
Un'altra considerazione è che un service worker può controllare solo le pagine ospitate nell'origine e nel percorso a cui appartiene. Ciò significa che, se il service worker è ospitato su https://www.example.com, può controllare solo gli URL di quell'origine (in base al percorso definito nel parametro scope), ma non controlla nessuna pagina in altri sottodomini, ad esempio quelli in https://section.example.com.
In questo caso, l'unica soluzione alternativa è utilizzare più service worker (uno per origine).
Memorizzazione nella cache
Anche l'oggetto Cache, IndexedDB e localStorage sono limitati a una singola origine. Ciò significa che non è possibile accedere alle cache appartenenti a https://www.example.com, ad esempio da https://www.section.example.com.
Ecco alcune cose che puoi fare per gestire correttamente le cache in scenari come questo:
Sfrutta la memorizzazione nella cache del browser:è sempre consigliabile utilizzare le best practice tradizionali per la memorizzazione nella cache del browser. Questa tecnica offre il vantaggio aggiuntivo di riutilizzare le risorse memorizzate nella cache tra le origini, il che non è possibile con la cache del service worker. Per le best practice su come utilizzare la cache HTTP con i service worker, puoi dare un'occhiata a questo post.
Mantieni l'installazione dei worker di servizio leggera:se gestisci più worker di servizio, evita di far pagare agli utenti un costo di installazione elevato ogni volta che passano a una nuova origine. In altre parole, pre-cache solo le risorse assolutamente necessarie.
Autorizzazioni
Le autorizzazioni sono limitate anche alle origini. Ciò significa che se un utente ha concesso una determinata autorizzazione all'origine https://section.example.com, questa non verrà trasferita ad altre origini, come https://www.example.com.
Poiché non è possibile condividere le autorizzazioni tra le origini, l'unica soluzione è richiedere l'autorizzazione per ogni sottodominio in cui è richiesta una determinata funzionalità (ad es. la posizione). Per elementi come le notifiche push web, puoi mantenere un cookie per monitorare se l'autorizzazione è stata accettata dall'utente in un altro sottodominio, in modo da evitare di richiederla di nuovo.
Installazione
Per installare una PWA, ogni origine deve avere il proprio manifest con un start_url relativo a se stesso. Ciò significa che un utente che riceve la richiesta di installazione su una determinata origine (ad es.https://section.example.com) non potrà installare la PWA con un start_url su un'altra (ad es.https://www.example.com).
In altre parole, gli utenti che ricevono la richiesta di installazione in un sottodominio potranno installare le PWA solo per le pagine secondarie, non per l'URL principale dell'app.
Inoltre, lo stesso utente potrebbe ricevere più richieste di installazione durante la navigazione sul sito, se ogni sottodominio soddisfa i criteri di installazione, e gli viene chiesto di installare la PWA.
Per risolvere il problema, puoi assicurarti che la richiesta venga visualizzata solo nell'origine principale. Quando un utente visita un sottodominio che soddisfa i criteri di installazione:
- Ascolta l'evento
beforeinstallprompt. - Impedisci la visualizzazione della richiesta chiamando
event.preventDefault().
In questo modo, ti assicuri che la richiesta non venga visualizzata in parti non previste del sito, mentre puoi continuare a mostrarla, ad esempio, nell'origine principale (ad es. home page).
Modalità autonoma
Durante la navigazione in una finestra autonoma, il browser si comporta in modo diverso quando l'utente esce dall'ambito impostato dal manifest della PWA. Il comportamento dipende dalla versione e dal fornitore del browser. Ad esempio, le ultime versioni di Chrome aprono una scheda personalizzata di Chrome quando un utente esce dall'ambito in modalità autonoma.
Nella maggior parte dei casi, non esiste una soluzione, ma è possibile applicare una soluzione alternativa per piccole parti dell'esperienza ospitate in sottodomini (ad esempio i flussi di lavoro di accesso):
- Il nuovo URL,
https://login.example.com, potrebbe aprirsi all'interno di un iframe a schermo intero. - Una volta completata l'attività all'interno dell'iframe (ad esempio la procedura di accesso), puoi utilizzare postMessage() per ritrasmettere le informazioni risultanti dall'iframe alla pagina principale.
- Come ultimo passaggio, una volta che il messaggio è stato ricevuto dalla pagina principale, gli ascoltatori possono essere annullati e l'iframe può essere rimosso dal DOM.
Conclusione
Il criterio di origine stessa impone molte limitazioni ai siti basati su più origini che vogliono ottenere un'esperienza PWA coerente. Per questo motivo, per offrire la migliore esperienza agli utenti, sconsigliamo vivamente di suddividere i siti in origini diverse.
Per i siti esistenti già costruiti in questo modo, può essere difficile far funzionare correttamente le PWA multi-origine, ma abbiamo esplorato alcune potenziali soluzioni alternative. Ognuno può comportare dei compromessi, quindi usa il tuo giudizio per decidere quale approccio adottare sul tuo sito web.
Quando valuti una strategia a lungo termine o il redesign del sito, valuta la possibilità di eseguire la migrazione a un'unica origine, a meno che non esista un motivo importante per mantenere l'architettura multi-origine.
Un ringraziamento speciale per le revisioni e i suggerimenti tecnici a Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle e Andre Bandarra.