Data di pubblicazione: 23 gennaio 2026
A partire da Chrome 144, Chrome lancerà una nuova prova dell'origine per l'aggiunta della funzionalità prerender until script all'API Speculation Rules. Questa origin trial consente ai siti di provare la nuova aggiunta con utenti reali. L'obiettivo è testare la funzionalità sul campo e fornire al team di Chrome un feedback per contribuire a definirla e decidere se è qualcosa da aggiungere alla piattaforma web.
Quale problema si intende risolvere?
L'API Speculation Rules consente di avviare i caricamenti delle pagine prima che gli utenti accedano effettivamente alle pagine. In questo modo, i caricamenti delle pagine futuri possono essere migliorati completando in anticipo alcune o tutte le operazioni. Finora ha consentito due tipi di speculazioni: prefetch e prerender.
Il prefetching recupera solo il documento HTML. In questo modo, la prima risorsa critica viene recuperata in anticipo, il che migliora le prestazioni quando si passa a un URL. Non carica alcuna risorsa secondaria (ad esempio CSS, JavaScript o immagini), né esegue JavaScript, pertanto il browser potrebbe dover svolgere ancora un lavoro considerevole durante i caricamenti delle pagine.
Il prerendering fa molto di più. Recupera le risorse secondarie e inizia a eseguire il rendering della pagina e JavaScript, quasi come se la pagina fosse aperta in una scheda di background nascosta. Quando l'utente fa clic sul link, può ottenere una navigazione istantanea se il browser ha completato tutto il lavoro necessario per il rendering della pagina.
L'utilizzo dell'opzione di prerendering è potenzialmente molto migliore per le prestazioni, ma comporta costi di implementazione aggiuntivi, nonché costi aggiuntivi per le risorse. Se non viene valutato attentamente, questo può anche causare effetti collaterali imprevisti durante il prerendering completo di una pagina prima che un utente abbia effettivamente raggiunto la pagina. Ad esempio, Analytics potrebbe attivarsi prima che un utente abbia navigato, falsando le statistiche, se il fornitore di Analytics non tiene conto delle speculazioni.
I siti che utilizzano il prerendering devono anche fare attenzione a non mostrare agli utenti una pagina obsoleta. Ad esempio, se esegui la precarica di una pagina su un sito di e-commerce, aggiungi un articolo al carrello e poi carichi la pagina precaricata in precedenza, potresti visualizzare la vecchia quantità nel carrello se il sito non presta particolare attenzione per assicurarsi che venga aggiornata.
Queste complicazioni esistono anche per il prefetch se parte della gestione dello stato avviene lato server, ma spesso rappresentano un problema più grande per il prerendering. L'utilizzo del prerendering su siti più complessi può essere più complicato.
Tuttavia, gli sviluppatori ci dicono di aver già notato i miglioramenti del rendimento grazie al pre-fetching della pagina e vogliono fare di più con le regole di speculazione per ottenere ancora più vantaggi. È qui che entra in gioco il prerendering fino allo script.
Che cos'è il prerendering fino allo script?
Prerender until script è una nuova via di mezzo tra prefetch e prerender. Recupera in anticipo il documento HTML (come fa il prefetch) e poi inizia il rendering della pagina, incluso il recupero di tutte le risorse secondarie (come fa il prerendering). Tuttavia, il browser eviterà l'esecuzione degli elementi <script> (sia per gli script incorporati che per gli script src). Quando rileva un tag <script> di blocco, mette in pausa il parser e attende che l'utente acceda alla pagina prima di continuare. Nel frattempo, lo scanner di precaricamento può continuare a recuperare le risorse secondarie necessarie alla pagina, in modo che siano pronte per l'uso quando la pagina può continuare a caricarsi.
Se non vengono utilizzati elementi di blocco <script>, si evita gran parte della complessità dell'implementazione. Allo stesso tempo, avviando il processo di rendering e recuperando le risorse secondarie, si ottiene un enorme vantaggio rispetto al prefetch, potenzialmente quasi quanto un prerender completo.
Nel migliore dei casi (quando nella pagina non sono presenti script), questa opzione pre-renderizza l'intera pagina. In alternativa, quando una pagina ha solo elementi di script nel piè di pagina o solo script con attributi async o defer, il prerendering della pagina verrà eseguito completamente senza JavaScript. Anche nello scenario peggiore (in cui è presente uno script di blocco in <head>), l'inizio del rendering della pagina e, in particolare, il recupero preliminare delle risorse secondarie, dovrebbe portare a un caricamento della pagina molto più rapido.
Come utilizzare il prerendering fino allo script?
Innanzitutto, attiva la funzionalità, quindi esegui il prerendering finché lo script non viene utilizzato nello stesso modo delle altre opzioni dell'API Speculation Rules con una nuova chiave prerender_until_script (nota i trattini bassi per renderlo un nome di chiave JSON valido).
Può essere utilizzato con le regole di elenco degli URL statici:
<script type="speculationrules">
{
"prerender_until_script": [{
"urls": ["next.html", "next2.html"]
}]
}
</script>
Può essere utilizzato anche con le regole per i documenti in cui gli URL da speculare sono disponibili come link nella pagina:
<script type="speculationrules">
{
"prerender_until_script": [{
"where": { "href_matches": "/*" }
}]
}
</script>
Il prerendering fino allo script può essere utilizzato con le solite opzioni dell'API Speculation Rules, inclusi i vari valori di impazienza.
Poiché JavaScript non verrà eseguito, non è possibile leggere document.prerendering e nemmeno l'evento prerenderingchange. Tuttavia, il tempo activationStart sarà diverso da zero.
Il seguente esempio mostra come eseguire il deployment dell'esempio precedente con un fallback al recupero preliminare per i browser che non supportano prerender_until_script:
<script type="speculationrules">
{
"prerender_until_script": [{
"where": { "href_matches": "/*" }
}],
"prefetch": [{
"where": { "href_matches": "/*" }
}]
}
</script>
Chrome gestirà questa duplicazione senza problemi ed eseguirà la regola più appropriata per ogni impostazione di impazienza.
In alternativa, puoi utilizzarli con diversi livelli di priorità per eseguire il prefetch in modo proattivo e poi eseguire l'upgrade al prerendering fino a quando lo script con più indicatori come suggerito in precedenza con prefetch/prerender:
<script type="speculationrules">
{
"prefetch": [{
"where": { "href_matches": "/*" },
"eagerness": "eager"
}],
"prerender_until_script": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
Tieni presente che non puoi eseguire l'upgrade di un prerendering fino allo script a un prerendering completo in questo modo, ma comunicacelo se questo è un pattern che ti interessa che Chrome supporti assegnando una stella a questo bug.
Tutto JavaScript è in pausa?
No, solo gli elementi <script> causano la sospensione dell'analizzatore sintattico. Ciò significa che i gestori di script incorporati (ad esempio onload) o gli URL javascript: non causano una pausa e potrebbero essere eseguiti.
Ad esempio, può registrare Hero image is now loaded nella console prima di passare alla pagina:
<img src="hero.jpg"
onload="console.log('Hero image is now loaded!')"
alt="Example Photo">
Se invece il listener di eventi viene aggiunto con un <script>, Hero image is now loaded non verrà registrato nella console finché la pagina non viene attivata:
<img src="hero.jpg" id="hero-image" alt="Example Photo">
<script>
const heroImage = document.querySelector('#hero-image');
if (heroImage.complete) {
console.log('Hero image is now loaded');
} else {
heroImage.addEventListener('load',
(event) => {
console.log('Hero image is now loaded');
}
);
}
</script>
Potrebbe sembrare controintuitivo, ma in molti casi (come nell'esempio precedente) è probabilmente meglio intraprendere l'azione immediatamente, in quanto ritardarla potrebbe portare a complicazioni più inaspettate.
Inoltre, la maggior parte degli eventi in linea richiede un'azione dell'utente (ad esempio onclick, onhover) e quindi non verrà eseguita finché l'utente non potrà interagire con la pagina.
Infine, gli script di blocco precedenti mettono in pausa il parser e impediscono il rilevamento dei gestori di eventi incorporati. Pertanto, il messaggio non verrà caricato nella console fino all'attivazione, nonostante sia un gestore di eventi incorporato:
<script>...</script>
<img src="hero.jpg"
onload="console.log('Hero image is now loaded!')"
alt="Example Photo">
Ciò è particolarmente importante per i gestori di script incorporati che utilizzano codice definito in precedenza, che continuerà a funzionare come previsto:
<script>
imageLoadFunction() = {
...
}
</script>
<img src="hero.jpg" onload="imageLoadFunction" alt="Example Photo">
Che dire degli script con gli attributi async e defer?
Gli script con gli attributi async e defer vengono ritardati fino all'attivazione, ma non impediscono al parser di continuare a elaborare il resto della pagina. Gli script vengono scaricati, ma non eseguiti finché non viene visualizzata la pagina.
Come attivare il prerendering fino allo script?
Il prerendering fino allo script è una nuova opzione su cui stiamo lavorando e che è soggetta a modifiche, pertanto non è disponibile per l'uso senza prima abilitarla per l'attivazione.
Può essere attivato localmente per lo sviluppatore con il flag di Chrome chrome://flags/#prerender-until-script o con il flag della riga di comando --enable-features=PrerenderUntilScript.
Il prerendering fino allo script è ora disponibile anche come prova dell'origine a partire da Chrome 144. Le prove dell'origine consentono ai proprietari dei siti di attivare una funzionalità sui loro siti in modo che gli utenti reali possano utilizzarla senza doverla attivare manualmente. In questo modo, l'impatto della funzionalità può essere misurato sugli utenti reali per garantire che funzioni come previsto.
Provalo e condividi il tuo feedback
Siamo molto entusiasti di questa proposta di aggiunta all'API Speculation Rules e invitiamo i proprietari dei siti a provarla.
Condividi il tuo feedback sulla proposta nel repository GitHub. Per fornire feedback sull'implementazione di Chrome, segnala un bug di Chromium.