Un sito HTML-first ha raddoppiato gli utenti in una notte: ecco come

Diamo spazio alla vicenda che ha come protagonista una società di servizi pubblici, che è riuscita a raddoppiare il numero di utenti che completavano una procedura online nel giro di poche ore dopo il rilascio di una nuova applicazione web. Il risultato non è arrivato grazie a un framework più sofisticato, a un’interfaccia ricca di effetti grafici o a una maggiore quantità di codice JavaScript. Al contrario, la svolta è nata da una scelta apparentemente controcorrente: riportare l’HTML al centro dell’esperienza utente e utilizzare il codice lato client solo come miglioramento progressivo.

La vicenda si inserisce in una fase storica in cui molte applicazioni web hanno spostato una parte crescente del loro funzionamento lato browser. Framework come React, Angular e Vue hanno semplificato la creazione di interfacce complesse ma in alcuni scenari hanno anche introdotto nuove criticità: bundle JavaScript pesanti, dipendenze numerose, problemi di accessibilità e maggiore fragilità in presenza di connessioni lente o dispositivi datati. Chi sviluppa servizi rivolti a un’ampia platea di utenti, soprattutto in ambiti regolamentati, deve però confrontarsi con esigenze molto diverse rispetto a quelle di una piattaforma social o di una dashboard aziendale.

Nel caso specifico, l’azienda opera in regime di monopolio regolamentato. La soddisfazione degli utenti rappresenta un indicatore monitorato con attenzione e il mancato raggiungimento delle soglie richieste avrebbe potuto comportare sanzioni economiche rilevanti. Il processo digitale esistente non riusciva a soddisfare le aspettative dei cittadini e due precedenti tentativi di modernizzazione avevano già consumato budget importanti senza produrre benefici concreti.

Quando la modernizzazione sul web peggiora l’esperienza utente

La versione più recente del portale era stata sviluppata come applicazione React largamente dipendente dal browser. Dopo appena 3 giorni di disponibilità pubblica, l’organizzazione aveva deciso di ritirarla a causa dell’elevato numero di segnalazioni di malfunzionamenti ricevute dagli utenti.

Le criticità non riguardavano soltanto l’usabilità. L’applicazione faceva ampio affidamento su caricamenti asincroni, stati globali JavaScript e componenti che mostravano schermate di attesa prima di rendere disponibili i contenuti. Uno degli aspetti più problematici riguardava la gestione degli allegati: le immagini caricate dagli utenti erano memorizzate nel localStorage del browser insieme agli altri dati della pratica.

I browser moderni impongono limiti che si aggirano generalmente intorno ai 5 MB per dominio: una singola foto scattata con uno smartphone può superare facilmente quella soglia. Bastava quindi allegare poche immagini affinché il processo fallisse, con conseguente perdita dei dati inseriti.

Il problema era aggravato dalla tipologia degli utenti. Chi richiedeva il servizio poteva trovarsi in una zona con copertura mobile limitata, utilizzare un vecchio dispositivo Android oppure un browser non aggiornato. Proprio le persone che avevano maggior bisogno del servizio rischiavano di incontrare gli ostacoli maggiori.

L’approccio HTML-first e il ritorno alle basi del web

La soluzione adottata ha seguito una filosofia molto diversa. La nuova versione dell’applicazione, riscritta da zero, è stata quindi sviluppata con Astro, framework noto per privilegiare la generazione di pagine leggere e contenuti statici. L’obiettivo non era eliminare JavaScript, ma ridurne drasticamente il ruolo.

Ogni schermata del percorso guidato corrispondeva a una pagina autonoma: quando l’utente selezionava “Avanti“, il browser inviava i dati al server tramite una normale comunicazione HTTP. Dopo la validazione, il backend registrava immediatamente le informazioni e reindirizzava l’utente alla fase successiva.

Si tratta di un modello utilizzato da decenni nelle applicazioni web tradizionali e recentemente rivalutato da framework come Remix. Il vantaggio principale è la robustezza: l’intero flusso continua a funzionare anche in assenza di JavaScript. Se non esistono aggiornamenti in tempo reale, streaming di dati o interazioni particolarmente sofisticate, trasferire megabyte di codice al browser spesso genera più problemi che benefici.

La persistenza dei dati come requisito fondamentale

Uno degli aspetti più interessanti del progetto riguarda la gestione delle sessioni: ciascuna compilazione del modulo riceveva un identificativo univoco e ogni passaggio salva immediatamente le informazioni sul server, compresi gli allegati caricati. La scelta ha eliminato una delle cause più frequenti di abbandono nei moduli complessi: la perdita accidentale dei dati.

Le interruzioni di connessione, il riavvio del dispositivo o la chiusura involontaria della scheda non compromettevano il lavoro già svolto. Un caso reale ha mostrato quanto la soluzione fosse efficace: un utente ha completato la procedura circa un mese dopo averla iniziata, ritrovando tutte le informazioni precedentemente inserite.

