資訊專欄INFORMATION COLUMN
摘要：文件路徑，上線后，絲絲潤滑無痛無癢，完美第四個版本，可以做更多注意哦，重點來咯盡早加載是減少首屏時間的關鍵引申閱讀，直接把到里是個不錯的方案。
第一個版本，簡單粗暴有點痛所謂 File Prefetching 就是在一個頁面加載成功后，默默去預加載后續可能會被訪問到的頁面的資源。
前端資源預加載其實沒啥新鮮的，我們倒騰這個事情的過程卻是很有有意思也很有啟發性。
1、建一個獨立的頁面，里面索引了各種需要預加載的css、js，代碼類似下面這樣。
...其他需要預加載的css
...其他需要預加載的js
2、 在每個頁面加入一個iframe（一般通過base模板統一加），這樣每個頁面打開的時候都會加載上面這個頁面。假設上面的頁面的url是 https://xxx.com/common/prefetching.html 那么我們每個頁面底部都有這么一行代碼：
如何驗證要驗證某個file prefetching的方案是否真的有效，無非就是以下幾步：
（假設A頁面使用了showcase_d0fbaaef124a8691398704216ccd469a.css，而B頁面不會）
讓chrome終端打開的時候cache功能依舊有效
清空所有本地cache
打開B頁面，在控制臺Networking里看prefetching.html以及附屬的資源文件是否被下載了
打開A頁面，注意：是在地址欄里輸入A的網址然后回車，不要打開A頁面后習慣性地按Command/Ctrl+R來刷新，不出意外，我們會看到如下圖這樣的結果：
這說明，這2個css文件是從cache里讀的。如果Command/Ctrl+R來刷新頁面，我們會看到這樣的結果：
兩者的差別是，Command/Ctrl+R的時候，瀏覽器會從cache里找該靜態文件，如果找到了，會根據上次請求這個文件時得到的cache-control信息判斷該靜態文件是否已經過期了，如果沒有，會以 if-modified-since、Etag 等信息作為 request headers 向服務器請求這個文件，服務器如果認為文件沒有變過，會返回Http code為304，瀏覽器于是直接讀cache。具體不展開啦，可以看 [《HTTP caching
》](https://developers.google.com/web/fundam... 和 《Understanding HTTP/304 Responses》。
讓chrome終端打開的時候cache功能依舊有效：Chrome終端的配置里把Disable cache (while DevTools is open)的勾選去掉
清空所有cache：地址欄里輸入 chrome://settings/clearBrowserData 打開后勾上 Cached images and files 點 Clear browsing data
查看瀏覽器當前cache的資源列表：chrome://cache/
目前看來，上面這個 File Prefeching 的方案是有效的。不過這種是最簡陋的試驗版，存在幾個問題：
prefetching.html 里的js會被執行，然后不可避免地會有一堆js錯誤 —— 看著難受~
通過iframe 加載 prefetching.html 會影響到當前頁面相關資源的加載速度
每次打開頁面都會加載一次 prefetching.html，雖然里面的靜態文件都已經在第一次打開的時候被cache住了不會重復下載，但無謂多一個請求終究是沒必要。
于是，我們上線使用的版本是這樣的：
1、有一段每個頁面都會被執行到的js：
// 打開一個iframe，下載之后頁面可能需要的js/css
setTimeout(function() {
var lastOpenTime = 0;
var nowTime = (new Date()).getTime();
try {
lastOpenTime = window.localStorage.getItem("staticIframeOpenTime");
} catch (e) {}
if (lastOpenTime > 0 && (nowTime - lastOpenTime < 24 * 3600 * 1000)) {
// 24小時打開一次iframe
return;
}
var iframe = $("