編輯于2015年
Patrick Hamann 對此的說明：
Pre-fetching會提示瀏覽器那些未來一定或可能使用到的資源，有時在當前頁面見效，有些則在未來可能打開的頁面生效。 作為開發者，我們比瀏覽器更懂自己的應用。我們可以利用這些技術提前告知瀏覽器web中用到的核心資源。
以前這種實踐也被稱為『prebrowsing』。但這并不是一種單一的技術，實際上可以拆分成很多小點：dns-prefetch, subresource, prefetch, preconnect, 和 prerender.
DNS prefetch
DNS prefetching通過指定具體的URL來告知客戶端未來會用到相關的資源，這樣瀏覽器可以盡早的解析DNS。比如我們需要一個在example.com的圖片或者視頻文件。在<head>就可以這么寫：
<link rel="dns-prefetch" >
當請求這個域名下的文件時就不需要等待DNS查詢了。項目中有用到第三方的代碼時這么做尤其有益（譯者注：其他的使用場景，比如當靜態資源和HTML不在一個域上，而在CDN上；又比如在重定向前可以加上DNS prefetch）。
Harry Roberts在他的前端性能優化文章中建議：
簡單的一行就能讓支持的瀏覽器提前解析DNS。也就是說在瀏覽器請求資源時，DNS查詢就已經準備好了。
這可能看起來是個非常微不足道的性能提升，而且還不是必須的–Chrome總是會做類似的處理，用戶只要在地址欄敲入一部分域名，如果命中了歷史常用的網站，Chrome就會提前解析DNS、預拉取頁面。（譯者注：效果確實有限，但是聊勝于無）
Preconnect
和DNS prefetch類似，preconnect不光會解析DNS，還會建立TCP握手連接和TLS協議（如果需要）。用法如下：
<link rel="preconnect" >
Ilya Grigorik寫了一篇文章詳細說明了這種技術：
現代瀏覽器竭盡所能的嘗試預測網站可能需要哪些鏈接。通過提前連接，瀏覽器可以提前建立必要的通信，消除了實際請求中DNS、TCP和TLS的耗時。不過，即使是只能的現代瀏覽器，也沒辦法為每個網站可靠的預測所有連接。
幸運的是開發者可以告訴瀏覽器哪些通信需要在實際請求發起前就提前建立連接。
舉個栗子：
上半張圖顯示了瀏覽器先拉html、再拉CSS并建立好CSSOM后，發現需要兩個外鏈的字體（在fonts.gstatic.com上）,然后瀏覽器開始發起兩個請求，具體來說，需要對這個域進行DNS解析、TCP和TLS握手（一個建立后可以復用給另一個連接）。
<link rel='preconnect' crossorigin>
<link rel='stylesheet'>
下半張圖增加了上面的代碼來從fonts.gstatic.com preconnect資源。可以看到，瀏覽器在請求CSS的同時并行的建立字體資源需要的連接，等到真正開始需要字體時立刻就開始返回數據。
更多詳細的內容可以參考Ilya Grigorik的文章。
目前只支持Firefox 39+和Chrome 46+，具體參見caniuse
Prefetch
當能確定網頁在未來一定會使用到某個資源時，開發者可以讓瀏覽器提前請求并且緩存好以供后續使用。prefetch支持預拉取圖片、腳本或者任何可以被瀏覽器緩存的資源。
不同于DNS prefetch，上面的寫法可是會去請求、下載資源并且緩存起來。當然也是有一些發生條件的。比如，客戶端可能會在弱網絡下不去請求較大的字體文件，Firefox則只會在瀏覽器空閑的時候prefetch資源（譯者注：這里是MDN上對瀏覽器空閑的定義和一些FAQ，建議閱讀）。
正如Bram Stein在他的文章中指出，prefetch很適用于優化webfonts的性能。以前，字體文件必須等DOM和CSSOM創建好后才能下載，可如果prefetch了字體，這個瓶頸就能輕松解決了。
注意：prefetch并沒有同域的限制
Subresource
subresource可以用來指定資源是最高優先級的。比如，在Chrome和Opera中我們可以加上下面的代碼：
<link rel="subresource" href="styles.css">
Chromium的文檔這么解釋：
和 "Link rel=prefetch"的語義不同，"Link rel=subresource"是一種新的連接關系。rel=prefetch指定了下載后續頁面用到資源的低優先級，而rel=subresource則是指定當前頁面資源的提前加載。
所以，如果資源是在當前頁面需要，或者馬上就會用到，則推薦用subresource，否則還是用prefetch。
Prerender
prerender是一個重量級的選項，它可以讓瀏覽器提前加載指定頁面的所有資源。
<link rel="prerender" href="/thenextpage.html" />
Steve Souders的文章詳細解釋了這個技術：
prerender就像是在后臺打開了一個隱藏的tab，會下載所有的資源、創建DOM、渲染頁面、執行JS等等。如果用戶進入指定的鏈接，隱藏的這個頁面就會進入馬上進入用戶的視線。Google Search多年前就利用了這個特性實現了Instant Pages功能。微軟最近也宣布會讓Bing在IE11上用類似prerender的技術。
但是要注意，一定要在十分確定用戶回點某個鏈接時才用這個特性，否則客戶端就會無端的下載很多資源和渲染這個頁面。
正如任何提前的動作一樣，預判總是有一定風險出錯。如果提前的動作是昂貴的（比如高CPU、耗電、占用帶寬），就要謹慎使用了。雖然不容易預判用戶會點進哪個頁面，但還是存在一些典型的場景：
如果用戶搜索到了一個明顯正確的結果時，那么這個頁面就很有可能被點入
如果用戶在登錄頁面，那么登錄成功后的頁面就很可能接下來會被加載了
如果用戶在閱讀一個多頁面的文章或者有頁碼的內容時，下一頁就很可能會馬上被點擊了
利用Page Visibility API可以用來防止頁面在還沒真正展示給用戶時就觸發了JS的執行。
