Progressive Web App: Che cosa devono sapere i marketer?

nb: l’articolo è una traduzione / interpretazione di un post di Di: Glebs Vrevsky e Alex Hodakovskis

Spesso la creatività del marketing incontra dei limiti tecnologici. Una pagina web carica a una certa velocità. La UX è intrappolata dai browser. Le soluzioni all’ultimo grido sono accessibili solo da chi dispone di budget elevati.

Le applicazioni native risolvono alcuni di questi problemi, ma portano con sé il proprio fardello (costi di sviluppo, irregolarità della piattaforma, requisiti per il download, necessità di aggiornamenti e problemi con l’indicizzazione nelle ricerche.

I siti per mobile ottengono più visitatori, ma le app sono decisamente migliori in termini di engagement e tasso di conversione:

Le Applicazioni Web Progressive (PWA) hanno il potenziale di unire il mobile reach con l’engagement delle app native. Ma pochi marketer sanno in che cosa vanno a cacciarsi seguendo tale percorso, o nel decidere di non seguirlo.

Che l’ignoranza costa. Le decisioni relative alla riprogettazione dei siti sono spesso le più costose, e meno reversibili che i marketer prendono. Prendiamo Hertz: La momento stanno facendo causa al proprio partner di marketing, Accenture, per 32 milioni di dollari, in seguito a un sito malfunzionante e a un rinnovamento dell’app.

Quando si tratta di riprogettazione, potresti essere l’unico decision-maker. Potresti essere l’unica voce del coro. In ogni caso, hai bisogno di guardare oltre gli oggetti luccicanti nel campo del web design e di sapere come la tecnologia PWA ti aiuterà (o meno) a raggiunger i tuoi obiettivi di marketing. 

Questo post fornisce le basi della conoscenza tecnica sulle PWA, oltre a fare focus su altri aspetti come UX, SEO e analisi, che influenzano maggiormente i team di marketing.   

Che cosa sono le PWA?

Nate dai problemi evidenziati in precedenza, per il coniatore del termine Alex Russel le PWA sono dei “siti che hanno preso tutte le vitamine giuste”.  Rese possibili dai moderni browser, le PWA permettono un’esperienza simile a quella in-app all’interno di un normale browser, eludendo le trappole delle app native. 

In altre parole, le PWA provano ad unire il meglio di siti web e app:

• Tempi di caricamento prossimi a quelli della luce, senza la necessità di scarica re app e aggiornare continuamente;
• Indicizzazione ottimizzata, senza dover sacrificare i benefit UX delle app native;
• Distribuibile su tutti i marketplace di app, senza richiedere codebase diversi;
• Reach esteso attraverso un minor uso di dati, senza limitare le prestazioni;
• Accessibilità arricchitaattraverso l’eliminazione dei download e degli acquisti di app;
• Browsing offline, accesso web ai dispositivi mobili, linkability…

Gartner ha predetto che le PWA rimpiazzeranno il 50% delle app per mobile entro il 2020. Alcuni titani del digitale: Twitter, Forbes, Uber, Alibaba, AliExpress, sono già passati alle PWA, e c’è anche una collezione crescente di case studies che mostrano l’effetto positivo delle PWA sui marketing KPI: Conversioni, revenue, tempo passato, engagement, re-engagement, lead, ecc. 

Dai un’occhiata a uno di questi siti sul tuo dispositivo mobile per provare in prima persona le PWA:

1. Ordinare un caffè da Starbucks.
2. Giocare a 2048 nel tuo browser.
3. Pianificare l’itinerario con MakeMyTrip.
4. Navigare su uno store e-commerce di moda (demo).

Le PWA possono dare l’idea che il sogno di ogni digital marketer sia diventato realtà, ma esistono delle sfide importanti, in cui scenderemo a breve. Per prima cosa, tuttavia, scendiamo in ciò che contraddistingue le PWA.

Come funzionano le PWA?

I web è disseminato delle stesse spiegazioni le cui parole sono state semplicemente cambiate di posto, pertanto, invece di sprecare altro inchiostro ecco una delle migliori:

Un’Applicazione Web Progressiva è un’applicazione software, scritta su una piattaforma web ed eseguita nel browser, che si comporta come un’applicazione nativa gestita dal cloud. 

È un’applicazione perché si installa e legge il codice sul dispositivo o computer dello shopper, e tutto ciò più velocemente e con più funzionalità delle “app single page JavaScript” del passato. 

Questo perché è scritto nei linguaggi del web, ovvero HTML, CSS e JavaScript, invece che in qualche linguaggio specifico o all’interno di un framework nativo di una piattaforma. 

Ed è progressiva perché si carica in modalità “lazy-load” (caricamento pigro), assieme a tutte le risorse e i dati necessari, secondo come l’utente naviga sul tuo store.

Le PWA sono compatibili con la maggior parte dei browser?

Il supporto delle feature come le notifiche push e l’aggiunta alla schermata iniziale, sono integrazioni delle PWA. Le PWA necessitano che il browser supporti i “service worker” (spiegati di seguito), cosa che praticamente tutti i moderni browser fanno. (Safari, che spesso si trascina dietro, viene spesso nominato come “l’Internet Explorer delle PWA”.) 

Ma la mancanza di supporto per feature specifiche non impedisce l’uso delle PWA. Dato che le PWA sono siti, funzioneranno su tutti i browser (solo che lo faranno senza tutte le feature). 

Perché i “service worker” sono essenziali per le PWA

Un sito che invia notifiche push quando non si sta usando il cellulare? Navigare su internet senza connessione? Questo (e molto altro) è possibile grazie ai service worker. Ma di che cosa si tratta? 

La definizione dei service worker da parte di Matt Gaunt, Google:

Un service worker è uno script processato dal tuo browser in background, in modo separato da una pagina web, che apre la via a feature che non richiedono una pagina o un’azione dell’utente.

Sappiamo tutti come funziona un sito, il codebase è conservato in un server, e qualsiasi persona può accedervi tramite il proprio browser semplicemente scrivendo il dominio o direttamente l’indirizzo IP. 

Quando si tratta delle PWA, c’è un elemento in più: il service worker. Si trova tra il server e il browser, aggiungendo un nuovo livello di funzionalità background per mimare le feature tipiche delle app (ad esempio: notifiche push dello status di consegna dell’ordine dal sito di un ristorante). 

Se la navigazione web tradizionale consiste di un’interazione diretta utente-server, il service worker permette un’interazione indiretta:

Fondamentalmente, un service worker è un file JavaScript lato-client che viene aggiunta al codebase. (Se vuoi una spiegazione più dettagliata e tecnica, dai un’occhiata a questa discussione fornita dalla community di sviluppatori Google Chrome).

La magia (e i limiti) del caching

Il service worker è anche un elemento cruciale della performance della PWA che dipende dal caching. Le PWA forniscono agli sviluppatori un controllo senza precedenti su ciò che è e non è nella cache del dispositivo utente.  

Avvertenza: al primo caricamento, gli utenti non potranno beneficiare del “magic caching” che è responsabile per i seguenti tempi di caricamento supersonici. Le PWA possono fornire un piccolo documento shell con risorse in linea per dare l’impressione di un caricamento veloce, e nel frattempo viene installato il Service Worker.

Mentre ciò potrebbe migliorare in modo minimo l’esperienza del primo contatto, le PWA hanno molti altri assi nella manica oltre al caricamento supersonico. Qui entrano in gioco le Accelerated Mobile Pages (AMP). 

AMP per l’acquisizione, le PWA per l’engagement.

Le AMP sono pagine HTML leggere progettate per caricare il più veloce possibile. (Qui trovi un video molto esaustivo.) Le AMP sono usate maggiormente per pagine statiche (es. Siti di notizie) piuttosto che per pagine più dinamiche, che si trovano per esempio sui siti di e-commerce.

Google ha integrato le AMP nei propri risultati di ricerca su mobile nel 2016, e le pagine che utilizzano le AMP godono di una priorità intrinseca nei risultati di ricerca, essendo marcate con il badge ”AMP”:

Per siti complessi con molti elementi dinamici è possibile integrare PWA e AMP per ottenere i migliori risultati di ogni piattaforma. 

Le PWA arricchiscono la user experience e l’engagement attraverso delle feature come le notifiche push, mentre le AMP possono essere integrate su pagine statiche come la homepage e i post dei blog.

Tokopedia, la più grande piattaforma marketplace in Indonesia, ha creato le versioni AMP dei loro tre principali tipi di landing page organiche: prodotto, categoria e trending. Ciò ha creato 3.6 milioni di pagine AMP per la ricerca organica, il loro più grande funnel per la scoperta di prodotti. Le pagine AMP trasferiscono poi gli utenti a una PWA per assicurare velocità stabili e una grande UX.

Ora che abbiamo una comprensione del modo in cui le PWA funzionano, entriamo nel dettaglio dei risultati dell’impiego di questa tecnologia.

L’impatto della PWA sulla performance, UX e accessibilità

I benefici della performance di una PWA

La prima impressione conta. E la prima esperienza che il tuo visitatore ha del tuo sito non è né il design, né il contenuto. È il tempo di caricamento pagina. Il percorso utente più rapido non ha importanza se non puoi far arrivare i visitatori alla linea di partenza. E su mobile, circa il 53% dei visitatori abbandonano una pagina se questa impiega più di 3 secondi per caricare.

Le PWA scalano il carico delle richieste dati fino a una frazione del loro livello attuale. Chi ha adottato le PWA in genere riporta un miglioramento della performance fino al 300%. Per quanto riguarda i siti già ottimizzati per la velocità, ciò può comportare delle velocità di caricamento praticamente istantanee, simili a quelle delle app native. 

Anche senza integrare le AMP, le PWA aiutano nel primo caricamento della pagina dando priorità a documenti shell leggeri con risorse in linea. 

I benefici UX delle PWA

Storicamente, le app native battevano alla grande i siti per mobile in termini di utenti ed engagement. Le PWA possono colmare la mancanza delle feature che in precedenza erano riservate alle app native, come l’assenza di caricamento quando si passa da una pagina all’altra. (Quando si progetta una PWA, è consigliabile procede come se si stesse progettando un’app nativa, e non una pagina web).

Le PWA surclassano le app native in alcuni aspetti, come l’eliminazione del rallentamento dell’installazione e diminuendo i drop-off delle installazioni “web-to-app”. In basso trovi un esempio di UX da un normale sito (a sinistra) a confronto di una PWA (a destra):

Qui di seguito ci sono 7 altri benefici UX:

1. Aggiungi alla schermata iniziale

In un ambiente che costantemente si orienta sul mobile, il bene digitale più prezioso è la schermata home utente, che in precedenza era disponibile solo sulle app native. (Aggiungendo siti alla tua schermata home, storicamente, è stato sempre un processo multi-step. Chrome e altri moderni browser adesso hanno una feature integrata per l’aggiunta alla schermata iniziale con un solo tap.)

La presenza della schermata iniziale posiziona il tuo logo di fronte e centrato e il tuo sito a solo un click di distanza. 

2. Notifiche push

Il service worker dà la possibilità di integrare le notifiche push nel tuo sito mobile. Beyond the Rack ha ottenuto un incremento medio del 26% di spesa e del 72% di tempo speso in più sulla propria PWA da utenti che hanno visitato tramite notifiche push. Carnival Cruise Line, grazie alle proprie notifiche push, ha raggiunto il 42% di engagement. 

Lanciare delle campagne di marketing, dare informazioni sul progresso degli ordini, notizie sul marchio, è un canale unico di comunicazione che aiuta il tuo marchio a diventare parte della quotidianità dei tuoi utenti (presumendo che tu lo utilizzi responsabilmente). 

3. Modalità offline

La modalità offline non è solo un’esperienza di offline completamente nativa (anche se potrebbe essere resa possibile con delle grandi perdite per l’UX). Il service worker può prevalere sulla gestione standard della cache del browser con regole specifiche, e la memoria cache rimane indipendente dal server remoto.

Ciò significa che, se la tua connessione viene interrotta, è possibile continuare a navigare grazie al service worker. Immagina di star navigando sul tuo store di abbigliamento preferito, mentre sei nella metro di Londra diretto verso una zona di campagna con copertura scarsa.

Quando premi sul pulsante indietro, invece di visualizzare un errore 404, il service worker ti mostra la pagina salvata nella cache con i dati ottenuti in precedenza. La modalità offline, in realtà, è veramente sicura.

(Tecnicamente, in modalità offline, è possibile anche eseguire il checkout. Tuttavia, l’ordine verrà processato una volta riconnessi.)

4. Distribuzione sugli app store

Avere la tua app negli elenchi degli app store è molto importante. È una delle ragioni per cui molte aziende investono nello sviluppo di (costose) app native per iOS e Android. Le PWA possono bypassare tale necessità.

Grazie alle tecnologie come Trusted Web Activity, che incorpora un riquadro web in un’applicazione, può convertire qualsiasi Applicazione Web Progressiva in un’app nativa in poche ore. (Ci sarà un solo codebase, l’app nativa è in parte una visualizzazione web).

È così possibile distribuirla sia sull’Apple App Store e sul Google Play Store sena il bisogno di sviluppare un’app nativa da zero.

5. Aggiornamenti automatici

Gli aggiornamenti sono un coro per gli utenti, e una responsabilità per chi è coinvolto. Le PWA non richiedono aggiornamenti, dato che si aggiornano attivamente in tempo reale, come un sito web. 

6. Indipendenza dalle piattaforme

Ogni piattaforma ha i suoi pro e i suoi contro, lasciandoti al poco invidiato compito di sopperire alle limitazioni specifiche della piattaforma.

Le applicazioni indipendenti dalle piattaforme sono un’efficiente alternativa allo sviluppo e al mantenimento di app native separate per iOS, Android e per il web. Le PWA forniscono la stessa user experience praticamente a tutti (in base alla capacità del browser per il supporto dei service worker).

7. Linkability e indicizzazione

Come accade con ogni sito, le PWA hanno degli URL e possono essere processati dai crawler e indicizzati dai motori di ricerca. A differenza delle app native, gli utenti possono trovare le pagine PWA direttamente negli SERP. I tempi di caricamento accorciati fanno la felicità di motori di ricerca e utenti.

Accessibilità

I velocissimi tempi di caricamento delle PWA forniscono l’accessibilità alle compagnie che operano nei mercati emergenti o hanno bisogni di fornire agli utenti un accesso continuo al sito in ogni momento.

Per esempio, l’espansione rapida di Uber in nuovi mercati ha richiesto un’applicazione di ride hailing che funzionasse bene indipendentemente dalla posizione, che fosse veloce indipendentemente dal dispositivo. Pertanto, hanno optato per una PWA. 

Le richieste arrivavano a solo 50kb, permettendo alla PWA di caricare in meno di 3 secondi su reti 2G.

Questi benefit sono arrivati di pari passo, assieme ad alcune sfide impegnative.

3 sfide delle PWA che influiscono sui marketer

Sebbene una PWA possa significare una UI familiare con una curva di apprendimento praticamente piatta per gli utenti, ci sono delle differenze significanti nel back-end, che influiscono sugli sviluppatori, oltre che sui marketer.

Ci sono tre cose da tenere a mente:

1. È facile padroneggiare il SEO.
2. Le analitiche delle PWA sono difficili da impostare e gestire.
3. Il tuo team di sviluppo potrebbe non essere pronto per le PWA.

1. È facile padroneggiare il SEO.

Ci sono dei concetti sbagliati riguardo a PWA e SEO. Il più comune dice che “Google dà priorità alle pagine PWA nei propri risultati di ricerca”. Ciò è falso.

Google non dà importanza alle PWA, ma dà importanza alla velocità dei tempi di caricamento, che influenza anche il comportamento dell’utente (e, in cambio, invia il segnale verso Google). In altre parole, il semplice avere una PWA non ti aiuterà con il SEO, ma avere una buona PWA potrebbe.

Ci sono altri concetti sbagliati, e sfide, quando si tratta di PWA e SEO.

Perché il SEO è una sfida?

Le PWA sono siti basati su JavaScript. Le meccaniche di rendering delle PWA differiscono da quelle dei normali siti basati su HTML. Per comprendere la differenza tra i due approcci, devi comprendere il rendering lato server e lato client:

• I siti standard usano un metodo di rendering tradizionale chiamato Server-Side Rendering (SSR) (Rendering lato server). Con l’SSR, il contenuto di una pagina è viene pre-caricato sul server e viene passato ogni volta che un utente richiede una pagina. Pertanto, ogni volta che un utente visita una nuova pagina, viene scaricata l’intera pagina, anche se la differenza fra le due è minima.
• I siti basati su JavaScript utilizzano il client-side rendering (CSR). Il CSR esegue il render di un sito direttamente nel browser dell’utente, da cui prende il nome. L’utente riceve un piccolo file in JavaScript invece di un grande file in HTML, e il browser richiede solo gli elementi necessari per passare da una pagina all’altra o caricare contenuti aggiuntivi. Ecco perché i siti basati su JavaScript caricano così velocemente.

Il CRS è superiore dal punto di vista UX ma è più complicato quando si tratta di SEO. Devi affidarti ai motori di ricerca per fare il rendering corretto del tuo sito basato su JavaScript.

Di solito, quando un bot dei motori di ricerca scopre una pagina, ne ispeziona il codice sorgente (ovvero l’HTML) e se del caso indicizza tutte le informazioni disponibili. Questo è facile per i pesanti siti in HTML, dato che la maggior parte del contenuto richiesto dai crawler è immediatamente disponibile. Ma dato che le PWA in genere hanno solamente JavaScript nel proprio codice sorgente, questo crea un altro livello che i motori di ricerca devono sezionare.

I motori di ricerca recuperano il contenuto dei siti basati su JavaScript a ondate. Durante la prima ondata di indicizzazione, il motore di ricerca ispeziona la tua pagina e indicizza solo il contenuto non-JavaScript. Quando diventano le disponibili le risorse di rendering di un motore di ricerca, i crawler fanno ritorno sulla tua pagina per finalizzare il processo.

Dato che questo è un processo che richiede molte risorse (anche per Google), potrebbe richiedere diversi giorni in più perché il tuo contenuto venga indicizzato. Per molte aziende online, specialmente i siti di notizie, la velocità dell’indicizzazione dei contenuti è cruciale Ciò può anche influire sui siti di e-commerce che per esempio lanciano delle campagne di marketing con offerte a tempo limitato. 

C’è una soluzione, ma è instabile.

Ci sono diverse soluzioni. Per esempio, il Dynamic Rendering (rendering dinamico), è il metodo che viene raccomandato da Google. Con il Dynamic Rendering, è possibile combinare entrambi i metodi di rendering: I bot dei motori di ricerca ottengono la versione SSR, mentre gli utenti umani ottengono la versione CSR. 

(Questo conta come “cloaking”, ovvero una tecnica SEO comune da black-hat che fornisce ai motori di ricerca dei contenuti diversi rispetto agli utenti? Secondo Google: No.)

I motori di ricerca, in particolare Google, hanno elogiato la tecnologia PWA, ma c’è poca comprensione della preparazione dei motori di ricerca a gestire i siti JavaScript. Come confermato da Google:

Attualmente è difficile processare JavaScript e non tutti i crawler dei motori di ricerca sono capaci di processarlo con successo o in modo immediato.

Altri principali motori di ricerca, come Bing e Yandex, non garantiscono la corretta indicizzazione dei siti basati su JavaScript.

Le migliori pratiche di SEO sono rimaste intatte

Dato che le PWA non sono un fattore di posizionamento, le migliori pratiche tecniche, on-site e off-site di SEO si applicano anche ad esse. Ecco alcuni degli aspetti dei SEO che devi prendere in considerazione se vuoi migrare il tuo sito a una PWA: 

1. Implementare i riferimenti canonici per le pagine uniche e canonizzare i duplicati o impostare i meta robot su “noindex, nofollow.” (Questo è particolarmente importante se vuoi unire PWA e AMP). 
2. Ogni pagina deve avere un URL univoco.
3. Assicurati che i crawler abbiano accesso all’importante contenuto nascosto nelle tab, negli scorrimenti senza fine, ecc., se vuoi che i crawler esplorino il contenuto dietro a pulsanti, immagini ecc. usa un link HTML.
4. Utilizza il markup di Schema.org per favorire la comprensione del contenuto della pagina da parte dei crawler. Utilizza il markup Open Graph in modo che gli URL vengano graziosamente condivisi sui social media.
5. Non mostrare agli utenti un contenuto diverso da quello che mostri a Google (eccetto per il monito precedente).
6. Assicurati che le tue pagine superino il Google Mobile-Friendly Test.
7. Testa la velocità delle pagine su Google PageSpeed Insights.

2. L’implementazione delle analitiche è complessa.

Diciamo, per esempio, che hai implementato nella tua PWA la navigazione e il checkout offline. Come tengono traccia di tali eventi le tue analitiche e gli script di marketing di terze parti?

La sfida principale per il tracciamento dei dati nelle PWA è l’ecosistema ibrido sito-app. Dato che una PWA è un sito (lanciato in maniera leggermente diversa), gli strumenti di tracciamento standard come Google Analytics possono funzionare.

Tracciamento standard delle visualizzazioni della pagina

Una PWA impiega framework JavaScript come Angular o React, il che significa che il tracciamento standard delle visualizzazioni della pagina non funzionerà a dovere. Per esempio, la History API (API cronologia) fornisce agli sviluppatori l’abilità di modificare l’URL di un sito senza che la pagina venga ricaricata interamente.

Dato che le PWA caricano il contenuto di una nuova pagina in modo dinamico, il codice delle analitiche viene azionato solo una volta. Quindi, come puoi tracciare il comportamento di un utente su ogni pagina? La tua implementazione della PWA ha bisogno di codici di tracciamento modificati per assicurare che le “visite alla pagina virtuali” vengano azionate nel momento giusto.

Implementare il tracciamento con Google Tag Manager o direttamente nel codice richiede un test completo e pensato, in modo da evitare i problemi comuni:

• Discrepanze tra i percorsi/titoli delle pagine e il corrente stato dell’applicazione;
• Visite alle pagine sparse su molteplici URL;
• Visite alle pagine seguenti che non vengono tracciate.

La complessità aumenta quando si tratta di e-commerce ed altre implementazioni avanzate di PWA. La sequenza di attivazione tag e i push del data layer spesso si trovano di fronte a ostacoli. La gestione del data-layer è critica. 

Feature di tracciamento unica

Come puoi tracciare le feature uniche delle PWA (notifiche push, modalità offline, aggiunte alla schermata iniziale, ecc.) nelle analitiche? 

Eventi on-page

Gli eventi on-page sono la parte più semplice. Non c’è alcuna differenza rispetto al normale tracciamento web. 

Le azioni utente, come la sottoscrizione alle notifiche push o di aggiunta alla schermata iniziale, sono facilmente tracciabili utilizzando i metodi standard di Google Analytics. Devi solo inserire nel Data Layer le informazioni del Custom Event (evento personalizzato) che vuoi tracciare. 

Eventi service worker

Diventa più complicato quando la funzionalità viene inizializzata dal service worker della tua PWA, come la stessa notifica push. 

Il service worker della tua PWA viene eseguito fuori dall’app principale, il che rende impossibili l’accesso alla coda Google Analytics e trasmettere i dati sulle notifiche azionate dai dati della navigazione offline o dalla PWA. In parole povere, significa che non puoi tracciare il comportamento del service worker tramite il normale codice di tracciamento di Google Analytics. Al contrario, il service worker ha bisogno di inviare le visite direttamente a Google Analytics. 

Questo è possibile attraverso il Measurement Protocol (protocollo di misurazione), che bypassa il normale file analytics.js e invia i dati del service worker direttamente a una proprietà specifica di Google Analytics.

Com’è possibile ciò? Concretamente, ciò che fa il file analytics.js è generare delle richieste POST personalizzate a una proprietà di Google Analytics, e lo fa basandosi sul comportamento on-site dell’utente. Nel caso dei service worker, lo stesso processo viene simulato manualmente.

Tracciamento in modalità offline

Le analitiche, certamente, non funzionano senza connessione internet. Tuttavia, c’è una soluzione. 

Utilizzando una Fetch API, si ottiene la possibilità di ascoltare e rispondere a richieste offline. Il service worker intercetta le richieste fatte a Google Analytics, e le ripete in seguito se la richiesta iniziale non va a buon fine.

Per le visualizzazioni di pagina offline, vorrai distinguere quali richieste sono avvenute quando l’utente era offline da quelle che sono avvenute mentre l’utente era online. Puoi farlo grazie a una Custom Dimension in Google Analytics che identifica per quanto tempo le visite sono state messe in coda (es: durante l’offline, l’utente quanto è rimasto in una determinata pagina?).

Tutto questo può essere realizzato tramite degli aggiustamenti al codice di tracciamento, alla proprietà di analytics e a una configurazione Workbox.

3. Il tuo team di sviluppo potrebbe non essere pronto per le PWA.

Lavorare con le PWA richiede esperienza in JavaScript, HTML, CSS e Chrome DevTools. Sebbene queste abilità possano apparire basiche, sono invece poco presenti nella maggior parte dei team. Un’analisi del settore ha dimostrato che gli ingegneri front-end sono le risorse più limitate dei team IT.

La prima sfida per il team di sviluppo è quella di riscrivere interamente la parte front-end del tuo sito, in modo da renderla basata su JavaScript. Questo lavoro richiede esperienza in framework specifici, come React. 

In genere, si cercano ingegneri full-stack front-end. Per realizzare un progetto PWA, devono essere:

• Professionisti in JavaScript e framework come React.
• Avere esperienza con le Single-page applications (SPA).
• Fare affidamento sulla conoscenza di DevOps per l’infrastruttura, i service worker e i setup dei rendering lato server.
• Devono essere esperti di architetture PWA per collegare assieme tutti i componenti (es: come le App per mobile vengono sottoposte agli App Store, come funziona l’aggiunta alla schermata iniziale, e come mobile e desktop comunicano fra loro).
• Comprendere le analitiche specifiche delle PWA e il setup SEO, gestire le richieste dal back-end alle componenti front-end PWA, setup del livello di cache, ecc.

Le abilità sono facili da imparare ma difficili da padroneggiare, e niente meno che la maestria può funzionare qui. Nel 2018 JavaScript era il linguaggio di sviluppo più popolare, mentre nel 2019 il framework di React ha raggiunto il primo posto nei desideri degli sviluppatori. 

Costi: Siti, app e PWA

Come accade con ogni nuova iniziativa di marketing, spesso si arriva alla domanda centrale: Quanto costerà tutto questo? Indifferentemente dal tuo setup corrente, per prima cosa devi definire il tuo ecosistema web per capire se c’è posto per una (potenziale) PWA. 

Potresti avere un sito reattivo, un’app mobile, e strumenti di supporto come widget ed estensioni browser, ecc. Ogni componente del tuo ecosistema web fa parte del lavoro di sviluppo, e la pipeline di sviluppo del tuo team tecnico in rapporto al riepilogo dei costi potrebbe apparire come segue:

Componente	Costo relativo
Sviluppo di un sito ricco di feature e reattivo	$$$
Ottimizzazione dell’esperienza mobile	$$
Sviluppo di un’app nativa Android	$$$$
Sviluppo di un’app nativa iOS	$$$$

Le PWA hanno il potenziale di tagliare i costi, dato che un singolo investimento fa sì che non sia più necessario sviluppare un’app indipendente:

Componente	Costo relativo
Sviluppo di un sito PWA con un’esperienza mobile simile alle app	$$$
Lancio dell’app PWA sull’App Store come app nativa	$
Lancio dell’app PWA sul Play Store come app nativa	$

Le app mobile native possono ancora esistere per i tuoi clienti abituali e affezionati (per ottenere il massimo della più stretta integrazione con il dispositivo), ma finanziare delle app per mobile indipendenti può prosciugare le risorse. In media, basandoci sulla nostra esperienza nel mercato U.S.A, i costi dello sviluppo di app native sono:

• Sviluppo di un’applicazione nativa “Startup”: $50K–100K
• Sviluppo di un’applicazione nativa “Enterprise”: $500K+

Con una PWA, puoi tagliare i costi utilizzando lo stesso codebase PWA per tutte le piattaforme, sia desktop, mobile che applicazioni.

Se hai già uno store e-commerce di successo, allora l’integrazione della PWA richiederà di scrivere nuovamente il front-end del tuo store. In genere lo sviluppo richiede dai 2 ai 4 mesi di lavoro, in base alla complessità del tuo store. Ci sono dei framework PWA pronti all’uso come Ionic e il tema ScandiPWA per Magento, che può integrare una PWA nel tuo sito in settimane, invece che in dei mesi.

Se stai per lanciare un nuovo store o sito di e-commerce, allora l’integrazione di una PWA al lancio può essere molto preziosa. Per altri tipi di business, esistono delle domande chiave che possono aiutare a determinare se una PWA è degna di essere presa in considerazione. Se rispondi “No” a tutte e tre le domande, non ha senso che tu sviluppi una PWA:

• Stai pensando di introdurre un’app per mobile?
• Il tuo sito necessita di un rinnovamento?
• È il traffico da mobile che detta la domanda?

Conclusioni

Le PWA promettono di portare alcune delle migliori app native direttamente sul browser. Rispetto allo sviluppo di siti e app, le PWA sono molto meno costose da creare e mantenere, e sono indipendenti dalle piattaforme. 

I marketer hanno la parola nella riprogettazione del sito. In molti casi, questa è la decisione più costosa (e difficile da cambiare) che viene presa. Oltre ai potenziali benefici, è saggio per i marketer di ricordare le sfide e le condizioni di SEO e analitiche, prima di impegnarsi in una PWA. 

Sono i marketer che devono realizzare il potenziale delle PWA. Le notifiche push, ad esempio, non saranno d’aiuto se i marketer invieranno spam ai potenziali clienti. Come accade con altre tecnologie, le PWA sono uno strumento, e pertanto per creare valore devono essere utilizzate da un esperto.