Una pagina che si apre rapidamente dopo un clic può migliorare la navigazione. Non significa però che prefetch e prerender vadano applicati a tutti i link interni.
La domanda utile non è solo quanto diventa veloce la pagina?, ma anche: quante risorse servono per preparare pagine che verranno davvero aperte? Il risultato dipende dal singolo sito: tema, plugin, cache pagina, CDN, hosting, script esterni e percorsi reali degli utenti. Senza osservare browser e infrastruttura non è possibile stimare in anticipo né il beneficio né il costo.
Per una PMI, il percorso più prudente è partire dal comportamento meno aggressivo, verificare le richieste nel browser e nei log, quindi estendere il prerender solo alle destinazioni per cui i dati mostrano un vantaggio sostenibile.
Che cos’è il caricamento speculativo
Il caricamento speculativo usa la Speculation Rules API del browser per preparare una possibile navigazione prima del clic. Non è una cache aggiuntiva e non sostituisce cache pagina, CDN o cache oggetti come Redis e Memcached.
- Prefetch: il browser recupera in anticipo la risposta della pagina che potrebbe essere visitata.
- Prerender: il browser prepara la pagina in background per poterla attivare rapidamente in caso di navigazione. Può comportare download di risorse, esecuzione di JavaScript e richieste attivate dagli script; per questo è potenzialmente più oneroso.
Una CDN o una cache HIT possono ridurre il lavoro dell’origin server, ma non annullano il costo di una speculazione inutilizzata. Il browser può comunque trasferire asset, usare CPU e memoria ed effettuare chiamate a strumenti terzi. Inoltre, il supporto varia in base al browser: quelli incompatibili ignorano le regole. Non va quindi promesso un miglioramento universale.
WordPress lo attiva già? Quando un plugin non serve
WordPress ha introdotto il supporto nativo al caricamento speculativo con la versione 6.8. La documentazione del WordPress Performance Team descrive una configurazione predefinita prudente: prefetch con eagerness conservative per visitatori non autenticati, soggetta alle condizioni e alle esclusioni previste dal Core.
Prima di installare un plugin, verificare la versione effettiva del Core e se tema, plugin di performance, CDN o codice personalizzato stanno già aggiungendo regole di prefetch o prerender. Regole duplicate o più aggressive possono rendere difficile attribuire costi e benefici.
Il plugin Speculative Loading può offrire un’interfaccia e opzioni aggiuntive, ma non è automaticamente necessario su un sito aggiornato. Prima di usarne i valori iniziali, controllare documentazione e versione installata: una strategia di prerender è più aggressiva del prefetch prudente del Core e va testata su un perimetro limitato.
Prefetch o prerender: scegliere in base alla pagina
| Scenario | Scelta iniziale prudente | Perché |
|---|---|---|
| Sito vetrina, blog B2B, pagine di servizio | Prefetch conservativo per visitatori non autenticati | Può ridurre l’attesa sulla navigazione successiva con un rischio più contenuto. |
| Poche destinazioni leggere, cacheabili e molto probabili | Test circoscritto di prerender | Ha senso solo se la pagina non avvia attività indesiderate al caricamento. |
| E-commerce, membership, configuratori, preventivi e prenotazioni | Evitare il prerender generalizzato | Stato utente, nonce, prezzi dinamici, moduli e risposte non cacheabili possono moltiplicare il lavoro senza una visita reale. |
| Login e area riservata | Esclusione o revisione tecnica specifica | Sessioni e contenuti personalizzati richiedono verifiche aggiuntive. |
Una cache HIT non equivale a costo zero. Anche con risposta servita dalla cache, un prerender può attivare asset, JavaScript, analytics, mappe, video, tag manager o API esterne. Per questo il prerender non dovrebbe essere un interruttore da attivare ovunque.
URL da escludere prima del test
Il Core prevede già alcune esclusioni tecniche. La documentazione di wp_get_speculation_rules() descrive, fra le altre, esclusioni per destinazioni amministrative e tecniche, link nofollow e, in determinate condizioni, URL con parametri di query. Queste protezioni non sostituiscono però una revisione delle pagine importanti per il business.
È normalmente opportuno escludere o valutare separatamente:
- carrello, checkout, account, login e logout;
- moduli, richieste di preventivo, configuratori e flussi multistep;
- prenotazioni, link che eseguono azioni e pagine dipendenti dalla disponibilità;
- contenuti molto personalizzati o non cacheabili;
- URL che producono molte varianti di cache;
- download pesanti e pagine con script terzi particolarmente costosi.
Per esclusioni mirate, WordPress espone il filtro wp_speculation_rules_href_exclude_paths. Il Core documenta anche le classi no-prefetch e no-prerender. L’effetto concreto va però controllato nel markup generato dal tema e nei componenti usati: applicare una classe a un contenitore o a un link può produrre risultati diversi a seconda dell’implementazione.
Quando entrano in gioco pagamenti, cookie personalizzati, API a consumo, analytics non standard o azioni utente, la revisione di sviluppatore e fornitore hosting è una precauzione necessaria, non un dettaglio opzionale.
Come verificare cosa sta facendo Chrome
La sola scheda Rete non basta sempre per capire se una pagina è idonea, se il prerender è partito o perché è stato annullato. In Chrome DevTools, Application > Speculative loads mostra regole riconosciute, URL candidati, idoneità e motivi di errore. La procedura è descritta nella guida di Chrome DevTools.
Nei log della CDN o del server, se l’header viene inoltrato e registrato, cercare Sec-Purpose. Valori come prefetch e prefetch;prerender possono aiutare a isolare le richieste speculative dalle navigazioni normali. Per quel segmento controllare cache HIT/MISS, richieste arrivate all’origin, tempi di risposta, byte trasferiti, chiamate verso terze parti ed errori.
DevTools aiuta a capire cosa tenta il browser; log e monitoraggio infrastrutturale mostrano invece il costo su CDN, cache, origin e servizi collegati. Servono entrambi.
Misurare un test: velocità utile e lavoro sprecato
Definire una baseline precisa: per esempio, due settimane con il comportamento nativo del Core invariato. Poi modificare una sola variabile per volta: prima un test di prefetch, quindi — solo se i segnali sono sani — un prerender limitato a poche destinazioni. Due-quattro settimane sono una finestra indicativa, non una regola: con poco traffico potrebbe non bastare, mentre campagne, rilasci o stagionalità possono rendere il confronto non affidabile.
Non affidarsi ai soli test sintetici. Osservare dati real-user delle pagine di arrivo, inclusi LCP e tempi percepiti, insieme a volume delle richieste speculative, cache HIT ratio, traffico verso l’origin, CPU, memoria, errori 5xx e costi o chiamate a servizi terzi.
Un indicatore interno utile è il tasso di utilizzo della speculazione, ma va definito separatamente per tecnica:
- Prerender: prerender effettivamente attivati / prerender avviati.
- Prefetch: navigazioni successive che riusano plausibilmente un prefetch / prefetch avviati.
Il primo rapporto è più diretto: per una pagina prerenderizzata e poi attivata, la Navigation Timing API espone activationStart maggiore di zero, come indicato nella documentazione Chrome sul prerender. Il secondo richiede cautela: una pagina visitata in seguito non dimostra da sola che il prefetch sia stato riusato. Se non è possibile correlare gli eventi in modo affidabile, trattarlo come una stima e non come un KPI certo.
Un tasso basso suggerisce di restringere URL o eagerness. Valutare infine le conversioni pertinenti — contatti, invii modulo o acquisti — senza attribuire automaticamente ogni variazione alla speculazione.
Checklist finale
- Verificare versione WordPress e regole già inserite da plugin, tema, CDN o codice personalizzato.
- Partire dal comportamento prudente per visitatori non autenticati.
- Escludere flussi con stato, azioni, personalizzazione o costo elevato.
- Controllare regole e idoneità con Chrome DevTools.
- Verificare che
Sec-Purposesia effettivamente disponibile nei log prima di basare su di esso il reporting. - Misurare insieme velocità delle pagine attivate, richieste inutilizzate e impatto sull’infrastruttura.
- Estendere il prerender solo a poche pagine con alta probabilità di clic e sostenibilità dimostrata.
- Se aumentano cache MISS, richieste all’origin, chiamate API o errori, ridurre la portata o tornare al prefetch prudente.
Il caricamento speculativo può migliorare alcune navigazioni, ma non è una scorciatoia universale. La configurazione migliore è quella che accelera i clic che contano senza trasformare i clic mancati in banda, elaborazione e costi inutili.
