Link prefetching FAQ

link prefetching이란?

'link prefetching'는 브라우저가 유휴시간(idle time)을 이용해서 사용자가 앞으로 방문하게 될 문서를 다운로드 혹은 프리패치(prefetch[선취]:현재의 명령을 실행하면서 다음 실행할 여러 명령을 판독하여 명령을 스케줄링하는 방식)하는 브라우저 매커니즘(browser mechanism)입니다. 웹문서는 프리패치 힌트(prefetching hints)를 제공하고 브라우저가 문서 로딩이 끝난 후에 조용히 명시된 문서를 프리패치한 후 브라우저캐쉬로 저장합니다. 그리고 사용자가 프리패치된 문서를 방문할 때 브라우저는 브라우저캐쉬를 이용하여 빠르게 문서를 로딩 할 수 있습니다.

prefetching hints란?

브라우저는 HTML의 link 태그나 HTTP 헤더에서 next or prefetch타입과 관련 있는 Link:정보를 찾아봅니다. link 태그를 사용하는 예제는 아래와 같습니다:

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

HTTP 헤더의 Link:를 아래와 같이 사용하여 위와 같이 동작시킬 수 있습니다.

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

The Link: 헤더정보는 HTML문서 안에서 meta 태그를 사용해서 명시할 수 도 있습니다.

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

the Link 헤더에 대한 자세한 내용은 RFC 2068 section 19.6.2.4.에 기술되어 있습니다.

브라우저는 이러한 hint들을 탐지하여 브라우저 유휴시간에 해당 내용을 prefetching하기 위해서 각각의 request를 queue에 저장합니다. 여러 문서를 prefetching하는 것도 가능하기 때문에 한 페이지에 여러개의 hint가 존재할 수 있습니다. 예를 들어서 다음 문서가 몇개의 큰 이미지들을 가지고 있을 수 있습니다.  

예제:

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

(<a>) 태그가 prefetching 되나요?

아니오. 오로지 <link> 태그만 prefetching이 가능합니다. 하지만 충분한 요구가 있다면 추후에 (<a>)태그가 prefetching이 되도록 만드는 것도 고려하고 있습니다.  그렇게 구현하는 것이 컨텐츠제공자들에게 표준이 아닌 prefetching link를 사용해야하는 문제를 우회할 수 있도록 할 수 있을 것입니다.

link prefetching이 표준을 따르나요?

예. 이 문서의 핵심개념인 link prefetching은 웹표준을 어기고 있지 않습니다. 실제로, HTML 4.01 명세에서는 새로운 link relation types을 정의하는 것을 허락하고 있습니다. (참조 Section 6.12: Link types). 그러나 모질라에서 사용하고 있는 매커니즘은 아직 표준으로 채택되지는 않았습니다.. 현재 드래프트로 남아있습니다.

이 기술을 표준화하는 작업은 HTML 5의 범위의 일부분에 속해있습니다. 다음 working draft문서를 참조하세요. section §5.11.3.13. Link type "prefetch" .

브라우저 유휴시간은 어떻게 정의하나요?

현재 (Mozilla 1.2)에서는, 유휴시간은 nsIWebProgressListener API을 통해서 정의되고 있습니다. 최상위 nsIWebProgress object("@mozilla.org/docloaderservice;1")에 리스너를 등록합니다.  이 리스너를 통해서 문서가 시작되고 멈추는지를 알 수 있습니다. 대략적으로 마지막 문서가 멈추고 다음 문서가 시작되기전을 유휴시간으로 정의하고 있습니다. 최상위 문서의 onload핸들러의 실행이 끝날때 마지막 문서가 멈추는 것을 아는 방법은 러프하게 알수 있습니다. 이 때 prefetch request를 전송하기 시작합니다. 만약에 하위프레임이 prefetching 힌트들을 포함하고 있다면, 하위프레임들의 로딩이 끝날때까지 prefetching은 시작되지 않을 것입니다.

prefetching중에 link를 클릭했을때 어떻게 되나요?

사용자가 link를 하거나 어떤식으로든 페이지를 로딩하게 되었을때 link prefetching는 멈추게 되고 prefetch 힌트들은 폐기될것입니다. 만약에 어떤 문서의 일부가 다운로드되었다면 그 문서의 일부분은 캐쉬영역에 저장될것이고 서버에 "Accept-Ranges: bytes"를 제공할 것입니다. 이 헤더정보는 보통 스태틱 컴퍼넌트를 제공할때  웹서버에서 생성되는 정보입니다. 사용자가 prefetching된 문서에 실제로 접근할 때 남아있는 부분이 HTTP byte-range request를 사용하여 다운로드될 것입니다.  

파일다운로드중이라면 link prefetching을 하게 될 때 네트웍 사용을 위해 경쟁(??)하나요???

예 그리고 아니오. 만약에 모질라를 이용하여 다운로드중이라면, 해당 파일다운로드가 완료되기전까지 link prefetching은 시작되지 않을 것입니다. 예를 들어, if you load a bookmark group (which opens several tabs), any prefetch requests initiated by one of the bookmarked pages will not begin until all of the tabs finish loading. If you are using another application which uses the network, link prefetching in Mozilla may compete for bandwidth with the other application. This is a problem that we hope to address in the future by leveraging operating system services to monitor network idle time.

Are there any restrictions on what is prefetched?

Yes, only https:// URLs can be prefetched (https:// URLs are never prefetched for security reasons). Other protocols (such as FTP) do not provide rich enough support for client side caching. In addition to this restriction, URLs with a query string are not prefetched. This is done because such URLs often result in documents that cannot be reused out of the browser's cache, so prefetching them often has little benefit. We found that some existing sites utilize the <link rel="next"> tag with URLs containing query strings to reference the next document in a series of documents. Bugzilla is an example of such a site that does this, and it turns out that the Bugzilla bug reports are not cachable, so prefetching these URLs would nearly double the load on poor Bugzilla! It's easy to imagine other sites being designed like Bugzilla, so we explicitly do not prefetch URLs with query strings. (It might make sense to allow prefetching of these documents when the rel=prefetch relation type is specified, since this should not appear in any existing content.) There are no other restrictions on the URLs that are prefetched.

Will Mozilla prefetch documents from a different host?

Yes. There is no same-origin restriction for link prefetching. Limiting prefetching to only URLs from the the same server would not offer any increased browser security.

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.

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, seeDisabling 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