Passare da una pagina all’altra del sito è lento: quando usare prefetch e prerender

Scegliere un percorso in cui l’anticipo abbia senso

Parti da una sequenza frequente: categoria e scheda prodotto, servizio e approfondimento, elenco e dettaglio. Osserva quali destinazioni vengono davvero scelte e quanto dura l’attesa. Non basta che la homepage contenga molti link per giustificare la preparazione di tutte le pagine collegate.

Definisci un obiettivo concreto, come ridurre l’attesa nell’apertura della scheda dopo la selezione di un prodotto. Se la destinazione ha già problemi di server, immagini o codice, affrontali anche direttamente: anticipare il lavoro non lo rende meno costoso. Per le cause generali resta utile la guida al sito lento. Se invece il problema è il ritorno all’elenco, verifica prima il comportamento del tasto indietro, dei filtri e della posizione.

Distinguere prefetch e prerender

Con le Speculation Rules, il prefetch recupera in anticipo il documento della destinazione, senza caricarne tutte le risorse collegate. Il prerender prepara più lavoro: può caricare risorse, eseguire codice e costruire la pagina prima che diventi visibile. Per questo richiede una selezione più attenta.

Esistono anche meccanismi precedenti, come il suggerimento rel="prefetch", con comportamento e limiti propri. La guida web.dev sul prefetch aiuta a distinguerli; non sono nomi intercambiabili per la stessa impostazione.

Il browser può non eseguire una preparazione richiesta. La pagina deve continuare a funzionare anche attraverso il caricamento ordinario.

Definire destinazioni consentite ed esclusioni

Inizia con un elenco circoscritto di pagine pubbliche di consultazione. Controlla gli indirizzi e ciò che accade aprendoli: un URL apparentemente simile a una scheda può includere un parametro che aggiunge un prodotto al carrello o modifica una preferenza.

Escludi invii, conferme, pagamenti, uscite dall’account e percorsi che avviano operazioni o consumano disponibilità. La documentazione MDN sulle Speculation Rules descrive i rischi degli effetti anticipati. Anche un semplice recupero del documento può attivare un’azione se il sito la esegue alla ricezione della richiesta.

In un esempio ipotetico, la pagina informativa di un’escursione può essere candidata alla prova, mentre un collegamento che blocca un posto deve restare escluso. Fai verificare anche gli indirizzi creati dai plugin, non soltanto quelli scritti manualmente nel menu.

Limitare le risorse e verificare i browser del pubblico

Una preparazione inutilizzata occupa banda e, soprattutto nel prerender, memoria e lavoro del dispositivo. Parti da poche destinazioni e da segnali di interesse adatti all’interfaccia. Il passaggio del puntatore può essere significativo su un computer, ma non descrive il comportamento di una persona che usa uno schermo tattile.

Verifica il supporto della funzione nelle versioni effettivamente utilizzate e mantieni collegamenti normali come base. Non promettere lo stesso effetto su tutti i browser. Considera reti lente, risparmio dati e limiti del dispositivo: anche quando il browser applica proprie protezioni, occorre valutare il costo complessivo del sito. Durante il collaudo controlla che il lavoro anticipato non ritardi immagini, pulsanti o contenuti della pagina che la persona sta leggendo in quel momento.

Controllare dati aggiornati e misurazione delle visite

Una pagina preparata prima del clic può contenere informazioni che cambiano nel frattempo, come numero di articoli nel carrello o stato dell’accesso. Verifica che la destinazione mostri dati coerenti quando viene attivata. Il problema va affrontato anche nei ritorni a schede già aperte, ma il prerender lo rende particolarmente evidente.

La documentazione Chrome descrive come riconoscere la fase di prerender e attendere l’attivazione per le attività pertinenti. Controlla gli strumenti di analisi del sito: una pagina preparata e mai vista non deve diventare automaticamente una visita o una conversione. Non assumere che ogni integrazione gestisca il caso allo stesso modo. Prova anche componenti esterni, contatori, raccomandazioni e richieste che partono all’avvio della pagina, definendo quali attività devono attendere l’uso effettivo.

Provare scenari completi prima della pubblicazione

Usa una copia di prova e una selezione piccola di indirizzi. Ripeti sia il clic verso la destinazione preparata sia una scelta diversa, per vedere il costo del lavoro che resta inutilizzato. Prova anche una navigazione rapida, in cui il browser non abbia ancora completato la preparazione.

Controlla ritorno all’elenco, cambio filtri, apertura in un’altra scheda e comportamento con la funzione disabilitata. Per account e dati variabili utilizza scenari di test, senza creare ordini reali. Verifica con gli strumenti del browser se la preparazione è partita, è stata rifiutata o è stata utilizzata. Un sito che sembra rapido dopo più visite potrebbe beneficiare semplicemente della cache ordinaria: il collaudo deve distinguere i due effetti prima di attribuire il miglioramento alla nuova tecnica.

Confrontare navigazioni utilizzate e lavoro sprecato

Valuta il tempo percepito dall’apertura effettiva, non soltanto dall’inizio del caricamento nascosto. Gli strumenti devono riconoscere le pagine prerenderizzate per produrre confronti coerenti. Puoi affiancare una misura delle navigazioni effettive alla quantità di preparazioni avviate e non utilizzate.

Il risultato da discutere comprende beneficio, risorse aggiuntive e correttezza delle funzioni. Se poche persone aprono le destinazioni preparate, restringi la selezione o modifica il momento di attivazione. Se non emerge un miglioramento apprezzabile, puoi rimuovere la regola senza cambiare l’architettura del sito. Conserva le esclusioni e aggiornale quando arrivano nuovi plugin o percorsi commerciali. La cache delle risorse e l’ottimizzazione delle pagine restano complementari: il lavoro anticipato è una scelta da mantenere soltanto quando il confronto ne sostiene l’utilità.

Domande frequenti

Prefetch e prerender migliorano anche il primo accesso da Google?

Non automaticamente. L’uso descritto riguarda soprattutto una navigazione futura preparata mentre la persona si trova già su una pagina del sito. La velocità del primo accesso richiede un’analisi dedicata delle risorse e del server.

È utile preparare in anticipo tutte le pagine del menu?

Non è una regola generale. Le destinazioni poco probabili possono consumare risorse senza un vantaggio. Inizia con pochi passaggi misurabili e verifica che le pagine siano sicure da recuperare e preparare.

Possiamo applicare il prerender al checkout?

Un percorso transazionale richiede una verifica specifica di effetti, dati variabili e integrazioni. Per una prima implementazione conviene limitarlo a pagine di consultazione; invii, pagamenti e azioni sul carrello devono restare fuori dalla preparazione automatica.