Un sito costruito secondo la filosofia HTML-first è riuscito a raddoppiare gli utenti che portavano a termine una procedura online, e lo ha fatto nel giro di una notte. Niente framework all’ultima moda, niente interfacce piene di animazioni, niente montagne di codice JavaScript. La svolta è arrivata da una scelta che sembra andare controcorrente: rimettere l’HTML al centro dell’esperienza e usare il codice lato browser solo come miglioramento facoltativo. La protagonista è una società che eroga servizi pubblici, alle prese con un processo digitale che proprio non funzionava.
Per capire il contesto serve ricordare dove sta andando buona parte del web. Negli ultimi anni framework come React, Angular e Vue hanno reso più semplice costruire interfacce complesse, spostando però sempre più lavoro dentro il browser. Funziona bene in certi scenari, meno in altri: bundle JavaScript pesanti, dipendenze a non finire, problemi di accessibilità e una fragilità evidente quando la connessione è lenta o il dispositivo è vecchio. Chi sviluppa servizi pensati per un pubblico vastissimo, magari in settori regolamentati, gioca una partita diversa rispetto a chi crea una piattaforma social o una dashboard interna. Nel caso in questione l’azienda opera in regime di monopolio regolamentato, dove la soddisfazione degli utenti viene tenuta sotto controllo e mancare le soglie può tradursi in sanzioni pesanti. Due tentativi precedenti di modernizzazione avevano già bruciato budget importanti senza risultati.
Quando modernizzare il sito peggiora tutto
L’ultima versione del portale era un’applicazione React fortemente dipendente dal browser. È durata appena 3 giorni online, poi è stata ritirata per la valanga di segnalazioni. I problemi non erano solo di usabilità. L’app si appoggiava a caricamenti asincroni, stati globali JavaScript e schermate di attesa prima di mostrare qualcosa. Il punto più critico riguardava gli allegati: le immagini caricate finivano nel localStorage del browser insieme al resto della pratica.
I browser moderni limitano quello spazio intorno ai 5 MB per dominio, e una foto scattata con uno smartphone può superarlo da sola. Bastavano poche immagini per mandare in errore tutto, con perdita dei dati già inseriti. A peggiorare le cose c’era il tipo di utenza: persone in zone con copertura mobile scarsa, vecchi telefoni Android, browser non aggiornati. Proprio chi aveva più bisogno del servizio rischiava di sbatterci la testa.
Il ritorno alle basi con Astro e la persistenza dei dati
La nuova versione è stata riscritta da zero con Astro, framework che predilige pagine leggere e contenuti statici. L’idea non era cancellare JavaScript, ma ridimensionarlo. Ogni schermata del percorso guidato diventava una pagina a sé: alla pressione di “Avanti” il browser spediva i dati al server con una normale comunicazione HTTP, il backend validava, salvava e reindirizzava al passaggio dopo. Un modello vecchio di decenni, riportato in auge da framework come Remix, il cui pregio è la robustezza: tutto continua a funzionare anche senza JavaScript attivo.
Sulla gestione dati è arrivata la mossa decisiva. Ogni compilazione riceveva un identificativo univoco e ogni passaggio salvava subito le informazioni sul server, allegati compresi. Addio a una delle cause più comuni di abbandono nei moduli lunghi: la perdita accidentale del lavoro. Interruzioni di rete, riavvii, schede chiuse per sbaglio non cancellavano niente. Un utente ha completato la procedura circa un mese dopo averla cominciata, ritrovando tutto al suo posto.
A indirizzare il progetto ha contribuito un episodio raccontato dallo sviluppatore Terence Eden, che in un ufficio pubblico londinese vide una persona consultare un portale governativo da una PlayStation Portable collegata al WiFi. Browser limitatissimo, eppure le pagine restavano usabili grazie alla loro semplicità. Da lì requisiti precisi: compatibilità con browser datati, funzionamento totale senza JavaScript, conformità agli standard WCAG di livello AA.
Anche la validazione dei campi è stata ripensata. Invece di librerie esterne, si è sfruttato il sistema nativo dei browser con attributi come required, pattern, email e minLength. Sopra è stato aggiunto un piccolo Web Component che intercettava gli errori e li mostrava accanto ai campi, usando attributi ARIA per i lettori di schermo. Meno di 1 KB di codice. Se il componente non caricava, interveniva la validazione nativa; se mancava pure quella, restava quella lato server. Più livelli indipendenti, secondo il principio della progressive enhancement: prima far funzionare il sito nella forma più semplice, poi aggiungere il resto.