Applicazioni web progressive in siti multiorigine

Sfide e soluzioni alternative per la creazione di app web progressive in siti con più origini.

Demián Renzulli

Data di pubblicazione: 19 agosto 2019

In passato, l'utilizzo di architetture multi-origine offriva alcuni vantaggi. Per le app web progressive, questo approccio presenta molte sfide. In particolare, la policy 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.

Scopri gli utilizzi corretti e non corretti di più origini e spiega le sfide e le soluzioni alternative per la creazione di app web progressive in siti con più origini.

Usi corretti e non corretti di più origini

Esistono alcuni motivi legittimi per cui i siti utilizzano un'architettura multi-origine, per lo più legati alla fornitura di un insieme indipendente di applicazioni web o alla creazione di esperienze completamente isolate l'una dall'altra. Esistono anche utilizzi che dovrebbero essere evitati.

Il buono

Dai un'occhiata ai motivi utili:

• Localizzazione/Lingua: l'utilizzo di un dominio di primo livello nazionale per separare i siti da pubblicare in paesi diversi (ad es. https://www.google.com.ar) o l'utilizzo di sottodomini per dividere i siti scelti come target per località diverse (ad es. https://newyork.craigslist.org) o per offrire contenuti per una lingua specifica (ad es. https://en.wikipedia.org).

• App web indipendenti: utilizzo di sottodomini diversi per fornire esperienze il cui scopo differisce notevolmente dal sito nell'origine principale. Ad esempio, in un sito di notizie, l'app web dei cruciverba 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 stai facendo nessuna di queste cose, è probabile che l'utilizzo di un'architettura multi-origine sia 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 di "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 fortemente sconsigliati:

• Sezioni del sito: separazione di diverse sezioni di un sito in sottodomini. Nei siti di notizie, non è raro vedere la home page all'indirizzo https://www.example.com, mentre la sezione sportiva si trova all'indirizzo https://sports.example.com, la politica all'indirizzo https://politics.example.com e così via. Nel caso di un sito di e-commerce, utilizza ad esempio https://category.example.com per le categorie di prodotto, https://product.example.com per le pagine di prodotto e così via.

• Flusso utente: un altro approccio sconsigliato è quello di separare diverse parti più piccole del sito, come le pagine per i flussi di accesso o di acquisto nei sottodomini. Ad esempio, utilizzando https://login.example.com e https://checkout.example.com.

Nota: quando crei un sito da zero, ti consigliamo vivamente di evitare di suddividerlo in sottodomini. Per i siti esistenti, l'approccio migliore è la migrazione a un'origine singola.

Per i casi in cui non è possibile eseguire la migrazione a un'unica origine, di seguito è riportato un elenco di problemi e, ove possibile, di soluzioni alternative che possono essere prese in considerazione durante la creazione di app web progressive.

Sfide e soluzioni alternative per le PWA su origini diverse

Quando si crea un sito web su più origini, fornire un'esperienza PWA unificata è difficile, soprattutto a causa della policy della stessa origine, che impone una serie di vincoli. Vediamoli uno alla volta.

Service worker

L'origine dell'URL dello script del service worker deve essere la stessa dell'origine della pagina che chiama register(). Ciò significa che, ad esempio, una pagina all'indirizzo https://www.example.com non può chiamare register() con un URL del service worker all'indirizzo 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 all'indirizzo https://www.example.com, può controllare solo gli URL di quell'origine (in base al percorso definito nel parametro scope), ma non controllerà 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).

Attenzione: la registrazione e la presenza di più service worker attivi consumano risorse aggiuntive (memoria, CPU e così via), quindi valuta attentamente il numero di service worker attivi di cui un utente avrà probabilmente bisogno per navigare nel sito.

Memorizzazione nella cache

Anche l'oggetto Cache, indexedDB e localStorage sono limitati a un'unica 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 l'ulteriore vantaggio di riutilizzare le risorse memorizzate nella cache tra le origini, cosa che non è possibile fare 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 leggera l'installazione dei service worker: se gestisci più service worker, evita di far pagare agli utenti un costo di installazione elevato ogni volta che navigano verso una nuova origine. In altre parole, pre-memorizza nella cache solo le risorse assolutamente necessarie.

Una volta che il service worker è attivo e in esecuzione, il criterio della stessa origine limita anche le richieste multiorigine effettuate all'interno dei service worker. Fortunatamente, esiste una soluzione alternativa consigliata, ovvero l'utilizzo di CORS (come spiegato qui). Non è consigliabile utilizzare la modalità no-cors durante il recupero delle risorse all'interno del service worker.

Autorizzazioni

Anche le autorizzazioni hanno come ambito le 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 origini, l'unica soluzione è chiedere 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 stessa. Ciò significa che un utente che riceve la richiesta di installazione su un'origine specifica (ad es. https://section.example.com) non potrà installare la PWA con un start_url su un'altra origine (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.

C'è anche il problema che lo stesso utente potrebbe ricevere più richieste di installazione durante la navigazione nel sito, se ogni sottodominio soddisfa i criteri di installazione e chiede all'utente di installare la PWA.

Per mitigare questo problema, puoi assicurarti che la richiesta venga mostrata solo nell'origine principale. Quando un utente visita un sottodominio che soddisfa i criteri di installazione:

1. Ascolta l'evento beforeinstallprompt.
2. Impedire la visualizzazione della richiesta, chiamando event.preventDefault().

In questo modo, ti assicuri che il prompt non venga mostrato in parti del sito non previste, mentre puoi continuare a mostrarlo, ad esempio, nell'origine principale (ad es. la home page).

Modalità autonoma

Durante la navigazione in una finestra autonoma, il browser si comporterà in modo diverso quando l'utente esce dall'ambito impostato dal manifest della PWA. Il comportamento dipende dalla versione e dal fornitore di ciascun 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 workflow di accesso):

1. Il nuovo URL, https://login.example.com, potrebbe aprirsi all'interno di un iframe a schermo intero.
2. Una volta completata l'attività all'interno dell'iframe (ad esempio, la procedura di accesso), è possibile utilizzare postMessage() per trasmettere le informazioni risultanti dall'iframe alla pagina principale.
3. Come passaggio finale, una volta che il messaggio viene ricevuto dalla pagina principale, è possibile annullare la registrazione dei listener e infine rimuovere l'iframe dal DOM.

Attenzione: la tecnica precedente può aiutare a mitigare la potenziale modifica della UI in una piccola parte del sito, dove l'utente può eseguire un'azione in un sottodominio e tornare all'origine principale (come in un flusso di accesso), ma non sarà una tecnica efficiente da implementare per interi percorsi, incluse molte pagine ospitate in sottodomini (come intere sezioni del sito).

Nota: nel contesto delle Trusted Web Activity, esiste un modo consigliato per evitare questo problema, ovvero convalidare tutte le origini utilizzando Digital Asset Links.

Conclusione

La policy della stessa origine 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à creati 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 un nuovo design del sito, valuta la possibilità di eseguire la migrazione a un'origine singola, a meno che non esista un motivo importante per mantenere l'architettura con più origini.

Ringraziamo per le revisioni tecniche e i suggerimenti: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle e Andre Bandarra.