最近的專案中為了能夠提公升那麼一丟丟效能，嘗試了一下對 chunks 進行預載入處理。雖然做了非同步載入的處理，但是專案大小決定了還是有多個非同步的 chunk.js 需要進行預載入，這裡我指的是 preload與a webpack plugin for injecting into htmlwebpackplugin pages, with async chunk support
複製**
這個外掛程式對字型元素( woff )，自動加了跨域：
原始碼：const crossorigin = asvalue === 'font' ? 'crossorigin="crossorigin" ' : '';
filestoinclude+= `\n`複製**
使用後：
將會在你的 index.html 中的 head標籤裡面新增一堆
這就意味著這些資源都會被預載入，然後從快取中去獲取。將會提公升網頁開啟的效率，但是濫用也會浪費頻寬。
但是實際上還是會造成有我不需要其 preload 的檔案被設定了，這就造成了浪費。
preload 與 prefetch
出現的更早，瀏覽器支援度也挺不錯，通俗的理解是著眼於下乙個頁面資源的預載入，所以在當前頁面的優先順序是很低的。
則是著眼於現在(當前頁面)。瀏覽器遇到 rel= 'preload' 的標籤就會將其推入到預載入器中，這個預載入器也將用於其他我們所需要的，各種各樣的，任意型別的資源。為了完成基本的配置，你還需要通過
引用一段 mdn 的描述： 元素的 preload能夠讓你在你的html頁面中
元素內部書寫一些宣告式的資源獲取請求，可以指明哪些資源是在頁面載入完成後即刻需要的。對於這種即刻需要的資源，你可能希望在頁面載入的生命週期的早期階段就開始獲取，在瀏覽器的主渲染機制介入前就進行預載入。這一機制使得資源可以更早的得到載入並可用，且更不易阻塞頁面的初步渲染，進而提公升效能。本文提供了乙個如何有效使用preload機制的基本說明
其特點是 宣告式的資源獲取請求(fetch)、不易(注意不是不會)阻塞 onload、as 提供的細粒度的控制
總結其優勢：更精確地優化資源載入優先順序，這種方式可以確保資源根據其重要性依次載入。
匹配未來的載入需求，在適當的情況下(相同的資源)，重複利用同一資源。
為資源應用正確的內容安全策略。
為資源設定正確的 accept 請求頭。
注意：忽略 as 屬性，或者錯誤的 as 屬性會使 preload 等同於 xhr 請求，瀏覽器不知道載入的是什麼，因此會賦予此類資源非常低的載入優先順序。
快取既然 preload以及 prefetch都是優先從 http快取中獲取資源，我們必然要接觸很多 304 not modified 響應。
我們先來看乙個 304 響應：
304 中最重要的兩個請求頭就是 if-none-match 和 if-modified-since。
前者的值是上一次響應中返回的 etag，etag是對該資源的一種唯一標識，只要資源有變化，etag就會重新生成。伺服器接收到請求頭中的if-none-match 之後就和檔案資源的 etag做比較，如果一樣，說明資源沒有變化，就返回乙個 304 not modified 並且沒有響應體。客戶端收到 304 響應後,就會從快取中讀取對應的資源，如果不相同，則表示資源發生了改變，那麼伺服器就會返回 http/200 ok 響應,響應體就是該資源當前最新的內容.客戶端收到 200 響應後,就會用新的響應體覆蓋掉舊的快取資源。
後者對應的上一次響應返回的 last-modified。last-modified 是該資源檔案最後一次更改時間，伺服器會在 response header 裡返回，同時瀏覽器會將這個值儲存起來，在下一次傳送請求時，放到 request header 裡的 if-modified-since 裡，伺服器在接收到後也會做比對，如果沒過期則返回304，如果過期則返回200 ok。同樣會更新舊的檔案。
如果兩個頭部都不帶的請求就是無條件(unconditionally)請求該資源,伺服器也就必須返回完整的資源資料。
上面所述的幾個頭部就是協商快取的關鍵人物了。
這裡還要說明乙個概念就是條件請求，所謂條件就是無法確定前端快取資源是否最新，所以通過上述的頭部來做乙個驗證，返回 304 或者 200。通過條件請求我們可以節省出乙個響應體，但是請求還是發出去了。
這裡如果連請求都不想發出去怎麼辦呢?
強快取、協商快取
瀏覽器快取主要有兩類：快取協商和徹底快取，也有稱之為協商快取和強快取。
1.強快取：不會向伺服器傳送請求，直接從快取中讀取資源，在chrome控制台的network選項中可以看到該請求返回200的狀態碼;
2.協商快取：向伺服器傳送請求，伺服器會根據這個請求的request header的一些引數來判斷是否命中協商快取，如果命中，則返回304狀態碼並帶上新的response header通知瀏覽器從快取中讀取資源；
兩者的共同點是，都是從客戶端快取中讀取資源；區別是強快取不會發請求，協商快取會發請求。
瀏覽器快取流程圖：
所以我們可以通過設定 expires( http1.0 ) 以及 cache-control( http1.1 )，來命中強快取，從而跳過傳送請求的過程。
expires：response header裡的過期時間，瀏覽器再次載入資源時，如果在這個過期時間內，則命中強快取。
cache-control：當值設為max-age= 600 時，則代表在這個請求正確返回時間(瀏覽器也會記錄下來)的 10 分鐘內再次載入資源，就會命中強快取。
使用者行為對瀏覽器快取的控制：f5 重新整理，瀏覽器會設定max-age=0，跳過強快取判斷，會進行協商快取判斷。
ctrl + f5, 跳過協商快取與強快取，直接從伺服器拉取資源。
未完待續....
ViewPager Fragment 預載入問題
viewpager 預設載入兩個fragment 左右各乙個 viewpager.setoffscreenpagelimit 1 其中引數可以設為0或者1，引數小於1時，會預設用1來作為引數，未設定之前，viewpager會預設載入兩個fragment,左右各1個。如果要讓fragment 只預載入...
資源預載入
提到前端效能優化時，我們首先會聯想到檔案的合併 壓縮，檔案快取和開啟伺服器端的gzip壓縮等，這使得頁面載入更快，使用者可以盡快使用我們的 web 應用來達到他們的目標。資源預載入是另乙個效能優化技術，我們可以使用該技術來預先告知瀏覽器某些資源可能在將來會被使用到。引用 patrick hamann...
延遲載入和預載入
在網頁剛開始開啟的時候，並沒有載入這些，滾動條移動到一定的位置才載入這些，這就是延遲載入的乙個例子。延遲載入的好處 使用延遲載入節約大量的流量資源。實現預載入的方法 1 將的實際的路徑位置放在xsrc中 2 得到距離視窗頂端的距離 3 獲取螢幕可視區域的最低點的位置 達到的時候實現1 在網頁開啟某一...