Sfide e soluzioni alternative per la creazione di app web progressive in siti multiorigine.
Contesto
In passato, l'utilizzo di architetture multiorigine presentava alcuni vantaggi, ma per le app web progressive, questo approccio presenta molte sfide. In particolare, il criterio della stessa origine impone limitazioni per la condivisione, ad esempio, di 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 multi-origine.
Utilizzi positivi e non corretti di più origini
Esistono alcuni motivi legittimi per cui i siti utilizzano un'architettura multiorigine, per lo più correlata al fornire un insieme indipendente di applicazioni web o alla creazione di esperienze completamente isolate tra loro. Ci sono anche utilizzi che dovrebbero essere evitati.
Il buono
Vediamo prima i motivi utili:
Localizzazione / lingua: 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 utilizzo di sottodomini per suddividere i siti indirizzati a località diverse (ad es.:https://newyork.craigslist.org) o di offrire contenuti in una lingua specifica (ad es.https://en.wikipedia.org).App web indipendenti:utilizzo di sottodomini diversi per offrire esperienze il cui scopo differisce notevolmente dal sito dell'origine principale. Ad esempio, in un sito di notizie, l'app web per le parole crociate potrebbe essere pubblicata intenzionalmente da
https://crosswords.example.com, essere installata e utilizzata come PWA indipendente, senza dover condividere risorse o funzionalità con il sito web principale.
Il cattivo
Se non stai svolgendo queste operazioni, è probabile che l'utilizzo di un'architettura multiorigine sarà uno svantaggio quando crei 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 dei sottodomini per separare arbitrariamente parti di un sito che dovrebbero far parte di un'esperienza unificata.
Ad esempio, sconsigliamo vivamente di utilizzare i seguenti pattern:
Sezioni del sito: separazione delle varie sezioni di un sito nei sottodomini. Nei siti di notizie, non è raro vedere la home page all'indirizzo
https://www.example.com, mentre la sezione sportiva si trova all'indirizzohttps://sports.example.com, la sezione politica inhttps://politics.example.come così via. Nel caso di un sito di e-commerce, usare qualcosa comehttps://category.example.comper le categorie di prodotto,https://product.example.comper le pagine di prodotto e così via.Flusso di utenti: un altro approccio sconsigliato consiste nel separare le diverse parti più piccole del sito, come le pagine per i flussi di accesso o di acquisto nei sottodomini. Ad esempio, l'uso di
https://login.example.comehttps://checkout.example.com.
Per i casi in cui non è possibile eseguire la migrazione a un'unica origine, di seguito trovi un elenco di sfide e, se possibile, di soluzioni alternative che possono essere prese in considerazione durante la creazione di app web progressive.
Sfide e soluzioni alternative per le PWA di diverse origini
Quando si crea un sito web con più origini, fornire un'esperienza unificata con una PWA non è facile, soprattutto a causa del criterio della stessa origine, che impone una serie di vincoli. Esaminiamoli uno alla volta.
Service worker
L'origine dell'URL dello script del service worker deve essere uguale all'origine della pagina che chiama register(). Questo significa che, ad esempio, una pagina all'indirizzo https://www.example.com non può chiamare register() con l'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 provenienti da quell'origine (in base al percorso definito nel parametro dell'ambito), ma non controlla le pagine in altri sottodomini come, ad esempio, quelle in https://section.example.com.
In questo caso, l'unica soluzione è utilizzare più service worker (uno per origine).
Memorizzazione nella cache
Anche l'oggetto Cache, indexDB e localStorage sono vincolati a una singola origine. Ciò significa che non è possibile accedere alle cache che appartengono a https://www.example.com, ad esempio da: https://www.section.example.com.
Di seguito sono riportate alcune operazioni che puoi eseguire per gestire correttamente le cache in scenari come questo:
Utilizza la memorizzazione nella cache del browser: si consiglia sempre di 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, operazione che non può essere eseguita con la cache del service worker. Per le best practice sull'utilizzo della cache HTTP con i service worker, puoi consultare questo post.
Riduci la leggerezza dell'installazione dei service worker: se gestisci più service worker, evita di far pagare agli utenti un costo di installazione elevato ogni volta che passano a una nuova origine. In altre parole, prememorizza nella cache solo le risorse assolutamente necessarie.
Autorizzazioni
Anche le autorizzazioni sono limitate alle origini. Ciò significa che se un utente ha concesso una determinata autorizzazione all'origine https://section.example.com, 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 in ogni sottodominio in cui è richiesta una determinata funzionalità (ad es. la posizione). Per azioni come il web push, puoi mantenere un cookie per monitorare se l'autorizzazione è stata accettata dall'utente in un altro sottodominio, per 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 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 solo PWA per le pagine secondarie, non per l'URL principale dell'app.
Si verifica inoltre il problema per cui lo stesso utente potrebbe ricevere più richieste di installazione durante la navigazione sul sito, se ogni sottodominio soddisfa i criteri di installazione e richiede all'utente di installare la PWA.
Per limitare il problema, puoi assicurarti che il prompt venga visualizzato 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 il numero
event.preventDefault().
In questo modo, ti assicuri che il prompt non venga visualizzato in parti indesiderate del sito, mentre puoi continuare a mostrarlo, ad esempio nell'origine principale (ad esempio 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 del browser. Ad esempio, le versioni più recenti 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 a questo problema, ma è possibile applicare una soluzione alternativa per piccole parti dell'esperienza ospitate in sottodomini (ad esempio, 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 trasferire alla pagina principale tutte le informazioni risultanti dall'iframe.
- Come ultimo passaggio, una volta ricevuto il messaggio dalla pagina principale, è possibile annullare la registrazione dei listener e, infine, rimuovere l'iframe dal DOM.
Conclusione
Il criterio della stessa origine impone molte limitazioni per i 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 multiorigine, ma abbiamo esplorato alcune possibili soluzioni alternative. Ognuno di questi può comportare dei compromessi, pertanto utilizza il tuo giudizio al momento di decidere quale approccio adottare per il tuo sito web.
Quando valuti una strategia a lungo termine o una riprogettazione del sito, valuta la possibilità di migrare a un'unica origine, a meno che non ci sia un motivo importante per mantenere l'architettura multiorigine.
Grazie mille per le recensioni tecniche e i suggerimenti: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle e Andre Bandarra.