指南是我寫的。
您肯定不想活在生產中編譯。
當您進行編譯時,會發生這樣的情況:
對/Asset中的文件的每個請求都傳遞給鏈輪。在第一在Rails用于緩存(通常是文件系統)的任何資源中編譯和緩存每個資產的請求。
在隨后的請求中,鏈輪接收到請求,并必須查找指紋文件名,檢查構成資產的文件(圖像)或文件(CSS和js)沒有被修改,如果存在緩存版本,則提供該文件。
那是一切在“資產”文件夾中和在插件使用的任何供應商/資產文件夾中。
這是很大的開銷,因為,老實說,代碼并不是為了速度而優化的。
這將對資產傳輸到客戶端的速度產生影響,并會對站點的頁面加載時間產生負面影響。
與默認情況相比:
當資產預編譯和編譯關閉時,將對資產進行編譯,并將其指紋到public/assets
..鏈輪將普通文件名到指紋文件名的映射表返回給Rails,Rails將其寫入文件系統。清單文件(Rails 3中的yml或Rails 4中具有隨機名稱的JSON)在啟動時由Rails加載到內存中,并被緩存以供資產助手方法使用。
這使得具有正確指紋資產的頁面生成非??欤募旧淼姆談t是從文件系統中快速生成Web服務器。兩者都比實時編譯快得多。
要獲得管道和指紋的最大優勢,您需要在Web服務器上設置未來的頭文件,并為js和css文件啟用gzip壓縮。鏈輪編寫gzip版本的資產,您可以設置您的服務器使用,消除了它這樣做的需要,為每個請求。
這將盡可能快地將資產分發給客戶端,并且在盡可能小的大小下,加快頁面的客戶端顯示速度,并減少(具有遙遠未來的頭)請求。
因此,如果您正在進行實時編譯,則如下所示:
- 很慢
- 缺乏壓縮
- 將影響頁的呈現時間。
對決
- 越快越好
- 壓縮
- 刪除從服務器無意中聽到的壓縮(可選)。
- 盡量減少頁面的呈現時間。
編輯:(回復后續評論)
管道能更改為在第一個請求時預編譯,但這樣做有一些主要障礙。首先,必須有一個查表來查找指紋名稱,否則助手方法太慢。在按需編譯的情況下,在編譯或請求每個新資產時,需要有一些方式來附加到查找表。
此外,在所有資產匯編到位之前,有些人將不得不在一段未知的時期內支付緩慢交付資產的代價。
默認情況下,編譯所有內容的代價是一次性支付的,它不會影響公眾訪問者,并確保一切在事情開始運行之前都能正常工作。
打破這一協議的原因是,它給生產系統增加了許多復雜性。
如果您正在閱讀這篇文章,因為您正在為部署過程中的緩慢編譯時間尋找解決方案,那么您可以考慮在本地預編譯這些資產。有關這方面的信息,請參閱資產管道指南..這允許您只在發生更改時在本地預編譯,提交該更改,然后在沒有預編譯階段的情況下進行快速部署。