Link prefetching FAQ

什么是链接预取？

链接预取是一种浏览器机制，其利用浏览器空闲时间来下载或预取用户在不久的将来可能访问的文档。网页向浏览器提供一组预取提示，并在浏览器完成当前页面的加载后开始静默地拉取指定的文档并将其存储在缓存中。当用户访问其中一个预取文档时，便可以快速的从浏览器缓存中得到。

预取是否使用HTTPS？

从 Gecko 1.9.1 (Firefox 3.5) 开始，支持获取 https 内容.

什么是预取提示？

浏览器会查找关系类型(rel)为 next 或 prefetch 的 HTML<link>  或 HTTP Link: header。下面是一个使用 link 标签的例子：

<link rel="prefetch" href="/images/big.jpeg">

同样效果的使用 HTTP Link: header 的例子：

Link: </images/big.jpeg>; rel=prefetch

Link: header 也可以通过使用 HTML meta 标签定义在 HTML 文档中：

<meta http-equiv="Link" content="</images/big.jpeg>; rel=prefetch">

Link: header 的格式在 RFC 5988 section 5 中有所描述。

浏览器检查所有这些预取提示，并将每一个独立的请求排到队列之中，然后浏览器空闲时将对这些请求进行预取。每个页面都可以有多个预取提示，因为预取多个文档是合理的。例如，未来要访问的页面可能包含多张大图。

下面是更多例子：

<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css">
<link rel="next" href="2.html">

a 标签(<a>) 会被预取吗？

不会，只有带有关系类型为 next 或 prefetch 的 <link> 标签会被预拉取。但是，如果该特性收到足够的关注，我们在未来可能会支持带有关系类型为 next 或 prefetch 的 <a> 标签的预取。这样做可能会帮助内容提供者避免预取内容过期的问题。

Is link prefetching standards compliant?

Yes, link prefetching as outlined in this document does not violate any existing web standards. In fact, the HTML 4.01 specification explicitly allows for the definition of new link relation types (see Section 6.12: Link types). However, the exact mechanism employed by Mozilla is not yet standardized. An Internet-Draft is in the works.

Standardization of this technique is part of the scope of HTML 5, see the current working draft, section §5.11.3.13. Link type "prefetch" .

浏览器的空闲时间是如何确定的？

在目前(Moilla 1.2)，空闲时间的确定是通过 nsIWebProgressListener API 实现的。我们在顶层 nsIWebProgress 对象 ("@mozilla.org/docloaderservice;1") 上附加了一个监听器。通过监听器，我们能够收到文档开始和停止的通知，从而将最后一个文档停止到下一个文档开始之间的间隔作为空闲时间的近似值。最后一个文档停止的通知大致会在顶层文档的 onLoad 方法即将被触发时发出。此时即是开始预取的时间点。如果一个子文档包含了预取提示，这些预取操作将会等到最顶层文档和其子文档完成加载后才会开始进行。

资源正在被预载时点击了某个链接会发生什么？

当用户点击一个连接，或开始任何形式的页面加载时，预取操作将被停止且任何预取提示将被丢弃。如果一个预取文档只下载了一部分，那么这部分文档将被保存在缓存中，供服务端发送一个 "Accept-Ranges: bytes" 的返回头。这个返回头通常是由网络服务器在返回静态内容时生成的。当用户真正访问这个已经（部分）预载过的文档时，该文档的剩余部分将被通过一个 HTTP byte-range 的请求获取。

如果后台正在进行下载任务会发生什么？预取会争夺带宽吗？

视情况而定。如果你正在使用 Mozilla 下载某些东西，预取将被推迟到下载结束。例如，如果你尝试加载书签组（将会开启多个浏览器标签），任何由书签组某页面发出的预取请求将被延迟到所有标签加载完毕时进行。如果你正在使用其他依赖网络的应用程序，那么 Mozilla 中的预取可能会与它们竞争带宽。这个问题我们希望将来能够借助操作系统服务去检测网络空闲时间来解决。

对预取内容是否有限制？

是的，只有 http:// (从 Gecko 1.9.1 开始支持 https:// ) 的 URL 可以被预取。其他协议（如 FTP）没有对客户端缓存提供足够的支持。

Mozilla 能够预取不同宿主的文档吗？

可以。预取不受同源限制。限制预取来自同一个服务器并不会对增强浏览器的安全性有所帮助。

Do prefetched requests contain a Referer: header?

Yes, prefetched requests include a HTTP Referer: header indicating the document from which the prefetching hint was extracted.

This may impact referrer tracking that is commonly used on many sites. For this reason, link prefetching may not be appropriate for all content. However, it is possible to instruct Mozilla to validate a prefetched document when the user follows a href to the prefetched document by specifying the Cache-control: must-revalidate HTTP response header. This header enables caching, but requires an If-Modified-Since or If-None-Match validation request before the serving the document out of the browser's cache.

As a server admin, can I distinguish prefetch requests from normal requests?

Yes, we send the following header along with each prefetch request:

X-moz: prefetch

Of course, this request header is not at all standardized, and it may change in future Mozilla releases. Chrome uses "X-Purpose: prefetch" or "Purpose: prefetch" header.

Is there a preference to disable link prefetching?

Yes, there is a hidden preference that you can set to disable link prefetching. Add this line to your prefs.js file located in your profile directory (or make the appropriate change via about:config):

user_pref("network.prefetch-next", false);

However, the theory is that if link prefetching needs to be disabled then there must be something wrong with the implementation. We would rather improve the implementation if it does not work correctly, than expect users to locate and tweak some obscure preference.

What about folks who pay-per-byte for network bandwidth?

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 <link> tag based prefetching instead of trying to roll-in silent downloading using various JS/DOM hacks. The <link> 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 <link> 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.

Which browsers support link prefetching?

Browsers based on Mozilla 1.2 (or later) as well as browsers based on Mozilla 1.0.2 (or later) support prefetching. This includes Firefox and Netscape 7.01+. Camino builds as of March 2003 are based on Mozilla 1.0.1, and therefore do not support prefetching. Test your browser to see if it supports Link Prefetching.

Privacy implications

Along with the referral and URL-following implications already mentioned above, prefetching will generally cause the cookies of the prefetched site to be accessed. (For example, if you google amazon, the google results page will prefetch www.amazon.com, causing amazon cookies to be sent back and forth. You can block 3rd party cookies in Firefox, see Disabling third party cookies.)

What about...?

If you have any questions or comments about link prefetching, please feel free to send them my way :-)

See also...

Prefetching Hints