摘要：文件路徑，上線后，絲絲潤滑無痛無癢，完美第四個版本，可以做更多注意哦，重點來咯盡早加載是減少首屏時間的關鍵引申閱讀，直接把到里是個不錯的方案。

所謂 File Prefetching 就是在一個頁面加載成功后，默默去預加載后續(xù)可能會被訪問到的頁面的資源。   
前端資源預加載其實沒啥新鮮的，我們倒騰這個事情的過程卻是很有有意思也很有啟發(fā)性。

1、建一個獨立的頁面，里面索引了各種需要預加載的css、js，代碼類似下面這樣。

    
    ...其他需要預加載的css



    
    ...其他需要預加載的js

2、 在每個頁面加入一個iframe（一般通過base模板統(tǒng)一加），這樣每個頁面打開的時候都會加載上面這個頁面。假設上面的頁面的url是 https://xxx.com/common/prefetching.html 那么我們每個頁面底部都有這么一行代碼：

要驗證某個file prefetching的方案是否真的有效，無非就是以下幾步：
（假設A頁面使用了showcase_d0fbaaef124a8691398704216ccd469a.css，而B頁面不會）

讓chrome終端打開的時候cache功能依舊有效

清空所有本地cache

打開B頁面，在控制臺Networking里看prefetching.html以及附屬的資源文件是否被下載了

打開A頁面，注意：是在地址欄里輸入A的網(wǎng)址然后回車，不要打開A頁面后習慣性地按Command/Ctrl+R來刷新，不出意外，我們會看到如下圖這樣的結(jié)果：

這說明，這2個css文件是從cache里讀的。如果Command/Ctrl+R來刷新頁面，我們會看到這樣的結(jié)果：

兩者的差別是，Command/Ctrl+R的時候，瀏覽器會從cache里找該靜態(tài)文件，如果找到了，會根據(jù)上次請求這個文件時得到的cache-control信息判斷該靜態(tài)文件是否已經(jīng)過期了，如果沒有，會以 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會被執(zhí)行，然后不可避免地會有一堆js錯誤 —— 看著難受~

通過iframe 加載 prefetching.html 會影響到當前頁面相關資源的加載速度

每次打開頁面都會加載一次 prefetching.html，雖然里面的靜態(tài)文件都已經(jīng)在第一次打開的時候被cache住了不會重復下載，但無謂多一個請求終究是沒必要。

于是，我們上線使用的版本是這樣的：

1、有一段每個頁面都會被執(zhí)行到的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 = $("