Il link prefetching è un meccanismo del browser, che utilizza il tempo di inattività per il download o effettuare ilprefetch dei documenti che l'utente potrebbe visitare in un futuro prossimo. Una pagina web fornisce dei consigli per il prefetching al browser, il quale dopo averla caricata, comincia in silenzio il prefetchinf dei documenti specificati e li memorizza nella sua cache. Quando l'utente visita uno dei documenti precaricati, quest'ultimo viene servito velocemente a partire dalla cache del browser.
Il browser cerca o un tag HTML link o una intestazione HTTP Link: con una relazione tipo next o prefetch. Ecco un esempio usando il tag link:
<link rel="prefetch" href="/images/big.jpeg">
Lo stesso suggerimento di prefetch usando una intestazione Link::
Link: </images/big.jpeg>; rel=prefetch
L'intestazione Link: può anche essere specificata all'interno del documento HTML usando un tag meta:
<meta http-equiv="Link" content="</images/big.jpeg>; rel=prefetch">
Il formato dell'intestazione Link: viene descritta nella RFC 2068, sezione 19.6.2.4.
Link:. Nonostante le intestazioni Link: non siano parte dello standard revisionato, vengono pratiacmente ancora usate dai server per specificare fogli di stile CSS, per questi ne facciamo qui uso.Il browser osserva tutti questi suggerimenti ed mette in attesa ogni richiesta per poi effettuare il prefetching nel periodo di inattività del browser. Possono esserci molteplici suggerumenti per ogni pagina, per cui avrebbe senso precaricare molteplici documenti. Ad esempio, il prossimo documento potrebbe contenere diverse immagini di grandi dimensioni.
Seguono alcuni esempi:
<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css"> <link rel="next" href="2.html">
No, solo i tag <link> con un tipo relazione next o prefetch vengono precaricati. Comunque, in caso di interesse sufficiente, potremmo pensare di estendere il supporto prefetching ai tag <a> che includono un tipo relazione next o prefetch. Fare questo potrebbe aiutare i fornitori di contenuti ad evitare il problema di aggiornare i link precaricati.
Si, il prefetching di link, come descritto in questo documento, non viola nessuno standard web. Infatti, le specifiche HTML 4.01 permettono esplicitamente la definizione di nuovi tipi relazione link (vedere la Sezione 6.12: Link types). Comunque, l'esatto meccanismo usato da Mozilla non è ancora parte dello standard. Un draft è in preparazione.
Nell'implementazione corrente (Mozilla 1.2), il tempo di inattività si determina usando l'API nsIWebProgressListener. Si collega un listener all'oggetto nsIWebProgress ("@mozilla.org/docloaderservice;1"). Da questo, si ricevono notifiche di start e stop, e si approssima il tempo di inattività come il periodo tra l'ultimo documento dal caricamento terminato ed il primo documento dal caricamento iniziato. La notifica dello stop dell'ultimo documento avviene approssimativamente quando il gestore onLoad inizia la sua attività per il documento. Questo accade quando si dà il via a richieste di prefetch. Se un frame figlio contiene suggerimenti di prefetching, il prefetch non inizierà fino a che non siano caricati il documento padre e tutti i figli.
QUando l'utente clicca un link, o inizia un qualche tipo di caricamento di pagina, il prefetch di link si interrompe ed ogni suggerimento di prefetch viene ignorato. Se un documento precaricato è stato parzialmente scaricato, viene comunque memorizzato nella cache se il server invia una intestazione "Accept-Ranges: bytes". Questa intestazione viene tipicamente generata dal webserver nel fornire un documento statico. QUando l'utente visita realmente un documento precaricato, la rimanente porzione del documento viene caricata usando una richiesta HTTP byte-range.
Si e no. Se si sta scaricando qualcosa usando Mozilla, il link prefetching verrà posticipato fino a che i download in background non saranno completati. Ad esempio, se si carica un gruppo di segnalibri (il che significa aprire diverse tab), ogni richiesta di prefetch iniziata da una delle pagine di segnalibro non inizierà fino a quando tutte le tab non avranno terminato il caricamento. Se si usa un'altra applicazione di rete, il link prefetching potrebbe competere per la banda con l'altra applicazione. Questo è un problema che speriamo di risolvere in futuro usando i servizi del sistema operativo per controllare il tempo di inattività della connesione.
Si, solo gli URL http:// possono essere precaricati (URL https:// non sono mai precaricato per ragioni di sicurezza). Altri protocolli (come FTP) non forniscono un supporto abbastanza ricco per il caching da lato client. In aggiunta a questa restrizione, gli URL conquery strings (stringhe di interrogazione) non sono precaricate. Questo perché alcuni URL inviano a documenti che non possono essere riutilizzati fuori dalla cache del browser, per cui il prefetching non darebbe grandi risultati. Abbiamo visto come siti esistenti utilizzino il tag <link rel="next"> con degli URL contenenti query string per fare riferimento al prossimo documento di una serie. Bugzilla ne è un esempio, e questo fa si che i sui report non siano memorizzabili in cache, per cui il prefetch degli URL raddoppierebbe il carico del server del pover Bugzilla! Si possono failmente pensare che altri siti siano stati progettati come Bugzilla, per cui noi esplicitamente non facciamo eseguire il prefetch degli URL con query string. (Avrebbe sensio permettere il prefecth di questi documenti quando è specificato il tipo relazione rel=prefetch, dato che non dovrebbe apparire in nessun contenuto esistente.) Non ci sono altre restrizioni sugli URL precaricati.
Si. Non ci sono restrizioni sull'origine dei documenti per il link prefetching. Litare il prefetching solo agli URL dello stesso server non offrirebbe nessun aumento della sicurezza del browser.
Sì, le richieste da prefetch includono una intestazione HTTP Referer: indicante il documento dal quale il suggerimento di prefetch è stato estratto.
Questo potrebbe avere impatto sul tracciamento dei refer solitamente usato in molti siti. Per questo, il link prefetching potrebbe non essere appropriato per tutti i contenuti. Comunque, è possibile istruire Mozilla per validare un documento precaricato quando l'utente segue un href verso il documento precaricato, specificando l'intestazione HTTP Cache-control: must-revalidate. Questa intestazione abilita la memorizzazione in cache, ma ha necessita di una richiesta di validazione If-Modified-Since o If-None-Match prima di servire il documento dalla cache stessa.
Si, mandiamo la seguente intestazione insieme con la richiesta di prefetch:
X-moz: prefetch
Ovviamente, questa intestazione di richiesta non è del tutto standard, e potrebbe cambiare in future release di Mozilla.
Si, c'è una preferenza nascosta da impostare per disabilatare il link prefetching. Aggiungere questa linea a prefs.js nella directory del proprio profilo di Mozilla.
user_pref("network.prefetch-next",false);
Stiamo considerando di aggiungere una Interfaccia Utente per questa preferenza (vedere {{ Bug(166648) }}); in ogni caso, la nostra teoria è che se il link prefetching deve essere disabilitato allora qualcosa è sagliato nella sua implementazione. Cerchiamo di migliorare l'implementazione se questa si rivelasse errata, piuttosto che attenderci che gli utenti vadano a cercare qualche oscura voce di preferenza nell'interfaccia uente. Diamine, l'interfaccia utente di Mozilla per le opzioni è già abbastanza piena ;-)
user_pref("network.prefetch-next",false);
Basically, there are two ways of looking at this issue: # websites can already cause things to be silently downloaded using JS/DOM hacks. # prefetching is a browser feature; users should be able to disable it easily. It is important that websites adopt <code><link></code> tag based prefetching instead of trying to roll-in silent downloading using various JS/DOM hacks. The <code><link></code> tag gives the browser the ability to know what sites are up to, and we can use this information to better prioritize document prefetching. The user preference to disable <code><link></code> tag prefetching may simply encourage websites to stick with JS/DOM hacks, and that would not be good for users. This is one reason why prefetching is enabled by default.
I browser basati su Mozilla 1.2 (o successivi) così come browser basati su Mozilla 1.0.2 (o successivi) supportano il prefetching. Questo include Firefox e Netscape 7.01+. Le build di Camino da Marzo 2003 sono basate su Mozilla 1.0.1, pre cui non supportano il prefetching.
Effettua un test con il tuo browser per vedere se supporta il Link Prefetching.
Per qualasiasi altra domanda o commento riguardo al link prefetching, mandatele pure a me :-)
{{ languages( { "en": "en/Link_prefetching_FAQ" } ) }}