Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Link prefetching FAQ

Questa pagina è in fase di traduzione: contribuisci anche tu completando le parti mancanti. Il testo da tradurre potrebbe essere nascosto nella pagina: vai in modifica per visualizzarlo

 

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.

Cosa sono i prefetching consigliati (prefetching hints)?

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="&lt;/images/big.jpeg&gt;; rel=prefetch">

Il formato dell'intestazione Link: viene descritta nella RFC 2068, sezione 19.6.2.4.

Nota: internamente facciamo riferimento ad una vecchia specifica di HTTP/1.1 dato che la nuova RFC 2616 non descrive l'intestazione 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">

Viene eseguito il prefetch sui tag ancora (<a>)?

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.

Il prefetching è attinente agli standard?

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.

Come viene determinato il periodo di inattività (idle) del browser?

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.

Ci sono restrizioni su cosa viene eseguito il prefetching?

Si, solo gli URL https:// 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.

Mozilla effettua il prefetch di documenti da host differenti?

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.

Le richieste da prefetching contengono una intestazione Refer: ?

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.

Come amministratore di server, posso distinguere tra richieste di prefetch e richieste normali?

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.

C'è una opzione per disabilitare il prefetching di link?

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 ;-)

Aggiornamento: causa la moltitudine di richieste, Mozilla 1.3+ include una opzione di preferenza nell'interfaccia utente per disabilitare il prefetching. Vedere Preferences->Advanced->
user_pref("network.prefetch-next",false);

Riguardo alle persone che pagano per avere banda?

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.

Cos'altro riguardo...?

Per qualasiasi altra domanda o commento riguardo al link prefetching, mandatele pure a me :-)

Vedere inoltre...

Prefetching Hints

Original Document Information

  • Author(s): Darin Fisher (darin at meer dot net)
  • Last Updated Date: Updated: March 3, 2003

Tag del documento e collaboratori

 Hanno collaborato alla realizzazione di questa pagina: artistics-weddings, jigs12, Leofiore
 Ultima modifica di: artistics-weddings,