資訊專欄INFORMATION COLUMN
摘要：和可以用來指定資源是最高優(yōu)先級的。如果用戶進入指定的鏈接，隱藏的這個頁面就會進入馬上進入用戶的視線。微軟最近也宣布會讓在上用類似的技術。
預加載
現(xiàn)在的網(wǎng)絡情況雖然很樂觀，但是
defer和async當瀏覽器碰到 script 腳本的時候：
沒有 defer 或 async，瀏覽器會立即加載并執(zhí)行指定的腳本，“立即”指的是在渲染該 script 標簽之下的文檔元素之前，也就是說不等待后續(xù)載入的文檔元素，讀到就加載并執(zhí)行。
有 async，加載和渲染后續(xù)文檔元素的過程將和 script.js 的加載與執(zhí)行并行進行（異步）。
有 defer，加載后續(xù)文檔元素的過程將和 script.js 的加載并行進行（異步），但是 script.js 的執(zhí)行要在所有元素解析完成之后，DOMContentLoaded 事件觸發(fā)之前完成。
然后從實用角度來說呢，首先把所有腳本都丟到
接著，我們來看一張圖咯：
此圖告訴我們以下幾個要點：
defer 和 async 在網(wǎng)絡讀?。ㄏ螺d）這塊兒是一樣的，都是異步的（相較于 HTML 解析）
它倆的差別在于腳本下載完之后何時執(zhí)行，顯然 defer 是最接近我們對于應用腳本加載和執(zhí)行的要求的
關于 defer，此圖未盡之處在于它是按照加載順序執(zhí)行腳本的，這一點要善加利用
async 則是一個亂序執(zhí)行的主，反正對它來說腳本的加載和執(zhí)行是緊緊挨著的，所以不管你聲明的順序如何，只要它加載完了就會立刻執(zhí)行
仔細想想，async 對于應用腳本的用處不大，因為它完全不考慮依賴（哪怕是最低級的順序執(zhí)行），不過它對于那些可以不依賴任何腳本或不被任何腳本依賴的腳本來說卻是非常合適的，
preload和refetchpreload通常在頁面中，我們需要加載一些腳本和樣式，而使用 preload 可以對當前頁面所需的腳本、樣式等資源進行預加載，而無需等到解析到 script 和 link 標簽時才進行加載。這一機制使得資源可以更早的得到加載并可用，且更不易阻塞頁面的初步渲染，進而提升性能。
使用方式
將 link 標簽的 rel 屬性的值設為 preload，as 屬性的值為資源類型（如腳本為 script，樣式表為 style）
preload example
prefetch與 preload 一樣，都是對資源進行預加載，但是 prefetch 加載的資源一般不是用于當前頁面的，即未來很可能用到的這樣一些資源，簡單點說就是其他頁面會用到的資源。當然，prefetch 不會像 preload 一樣，在頁面渲染的時候加載資源，而是利用瀏覽器空閑時間來下載。當進入下一頁面，就可直接從 disk cache 里面取，既不影響當前頁面的渲染，又提高了其他頁面加載渲染的速度。
使用方式
同 preload 很相似，無需指定 as 屬性：
preload example
總結:對當前頁面需要的資源，使用 preload 進行預加載，對其它頁面需要的資源進行 prefetch 預加載。
Subresource和Prerendersubresource可以用來指定資源是最高優(yōu)先級的。比如，在Chrome和Opera中我們可以加上下面的代碼：
Chromium的文檔這么解釋：
和 "Link rel=prefetch"的語義不同，"Link rel=subresource"是一種新的連接關系。rel=prefetch指定了下載后續(xù)頁面用到資源的低優(yōu)先級，而rel=subresource則是指定當前頁面資源的提前加載。
所以，如果資源是在當前頁面需要，或者馬上就會用到，則推薦用subresource，否則還是用prefetch。
prerender是一個重量級的選項，它可以讓瀏覽器提前加載指定頁面的所有資源。
Steve Souders的文章詳細解釋了這個技術：
prerender就像是在后臺打開了一個隱藏的tab，會下載所有的資源、創(chuàng)建DOM、渲染頁面、執(zhí)行JS等等。如果用戶進入指定的鏈接，隱藏的這個頁面就會進入馬上進入用戶的視線。Google Search多年前就利用了這個特性實現(xiàn)了Instant Pages功能。微軟最近也宣布會讓Bing在IE11上用類似prerender的技術。
但是要注意，一定要在十分確定用戶回點某個鏈接時才用這個特性，否則客戶端就會無端的下載很多資源和渲染這個頁面。
正如任何提前的動作一樣，預判總是有一定風險出錯。如果提前的動作是昂貴的（比如高CPU、耗電、占用帶寬），就要謹慎使用了。雖然不容易預判用戶會點進哪個頁面，但還是存在一些典型的場景：
如果用戶搜索到了一個明顯正確的結果時，那么這個頁面就很有可能被點入
如果用戶在登錄頁面，那么登錄成功后的頁面就很可能接下來會被加載了
如果用戶在閱讀一個多頁面的文章或者有頁碼的內容時，下一頁就很可能會馬上被點擊了
利用Page Visibility API可以用來防止頁面在還沒真正展示給用戶時就觸發(fā)了JS的執(zhí)行。
參考：
defer和async
prefetch與 preload
prefetch預加載
preload當即加載
加載技術概述
dnc fetch
Prerender Subresource
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/114181.html
摘要：搜索了相關的資料后對其有了些認識，在此記錄一下。這一機制使得資源可以更早的得到加載并可用，且更不易阻塞頁面的初步渲染，進而提升性能。當進入下一頁面，就可直接從里面取，既不影響當前頁面的渲染，又提高了其他頁面加載渲染的速度。 原文地址在 我的筆記里，覺得還行就給個 star 吧：） 關于 preload 和 prefetch 早有耳聞，知道它們可以優(yōu)化頁面加載速度，然具體情況卻了解不多。...
摘要：搜索了相關的資料后對其有了些認識，在此記錄一下。這一機制使得資源可以更早的得到加載并可用，且更不易阻塞頁面的初步渲染，進而提升性能。當進入下一頁面，就可直接從里面取，既不影響當前頁面的渲染，又提高了其他頁面加載渲染的速度。 原文地址在 我的筆記里，覺得還行就給個 star 吧：） 關于 preload 和 prefetch 早有耳聞，知道它們可以優(yōu)化頁面加載速度，然具體情況卻了解不多。...
摘要：例如，將獲得最高優(yōu)先級，而將獲得低優(yōu)先級或中優(yōu)先級。不帶屬性的的優(yōu)先級將會等同于異步請求。對使用屬性，不然將不會從中獲益。因此，在標記中聲明以被掃描器掃描。 這是 Web 性能優(yōu)化的第 6 篇，上一篇在下面看點擊查看： Web 性能優(yōu)化：使用 Webpack 分離數(shù)據(jù)的正確方法 Web 性能優(yōu)化：圖片優(yōu)化讓網(wǎng)站大小減少 62% Web 性能優(yōu)化：緩存 React 事件來提高性能 We...
摘要：緊接著發(fā)現(xiàn)，于是又停了，瀏覽器下載并執(zhí)行完，繼續(xù)。，發(fā)現(xiàn)，遂將中文字展示了出來。的執(zhí)行時間是在所有元素解析完成之后，事件觸發(fā)之前。的執(zhí)行時間是在當前腳本下載完成后，所以多個是執(zhí)行順序是不固定的。至此，完美的結構出爐了。 現(xiàn)代瀏覽器性能優(yōu)化-JS篇 眾所周知，JS的加載和執(zhí)行會阻塞瀏覽器渲染，所以目前業(yè)界普遍推薦把script放到之前，以解決js執(zhí)行時找不到dom等問題。但隨著現(xiàn)代瀏覽器...
閱讀 2750·2021-11-25 09:43
閱讀 2111·2021-11-18 13:25
閱讀 4572·2021-09-22 15:52
閱讀 1870·2021-09-22 15:49
閱讀 2216·2019-08-30 15:54
閱讀 3011·2019-08-29 17:13
閱讀 2317·2019-08-29 16:54
閱讀 2259·2019-08-29 12:58
