La navigazione tra le pagine web di un sito è legata al principio che sta alla base di internet: il collegamento ipertestuale o link. Le API History di HTML5 sono uno di quei piccoli cambiamenti grazie al quale la nostra vita digitale subirà alcuni miglioramenti. Grazie ad esse la velocità di navigazione su un sito aumenta notevolmente, per una migliore gestione dello scaricamento di informazioni che porta a miglioramenti sotto vari aspetti.
Siamo stati abituati, in quasi 20 (10 nel nostro paese) anni di internet, ad una serie di reazioni collegate alle nostre azioni digitali che possono dipendere dal contesto: se, ad esempio, sto navigando su un sito istituzionale, mi aspetto che quando clicco sul link “Dove siamo” il browser ricarichi l’intera pagina con le informazioni per raggiungere il luogo.
Se, invece, sto utilizzando un’APP online, penso ad esempio a Google+ pubblicato proprio in questi giorni, mi aspetto che al click su un link la pagina rimanga la stessa sulla quale sono e che alcune di queste informazioni vengano modificate. In realtà il principio basilare è comune tra i due contesti: sia per il sito “istituzionale” che per l’applicazione web, solo alcune informazioni cambiano all’esecuzione di un link. L’header ed il footer della pagina, molto probabilmente, rimangono identici prima e dopo il click.
Che motivo c’è, dunque, per sfruttare tante risorse per avere informazioni che già abbiamo caricato?
Perchè usare le History API
Per offrire la possibilità di caricare informazioni senza operare il refresh totale della pagina è necessario sfruttare una chiamata Ajax che restituisca le informazioni desiderate. Effettuando solamente una chiamata Ajax, però, l’url della pagina non viene modificato, ma rimane identico, e, dunque, se invio il link al mio amico Daniele, lui non riuscirà a vedere lo stesso risultato che volevo condividere. Un trucco per aggirare questo problema è stato, negli anni passati, l’utilizzo del location.hash per i link visualizzati; ovvero il link cliccato porta ad una porzione della stessa pagina con il cancelletto, ad esempio pagina.php#dovesiamo, ed intanto viene effettuata la richiesta asincrona. Chiaramente si tratta di un miglioramento rispetto alla prima soluzione, perchè se copio il link e lo invio a Daniele, ora potrà vedere l’informazione corretta.
Ma è una soluzione un po’ sporca!
Il mio amico, Daniele, aprendo la pagina con il suo browser vedrà il caricamento iniziale di un contenuto per poi notare, dopo pochi secondi (in base alla quantità di informazioni e alla velocità di connessione) l’aggiornamento della pagina con lo scaricamento della vera informazione: quella che volevo condividere io.
Inoltre, a livello SEO, qualsiasi, non dico esperto, ma anche solo apprendista, potrebbe strigliare il programmatore perchè l’informazione caricata tramite richiesta asincrona non viene indicizzata.
Anche il sistemista potrebbe, a lungo andare, arrabbiarsi: perchè scaricare 1 pagina e mezza (mezza perchè facciamo la chiamata Ajax) quando invece quello che interessa a Daniele è solo 1 pagina? Va da sé che questa soluzione va bene in mancanza di altro.
Ma c’è dell’altro: le History API.
La specifica HTML5 difinisce History come l’oggetto che offre la rappresentazione delle pagine nello storico della sessione all’interno del contesto di navigazione.
A livello pratico, nel nostro caso, questo significa che grazie all’oggetto history posso modificare l’URL della pagina senza che il browser effettui il refresh.
Come usare le History API
Per fare in modo che il click su un link permetta alla pagina web di preventivare il cambiamento di sezione che il browser è predisposto ad effettuare per poter, invece, caricare altre informazioni è necessario enucleare un insieme di passaggi tecnici. Propongo, dunque, una struttura schematica della soluzione che viene applicata al click sul link:
- Bloccare l’evento predisposto di default dal browser per il click: event.preventDefault()
Il click porterebbe al refresh della pagina ed è la prima azione da evitare - Impostare l’url del link cliccato nella location bar del browser:history.pushState(null, null, link)
Al punto 1 ho bloccato il caricamento della pagina definita nell’href, quindi è necessario predisporre l’aggiornamento manuale della barra degli indirizzi con il metodo pushState - Effettuare la richiesta asincrona per recuperare i dati inerenti al link richiesto:XMLHttpRequest
Inviando una richiesta Ajax alla pagina destinataria ottengo in risposta le informazioni desiderate
A questi passaggi è necessario aggiungere un controllo finale per poter effettuare il check dell’utilizzazione dei pulsanti di navigazione del browser che operano direttamente nella History: i tasti Back e Forward.
Per questo controllo possiamo definire un listener sull’oggetto window per l’evento popstate richiamato, appunto, dal click su uno dei tasti suddetti:
[javascript]
window.addEventListener("popstate", function(e){
…
}, false);
[/javascript]
Clicca qui per visualizzare il minisito che ho realizzato (non funzionante su Internet Explorer) come test per introdurre le History API di HTML5.
Considerazioni sul tipo di tecnologia
Chiaramente i plus di questa gestione sono la migliore gestione di velocità di caricamento e la minor banda sfruttata. A livello di compatibilità cross-browser purtroppo Internet Explorer non supporta, neanche nella versione 9, le API History di HTML5, mentre gli altri browser moderni non danno problemi.
La mancanza di compatibilità con Internet Explorer va sicuramente gestita con un fallback così da sfruttare il processo di graceful degradation e non causare problemi di visualizzazione ad alcuno.
Per quanto concerne la questione della user experience penso che il cambiamento offerto dalle API History non sia assolutamente invasivo in quanto l’utente è già in parte educato ad aspettarsi modifiche parziali alle pagine web tramite Ajax, ma che anzi possa rimanere stupito dalla velocità di caricamento delle informazioni evitando il refresh del browser.
In ambito SEO i search engine apprezzano sicuramente l’utilizzazione delle API History in quanto l’url della pagina linkata è quello corretto e non viene manipolato tramite alcuno script. La pagina di destinazione esiste ed il bot del motore di ricerca riesce a raggiungerla senza alcun problema in quanto, seguendo l’HREF ed evitando di eseguire il Js, essa viene aperta normalmente.
