PWA vs native nella pratica: come fornire prestazioni in ciascuna

Per la maggior parte degli articoli, la discussione "PWA o nativa" termina al momento della decisione. Ma per chi costruisce la decisione è solo l’inizio. Scegliere la piattaforma giusta e gestirla male fornisce lo stesso risultato di scegliere quella sbagliata: un prodotto lento che l’utente abbandona.

Ho visto PWA veloci e PWA molto lente. Ho visto app native fluide e app native bloccate. La piattaforma non garantisce le prestazioni; garanzie di esecuzione. E ciascun approccio ha i propri punti di fallimento, le proprie insidie e le proprie pratiche assistenziali.

Questo testo è per coloro che hanno già deciso e ora devono concretizzarlo. Invece di confrontare PWA e nativo in astratto, mi occuperò di come mantenere le prestazioni di ciascuno nella pratica, dove ognuno tende a bloccarsi e cosa fare affinché la velocità raggiunga l'utente e rimanga.

Le prestazioni sono ciò che sente l'utente, non ciò che mostra il grafico

Prima di qualsiasi tecnica, vale la pena allineare ciò che conta. Le prestazioni, per l'utente, non sono un numero di riferimento. È la sensazione che l'app risponda. Significa vedere qualcosa di utile rapidamente, toccarlo e ricevere una risposta, senza aspettare con lo schermo bloccato.

Questa distinzione cambia il modo in cui lavoriamo. Ottimizzare le metriche interne di cui l'utente non si accorge è uno spreco. Ottimizzando il tempo fino alla prima interazione utile, ciò che rimane è la fluidità delle risposte e l'assenza di arresti anomali.

Sia in PWA che in nativo, il sovrano è la percezione. Cambiano le tecniche, ma l'obiettivo è lo stesso: far sì che il prodotto appaia velocemente ovunque l'utente guardi. Chiunque persegua questo, e non il bel numero, offre risultati migliori.

In pratica, fornire prestazioni in una PWA

Il tallone d’Achille di PWA è il peso della rete. Mentre viene eseguito nel browser, tutto ciò che carichi, script, stili, librerie, influisce sul tempo di apertura. L'errore più comune è accumulare dipendenze finché l'app non rallenta senza che nessuno si accorga di quando ciò è accaduto.

La prima pratica è mantenere l'app snella. Carica solo ciò che è necessario per la prima schermata e rimanda il resto. Rompi il codice in modo che l'utente non scarichi subito ciò che utilizzerà solo in seguito. Ogni kilobyte tagliato dal carico iniziale appare come velocità percepita.

Il secondo è padroneggiare la cache del service work. Questo è ciò che fa sì che PWA si apra immediatamente alle visite successive e funzioni offline. Ma la cache mal configurata serve vecchi contenuti o impedisce l'arrivo degli aggiornamenti. In pratica, definire strategie per tipologia di risorsa, aggressive per ciò che non cambia, validate per ciò che cambia, e testare l'aggiornamento ad ogni consegna, in modo da non bloccare l'utente in una vecchia versione.

Il terzo è misurare con dati reali e in condizioni reali: connessione lenta, dispositivo modesto. Ciò che vola sulla macchina dello sviluppatore può strisciare sul cellulare dell'utente. Le prestazioni di PWA vengono mantenute quando la misurazione entra nel flusso di consegna, non quando si fa affidamento sulla stampa.

In pratica, fornire prestazioni in un linguaggio nativo

Il nativo ha un netto vantaggio in termini di prestazioni, ma questo crea un falso senso di sicurezza. La trappola qui non è il peso del caricamento, ma l'uso imprudente delle risorse del dispositivo: memoria, batteria, lavoro sul thread principale.

La prima pratica è proteggere la fluidità dell'interfaccia. In modalità nativa, qualsiasi operazione pesante eseguita nel thread che disegna lo schermo provoca un arresto anomalo visibile. Lavori pesanti, elaborazione, accesso ai dati, networking, devono uscire da questo thread affinché l'interfaccia continui a rispondere. Gli arresti anomali dello scorrimento e del tocco provengono quasi sempre da qui.

Il secondo è prendersi cura della memoria e delle risorse. Le app native che perdono memoria o consumano risorse si deteriorano con l'uso, diventando più lente man mano che rimangono aperte. In pratica, ciò richiede disciplina nel rilasciare ciò che non si utilizza e nel testare l'app in sessioni lunghe, non solo in lanci rapidi.

Il terzo è rispettare il dispositivo. Un consumo eccessivo di batteria e dati non appare in un breve test, ma distrugge la reputazione dell'app nell'uso reale e porta alla disinstallazione. Misurare il comportamento dell'app nel tempo, su dispositivi diversi, è ciò che distingue l'app nativa che ha un bell'aspetto nella demo da quella nativa che mantiene la qualità nella vita dell'utente.

L'errore che li affonda entrambi

C'è una trappola comune ad entrambi gli approcci, ed è culturale prima che tecnica: lasciare la performance alla fine.

I team che considerano la velocità come un aggiustamento finale, dopo che il prodotto è pronto, scoprono che le scarse prestazioni di solito sono dovute all'architettura, non ai dettagli. Non è possibile “ottimizzare in seguito” ciò che è stato costruito senza pensare alla velocità. I guadagni dell’ultimo minuto sono piccoli; i problemi strutturali sono grandi.

La pratica che evita ciò è incorporare la prestazione come criterio continuo. Misurare tempestivamente, stabilire un limite di carico e risposta accettabile e trattare la regressione delle prestazioni come un difetto, non come un miglioramento opzionale. Sia in PWA che in quella nativa, la velocità che rimane è quella curata dall'inizio, consegna dopo consegna.

Un altro errore condiviso è non misurare in condizioni reali. Il dispositivo dello sviluppatore è potente e dispone di una buona rete. Non l'utente. Una performance che esiste solo nell’ambiente di chi la costruisce è un’illusione.

Performance come disciplina, non come miracolo

La lezione che vale per PWA e nativa è la stessa: le prestazioni non sono un effetto della piattaforma, sono il risultato di un'esecuzione attenta e continua. La migliore scelta tecnologica, eseguita senza disciplina, offre un prodotto lento. Una scelta modesta, eseguita con cura, può offrire un’esperienza eccellente.

In PWA, la disciplina si concentra su peso e cache. Nel nativo, nell'uso delle risorse e nella fluidità. In entrambi i casi, il nemico è l'autocompiacimento: dare per scontato che sia veloce perché è veloce per te, e scoprire tardi che non è veloce per l'utente.

Coloro che costruiscono per altri devono misurare il modo in cui sperimentano il prodotto, non come appare nell'ambiente di sviluppo controllato. Questa umiltà, il fatto di testare il dispositivo peggiore, la connessione peggiore, è ciò che distingue i prodotti che le persone utilizzano da quelli che disinstallano.

La decisione tra PWA e nativi è importante. Ma l'esecuzione conta altrettanto, ed è qui che la maggior parte dei prodotti vince o perde. La performance è un lavoro quotidiano e non esiste una piattaforma che possa sostituire questo lavoro.