Oggi le pagine web sono ricche di immagini, video ed elementi interattivi che mirano a migliorare l’esperienza dell’utente. Tuttavia, questi elementi possono rallentare il tempo di caricamento della pagina.
Con il progredire della tecnologia, un obiettivo rimane costante: le prestazioni. Tutti sperano che le loro pagine web si carichino alla velocità della luce.
Un modo per rendere più veloce il caricamento delle pagine web è quello di effettuare il prerendering o il prefetch prima che l’utente vi acceda.
Breve storia del prerendering
Nel 2011, il team di Chromium ha introdotto una prima forma di prerendering nel browser Chrome attraverso il tag <link rel="prerender" … >.
Questo permetteva agli sviluppatori di suggerire ai browser le pagine che un utente avrebbe potuto visitare successivamente. Il browser recuperava e renderizzava silenziosamente queste pagine in background, riducendo drasticamente il tempo di caricamento quando l’utente navigava verso quelle pagine.
Nonostante i vantaggi, questa prima implementazione del prerendering utilizzava molte risorse di banda e CPU e poteva causare problemi di privacy se l’utente non visitava le pagine prerenderizzate. Inoltre, era necessario selezionare manualmente i link di cui effettuare il prerendering, il che non era sempre efficace o fattibile.
Per risolvere alcuni di questi problemi, Chrome ha deprecato il prerendering utilizzando il suggerimento rel=prerender in favore del metodo NoState Prefetch, che prevede il recupero delle risorse di una pagina senza eseguire JavaScript o altre azioni potenzialmente invasive per la privacy.
Il metodo NoState Prefetch migliorava il caricamento delle risorse ma non poteva garantire un caricamento istantaneo della pagina come un prerendering completo.
L’API Speculation Rules
L’API Speculation Rules è una nuova API sperimentale definita da JSON che precarica in modo speculativo gli URL prima di navigare verso di essi, con tempi di rendering più rapidi e una migliore esperienza utente.
L’API consente agli sviluppatori di configurare regole con una struttura definita in formato JSON all’interno di uno script script type="speculationrules" che il browser può utilizzare per decidere di quali URL eseguire il pre-render.
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["firstpage.html", "secondpage.html"]
}
]
}
</script>Lo stesso vale per il prefetching, che spesso può essere un buon primo passo verso il prerendering:
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["firstpage.html", "secondpage.html"]
}
]
}
</script>I frammenti di codice qui sopra mostrano come funziona l’API Speculation Rules specificando un elenco di URL di cui eseguire il prefetch o il prerender.
Recentemente, Google ha annunciato nuovi miglioramenti all’API Speculation Rules, che ora offre la possibilità di trovare automaticamente i link utilizzando le regole dei documenti. Funziona recuperando gli URL dal documento in base a una condition where.
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"where": {
"and": [
{
"href_matches": "/*"
},
{
"not": {
"href_matches": [
"/wp-login.php",
"/wp-admin/*"
]
}
}
]
},
"eagerness": "moderate"
}
]
}
</script>In questo frammento di codice, tutti gli URL della pagina vengono considerati per il prerendering, tranne quelli che portano alle pagine di login e di amministrazione di WordPress. È anche possibile specificare un livello di eagerness – eager (subito), moderate (al passaggio del mouse dopo 200 ms) e conservative (al passaggio del mouse o al tocco).
I selettori CSS possono essere utilizzati in alternativa o insieme a href per trovare i link nella pagina corrente:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "selector_matches": ".prerender" },
{ "not": {"selector_matches": ".do-not-prerender"}}
]
},
"eagerness": "moderate"
}]
}
</script>Mentre si utilizza l’API Speculation Rules, la si può ispezionare utilizzando i servizi in background degli speculative loads (carichi speculativi) nella scheda Application di Chrome quando si ispeziona la pagina.
C’è dell’altro: lo esploreremo nella sezione dedicata al debug.
Supporto browser
L’API Speculation Rules è supportata dai moderni browser basati su Chromium, compresi Chrome ed Edge, a partire da versioni specifiche.
Questo garantisce che gli utenti dei browser supportati possano beneficiare di tempi di caricamento più rapidi, mentre quelli degli altri browser non subiranno alcun effetto negativo, poiché l’API è uno strumento di miglioramento progressivo.
Il plugin Speculative Loading per WordPress
Per sfruttare i vantaggi dell’API Speculation Rules in WordPress, il team di WordPress Performance (che include sviluppatori di Google) ha recentemente pubblicato il plugin Speculative Loading. Questo plugin consente il caricamento speculativo degli URL di frontend collegati alla pagina.
Finora il plugin è stato poco adottato perché l’API è ancora in fase iniziale, ma ha ricevuto alcune recensioni positive.
Per impostazione predefinita, il plugin è configurato per eseguire il prerendering degli URL del frontend di WordPress quando l’utente passa il mouse su un link pertinente. Questo può essere personalizzato tramite la sezione Speculative loading in Settings > Reading.
Ciò significa che tutti gli URL collegati alla pagina vengono prerenderizzati con una configurazione eagerness di livello moderate, che di solito si attiva quando si passa il mouse su un link. Per questo motivo, non è necessario fare nulla dopo aver attivato il plugin: funziona subito.
Ad esempio, supponiamo che abbiate già installato il plugin Speculative Loading su un sito WordPress. Usate i DevTools di Chrome per ispezionare il sito e cliccate sulla scheda Elements. Scorrendo verso il basso, noterete che è già stato aggiunto uno script script type="speculationrules" con le varie regole di speculazione.
Utilizza una Regex per specificare i link che devono essere prerenderizzati, i link da non prerenderizzare e per impostare l’eagerness. Le sezioni seguenti spiegano nel dettaglio queste regole.
Limiti per prevenire l’uso eccessivo
Chrome ha dei limiti per evitare un uso eccessivo dell’API:
| Eagerness | Prefetch | Prerender |
| immediate/eager | 50 | 10 |
| moderate/conservative | 2 (FIFO) | 2 (FIFO) |
Prevengono l’uso eccessivo attraverso varie impostazioni basate sull’urgenza e sull’interazione con l’utente.
immediateeeager: non dipendono dalle azioni dell’utente, quindi hanno limiti più elevati. Consentono di regolare la capacità in modo dinamico eliminando le speculazioni più vecchie.moderateeconservative: al contrario, queste impostazioni sono attivate dall’utente e aderiscono al principio First In, First Out (FIFO) con un limite massimo di 2, sostituendo le speculazioni più vecchie con quelle nuove per conservare la memoria.
Impedire il prefetch e il prerender di alcuni URL
È importante notare che i percorsi di WP-admin sono esclusi dal prerender e dal prefetch per impostazione predefinita. In qualità di sviluppatori di WordPress, spetta a voi determinare i percorsi a cui dare priorità.
Potete personalizzare le regole per stabilire quali tipi di URL precaricare in modo speculativo utilizzando il filtro plsr_speculation_rules_href_exclude_paths.
Il seguente esempio di codice assicura che URL come https://wordpresssite.com/cart/ o https://wordpresssite.com/cart/book/ siano esclusi dal prefetching e dal prerendering:
<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( $exclude_paths ) {
$exclude_paths[] = '/cart/*';
return $exclude_paths;
}
);A volte potreste voler escludere un URL dal prerender e attivarne il prefetch. Ad esempio, una pagina con JavaScript lato client per aggiornare lo stato dell’utente probabilmente non dovrebbe essere sottoposta a prerendering, ma sarebbe ragionevole eseguirne il prefetch.
A questo scopo, il filtro plsr_speculation_rules_href_exclude_paths riceve la modalità corrente ( prefetch o prerender) per fornire esclusioni condizionali.
Ad esempio, facciamo in modo che URL come https://wordpresssite.com/products/ non possano essere prerenderizzati, pur consentendone il prefetch.
<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( array $exclude_paths, string $mode ): array {
if ( 'prerender' === $mode ) {
$exclude_paths[] = '/products/*';
}
return $exclude_paths;
}
);Debug delle regole di speculazione per i siti WordPress
Il debug delle regole di speculazione può essere complicato perché le pagine prerenderizzate vengono rese in un rendering separato, come una scheda di background nascosta che sostituisce la scheda corrente quando viene attivata. Il team di Chrome ha lavorato molto con i DevTools, consentendoci così di eseguire il debug.
In Chrome DevTools, andate alla scheda Applications e poi scorrete verso il basso fino alla scheda Speculative loads. Questa scheda fornisce agli sviluppatori dettagli sulla speculazione, sugli URL prerenderizzati, su quelli che falliscono e molto altro ancora.
Qui si vede che cinque link della pagina possono essere prerenderizzati in base agli URL che corrispondono alle regole impostate nel JSON delle regole di speculazione, come si vede qui sotto. È bene notare che non è necessario elencare tutti gli URL; le regole del documento consentono al browser di rilevarli dagli stessi link di origine della pagina.
Lo “stato” di alcuni link è indicato come “Not triggered”: il processo di prerenderizzazione non è ancora iniziato. Tuttavia, se passiamo il mouse sui link della pagina, vediamo che lo stato cambia man mano che ogni URL viene prerenderizzato.
Ricordate che Chrome ha fissato dei limiti per i prerender, tra cui un massimo di due prerender per moderate eagerness, quindi dopo aver passato il mouse sul terzo link, vedremo il motivo del fallimento per quell’URL:
È anche possibile cambiare il renderer utilizzato dai pannelli di DevTools con il menu a tendina in alto a destra o selezionando un URL nella parte superiore del pannello e selezionando Inspect:
Questo menu a tendina (e il valore selezionato) è condiviso da tutti gli altri pannelli, come ad esempio il pannello Network, dove potete vedere che la pagina richiesta è quella prerenderizzata:
Oppure il pannello Elements, dove potete vedere il contenuto della pagina:
Così come potete eseguire il debug delle pagine prerenderizzate, potete anche eseguire il prefetch delle pagine. Per il plugin “Speculative loading”, assicuratevi di selezionare Prefetch come Speculation Mode.
Ora, quando ispezionate la pagina con DevTools e navigate nella scheda Speculative loads, l’azione sarà Prefetch per i vari URL e anche le regole cambieranno.
Quando si passa alla scheda Network dopo aver messo il mouse su un link, le risorse prefissate vengono mostrate per ultime, come si può vedere dalla colonna Type. Queste vengono recuperate con la priorità più bassa perché sono destinate alle navigazioni future e Chrome dà la priorità alle risorse della pagina corrente.
Confronto delle prestazioni
Finora abbiamo visto cosa fa e come funziona il plugin “Speculative Loading”. Basta con la teoria; confrontiamo le prestazioni di due siti identici sullo stesso server (Hosting WordPress di Kinsta).
Per fare ciò, ho creato due siti WordPress con la dashboard MyKinsta sullo stesso data center (Iowa (US Central), potenziato con le VM C3D di Google) e senza installare alcun altro plugin per entrambi i siti.
Il sito “Bare-site” è privo del plugin, mentre per il sito “Speculative-site” il plugin “Speculative Loading” è installato e attivato nella bacheca di WordPress.
È importante sapere che l’API Speculative Rules migliora solo il tempo di caricamento della pagina successiva che si sta per navigare: non è possibile giudicare questo aspetto basandosi su strumenti generici per le prestazioni del sito come Lighthouse.
Verifichiamo la velocità della pagina caricando una pagina da uno specifico link interno dei due siti web e utilizzando la scheda Network di Chrome DevTool durante l’ispezione del sito per vedere il tempo di caricamento e altre informazioni.
Per quanto riguarda “Bare-site”, noterete che il caricamento è più lungo perché l’intero processo di caricamento avviene in movimento e il contenuto DOM viene appena caricato:
Ma nel caso di “Speculative-site”, il contenuto del DOM è già stato caricato tramite la Speculative API e memorizzato nella cache.
La differenza tra i due siti potrebbe sembrare minima. In questo caso, la differenza è di circa 0,22 s, ma nel caso di un sito di grandi dimensioni con più contenuti, si inizia a notare una differenza significativa.
Impatto dell’API Speculation Rules sulle funzioni analitiche
Le funzioni analitiche sono essenziali per tracciare l’utilizzo del sito web attraverso le visualizzazioni di pagina e gli eventi e per valutare le prestazioni attraverso il monitoraggio degli utenti reali (RUM). È importante sapere che il prerendering può influenzarle.
Ad esempio, l’utilizzo dell’API Speculation Rules potrebbe richiedere del codice aggiuntivo per attivare le funzioni analitiche solo quando le pagine prerenderizzate vengono effettivamente visitate. Sebbene Google Analytics, Google Publisher Tag (GPT) e Google AdSense ritardino il tracciamento fino a quando una pagina non è attiva, non tutti i provider lo fanno di default.
Per gestire questo problema, è possibile impostare una promessa che inizializzi le funzioni analitiche solo all’attivazione della pagina:
// Promise to activate analytics on page activation for prerendered pages
const whenActivated = new Promise((resolve) => {
if (document.prerendering) {
document.addEventListener('prerenderingchange', resolve);
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialize analytics
}
initAnalytics();Riepilogo
Questo articolo spiega cos’è l’API Speculative Rules, come funziona e come utilizzarla su un sito WordPress. Si tratta di una funzione ancora sperimentale, ma che sta gradualmente ottenendo un’adozione massiccia.
Le regole di speculazione sono ancora limitate alle pagine della stessa scheda, ma sono in corso sforzi per ridurre queste restrizioni.
È inoltre importante sapere che una parte significativa delle prestazioni del sito dipende dalla qualità dell’hosting. Noi di Kinsta siamo noti per offrire un hosting WordPress di qualità superiore con decine di funzioni premium.
La nostra infrastruttura è completamente containerizzata e alimentata esclusivamente dalla Google Cloud Platform sulla rete Premium Tier di Google, che ci permette di offrire un’ampia selezione di data server più veloci, prestazioni incredibili, caching a livello di server, risorse dedicate e sicurezza avanzata.
Date un’occhiata a ciò che dicono i nostri clienti o contattateci per saperne di più sulla nostra soluzione di hosting gestito e sui suoi vantaggi.
Cosa ne pensate dell’API Speculative Rules e della sua introduzione in WordPress? Condividetelo con noi nei commenti qui sotto!
Lascia un commento