Routing basato su hash e su path a confronto

Le SPA hanno bisogno di URL che il browser non recuperi. Esistono due approcci: quello basato sugli hash utilizza il frammento, cioè tutto ciò che segue #, che il browser non invia mai al server; quello basato sul percorso utilizza il pathname insieme alle funzionalità della History API.

Gli URL hanno un aspetto simile a https://example.com/#/about. Il server vede solo / e restituisce lo stesso HTML per ogni URL. Il JavaScript del client legge location.hash per decidere quale vista eseguire. È una soluzione semplice che non richiede alcuna configurazione del server.

I router basati sugli hash ascoltano l'evento hashchange, che viene generato ogni volta che cambia location.hash. Insieme alla lettura di window.location.hash, questa è tutta l'API necessaria per il routing lato client: non è coinvolta alcuna History API.

Gli URL hanno un aspetto simile a https://example.com/about, indistinguibile da quello degli URL restituiti dal server. pushState della History API cambia il percorso senza ricaricare la pagina; popstate viene generato durante la navigazione avanti o indietro; l'intercettazione dei clic trasforma <a> in una navigazione SPA.

Per il routing basato sul percorso, il server deve restituire l'index.html della SPA per qualsiasi percorso che l'utente potrebbe inserire direttamente o ricaricare. Altrimenti il ricaricamento di /about restituisce un errore 404. Configuri il server in modo che provi prima a trovare il file e, in caso contrario, utilizzi index.html: ad esempio, il history fallback in Nginx o vite-plugin-history-api nello sviluppo di Vite.

I motori di ricerca e molti strumenti non riescono affatto a eseguire la scansione dei frammenti hash: il contenuto di /#/about è invisibile ai crawler meno recenti. Google lo gestisce tramite il rendering headless, ma altri strumenti potrebbero non farlo. Gli URL basati sul percorso vengono sottoposti normalmente a scansione, quindi sono nettamente migliori per la SEO.

Gli URL con hash sono visibilmente «strani»: gli utenti notano il carattere # e potrebbero non fidarsi del link o dimenticare di copiare l'URL completo. Gli URL basati sul percorso hanno l'aspetto di qualsiasi altro URL web, come gli utenti si aspettano. Per questo motivo, le SPA moderne scelgono quasi sempre il routing basato sul percorso.

Basato sugli hash: circa 10 righe di JavaScript, con listener di hashchange e rendering. Basato sul percorso: chiamate a pushState, listener di popstate, intercettazione dei clic sui link e fallback lato server. L'hash è la scelta più semplice possibile; il percorso richiede più infrastruttura per offrire un'esperienza utente migliore.

Gli host completamente statici, come la configurazione predefinita di GitHub Pages, non possono eseguire un fallback lato server, quindi il routing basato sul percorso si interrompe al ricaricamento. Possibili soluzioni: utilizzare i meccanismi di reindirizzamento di 404.html, ospitare il progetto su Netlify o Vercel, che supportano il fallback delle SPA, oppure accettare il routing basato sugli hash per i progetti destinati esclusivamente all'hosting statico.

Alcune applicazioni combinano entrambi gli approcci: utilizzano il percorso per la route principale e l'hash per le sezioni della pagina, come finestre modali e ancoraggi delle schede. L'evento hashchange viene comunque generato per queste sezioni e completa il router basato sulla History, consentendo di gestire lo stato delle sottopagine senza appesantire l'URL principale.

Per migrare dagli hash ai percorsi, riscriva tutti i link interni, aggiunga il fallback del server, sostituisca la logica di hashchange con popstate e reindirizzi i vecchi URL con hash verso gli equivalenti basati sul percorso tramite un piccolo script di bootstrap che viene eseguito una volta e chiama history.replaceState.

Scelga il routing basato sugli hash per gli host statici senza riscritture, gli strumenti amministrativi interni per i quali la SEO non è importante e i widget incorporati. Scelga il routing basato sul percorso per tutto ciò che è rivolto agli utenti, deve essere indicizzato dalla SEO o viene condiviso sui social media: in pratica, per la maggior parte delle applicazioni.

Perché il routing delle SPA basato sul percorso richiede una configurazione del server che non è necessaria per il routing basato sugli hash?

Il routing basato sugli hash, con URL come /#/about, non richiede configurazioni del server, ma offre una SEO debole e utilizza URL poco eleganti. Il routing basato sul percorso, con URL come /about, richiede un fallback del server verso index.html, ma produce URL puliti, adatti alla SEO e facili da condividere. Le SPA moderne rivolte al pubblico utilizzano il routing basato sul percorso; i progetti ospitati su server statici o destinati a uso interno possono ancora scegliere gli hash per semplicità.