Dal punto di vista architetturale, il modello si avvicina a un sistema di salvataggio incrementale lato server. Richiede maggiore attenzione nella progettazione delle API e della gestione delle sessioni, ma offre livelli di affidabilità nettamente superiori rispetto all’archiviazione locale nel browser.

Accessibilità e browser obsoleti: una scelta tecnica e non ideologica

Un episodio raccontato dallo sviluppatore Terence Eden ha influenzato profondamente il progetto. Durante una ricerca sul campo presso un ufficio pubblico londinese, Eden si è accorto di una persona che stava consultando informazioni su un portale governativo tramite una PlayStation Portable collegata al WiFi pubblico. Il browser integrato della console era estremamente limitato, ma le pagine risultavano comunque utilizzabili grazie alla loro semplicità.

L’episodio evidenzia un principio spesso trascurato: non tutti gli utenti dispongono di hardware recente o connessioni affidabili. Alcuni utilizzano tecnologie assistive, altri dispositivi molto vecchi. Un servizio pubblico deve funzionare anche in queste condizioni.

Da qui sono derivati requisiti molto precisi: compatibilità con browser datati, funzionamento completo senza JavaScript e conformità agli standard WCAG (Web Content Accessibility Guidelines) di livello AA. Le linee guida del W3C definiscono criteri verificabili per garantire accessibilità a persone con disabilità visive, motorie, cognitive o uditive e rappresentano oggi il riferimento principale per numerose normative internazionali.

Validazione dei moduli senza dipendenze pesanti

Un’altra area di intervento ha riguardato la validazione dei campi. Molti team investono settimane nella configurazione di librerie dedicate, soprattutto nei progetti React. Tuttavia i browser includono già un sistema nativo estremamente efficace basato sugli attributi HTML standard come required, pattern, email e minLength.

Anziché sostituire il meccanismo già presente, il progetto ha introdotto un piccolo Web Component con il compito di migliorare l’esperienza d’uso dell’interfaccia. Questo componente rilevava automaticamente gli errori generati dal browser durante la compilazione dei moduli e li visualizzava direttamente accanto ai campi interessati, utilizzando specifici attributi ARIA, che consentono alle tecnologie assistive come i lettori di schermo di comunicare correttamente le informazioni agli utenti.

La logica occupava meno di 1 KB di codice. Se il componente non riusciva a caricarsi, il browser utilizzava automaticamente la validazione nativa. Se anche quest’ultima non risultava disponibile, interveniva la validazione lato server. In pratica esistevano più livelli di protezione, ciascuno indipendente dagli altri.

La tecnica segue il principio della progressive enhancement, secondo cui il sito deve prima funzionare correttamente nella forma più semplice possibile; successivamente si aggiungono miglioramenti estetici e funzionali. Molti esperti continuano a considerare questo approccio uno dei metodi più efficaci per costruire applicazioni robuste e accessibili.

Perché le analisi tradizionali non raccontavano tutta la storia

Al momento del rilascio si è verificato un fenomeno inatteso. Il numero di pratiche completate è praticamente raddoppiato: i sistemi di analisi non riuscivano a spiegare l’origine di quel traffico aggiuntivo.

La spiegazione è piuttosto semplice. Molti strumenti di analytics dipendono da script JavaScript eseguiti nel browser: gli utenti che abbandonano il sito prima del caricamento completo degli script, oppure quelli che incontrano errori di esecuzione, spesso non vengono registrati correttamente.

Riducendo la dipendenza da JavaScript, una quota significativa di persone che prima falliva la procedura ha iniziato a completarla con successo: quegli utenti esistevano già; semplicemente non comparivano nelle statistiche tradizionali.

Molte organizzazioni continuano a misurare le prestazioni digitali senza considerare questa distorsione: quando il monitoraggio dipende dalla stessa tecnologia che genera il problema, ottenere una fotografia accurata diventa difficile.

Una vicenda che si interseca con il web di oggi

La storia dimostra che prestazioni, accessibilità e affidabilità non rappresentano vincoli che rallentano l’innovazione. Anzi.

Un’applicazione capace di funzionare su una connessione 3G instabile, su uno smartphone economico di 10 anni fa o persino su un browser limitato offre quasi sempre un’esperienza eccellente anche agli utenti dotati di dispositivi moderni.

Molte discussioni sullo sviluppo web si concentrano sugli strumenti più recenti. La lezione più interessante emersa da questo progetto è diversa: la tecnologia migliore dipende dal problema da risolvere. Se l’obiettivo consiste nel permettere a milioni di persone di compilare un modulo senza errori e senza perdere dati, HTML, HTTP e validazione lato server restano ancora oggi strumenti straordinariamente efficaci.