提到前端效能優化時，我們首先會聯想到檔案的合併、壓縮，檔案快取和開啟伺服器端的gzip壓縮等，這使得頁面載入更快，使用者可以盡快使用我們的 web 應用來達到他們的目標。
資源預載入是另乙個效能優化技術，我們可以使用該技術來預先告知瀏覽器某些資源可能在將來會被使用到。
引用 @patrick hamann 的解釋：
預載入是瀏覽器對將來可能被使用資源的一種暗示，一些資源可以在當前頁面使用到，一些可能在將來的某些頁面中被使用。作為開發人員，我們比瀏覽器更加了解我們的應用，所以我們可以對我們的核心資源使用該技術。這種做法曾經被稱為prebrowsing，但這並不是一項單一的技術，可以細分為幾個不同的技術：
dns-prefetch、subresource和標準的prefetch、preconnect、prerender。
通過 dns 預解析來告訴瀏覽器未來我們可能從某個特定的url獲取資源，當瀏覽器真正使用到該域中的某個資源時就可以盡快地完成 dns 解析。例如，我們將來可能從example.com獲取或音訊資源，那麼可以在文件頂部的標籤中加入以下內容：
在 @harry roberts 的文章中提到：
通過簡單的一行**就可以告知那些相容的瀏覽器進行 dns 預解析，這意味著當瀏覽器真正請求該域中的某個資源時，dns 的解析就已經完成了。這似乎是乙個非常微小的效能優化，顯得也並非那麼重要，但事實並非如此 —— chrome 一直都做了類似的優化。當在瀏覽器的位址列中輸入
url的一小段時，chrome 就自動完成了 dns 預解析（甚至頁面預渲染），從而為每個請求節省了至關重要的時間。
與 dns 預解析類似，preconnect不僅完成 dns 預解析，同時還將進行 tcp 握手和建立傳輸層協議。可以這樣使用：
現代瀏覽器都試著****將來需要哪些連線，然後預先建立socket連線，從而消除昂貴的 dns 查詢、tcp 握手和 tls 往返開銷。然而，瀏覽器還不夠聰明，並不能準確**每個**的所有預鏈結目標。好在，在 firefox 39 和 chrome 46 中我們可以使用preconnect告訴瀏覽器我們需要進行哪些預連線。
這是另乙個預獲取方式，這種方式指定的預獲取資源具有最高的優先順序，在所有prefetch項之前進行：
所以，如果資源是當前頁面必須的，或者資源需要盡快可用，那麼最好使用rel=prefetch為將來的頁面提供了一種低優先順序的資源預載入方式，而rel=subresource為當前頁面提供了一種高優先順序的資源預載入。
subresource而不是prefetch。
這是乙個核**，因為prerender可以預先載入文件的所有資源：
所有預載入技術都存在乙個潛在的風險：對資源**錯誤，而預載入的開銷（搶占 cpu 資源，消耗電池，浪費頻寬等）是高昂的，所以必須謹慎行事。雖然很難確定使用者下一步將訪問哪些資源，但高可信的場景確實存在：最後，使用 page visibility api 可以防止頁面真正可見前被執行。
preload是乙個新規範，與prefetch不同（可能被忽略）的是，瀏覽器一定會預載入該資源：
☄**使用者下一步將訪問哪些資源是困難的，需要進行大量的測試，但是這帶來的效能提公升是明顯的。如果我們願意嘗試這些預獲取技術，一定會顯著提公升使用者的體驗。
前端效能優化 資源預載入
預載入是瀏覽器對將來可能被使用資源的一種暗示，一些資源可以在當前頁面使用到，一些可能在將來的某些頁面中被使用。作為開發人員，我們比瀏覽器更加了解我們的應用，所以我們可以對我們的核心資源使用該技術。預載入可以拆分成很多小點 dns prefetch,subresource,prefetch,preco...
前端效能優化 資源預載入
預載入是瀏覽器對將來可能被使用資源的一種暗示，一些資源可以在當前頁面使用到，一些可能在將來的某些頁面中被使用。作為開發人員，我們比瀏覽器更加了解我們的 應用，所以我們可以對我們核心資源使用該技術。當提到前端效能優化時，我們首先會聯想到檔案的合併，壓縮，檔案快取和開啟服務端的gzip壓縮等，這使得頁面...
mysql 預載入快取 預載入與快取
最近的專案中為了能夠提公升那麼一丟丟效能，嘗試了一下對 chunks 進行預載入處理。雖然做了非同步載入的處理，但是專案大小決定了還是有多個非同步的 chunk.js 需要進行預載入，這裡我指的是 preload與a webpack plugin for injecting into htmlweb...