面試的妹紙問我：web緩存設置不是後臺的事情嗎？

背景介紹

團隊最近在招前端開發，早上收到一封簡歷，是個妹紙，從技能點來看還算符合要求，因而約了下午3點過來面試。

整個面試過程持續了大約40分鐘，問的題目也比較常規，其中一道題就是「常見的性能優化手段」。期間妹紙提到她看過《圖解HTTP》，我就順帶問了下，「是否瞭解HTTP協議中常見的跟緩存相關的header」。

若是妹紙可以答上一兩個，好比max-age之類的，基本這道題就放行了。不過妹紙的回覆讓我以爲有些意外：（字眼記不清了，大體這麼個意思）

「web緩存設置不是後臺的事情嗎？」

爲何以爲web緩存設置是後臺的事

妹紙的邏輯其實不難理解，由於web所須要的資源，如網頁、JavaScript、CSS、圖片等，都是放在服務器上的。而服務器大部分時候，要嘛是後臺同窗，要嘛是運維同窗在管理，不少前端同窗並無多少機會接觸到服務器，更別說上去對靜態資源作緩存設置了。

相信很多前端新人也是這麼認爲的。已經記不清有多少次，在技術羣裏面，每當有人討論HTTP協議等彷佛跟前端「關係不是特別大」的內容的時候，總會有那麼一兩個羣友怒氣值滿滿地來上一句：

別老裝逼成嗎，前端不就寫寫網頁切切圖片，這些東西有毛用，又不能漲工資。

對於這種言論，我通常是選擇潛水逃離，毫不戀戰。

柳暗花明：凡事皆有因

對於這個「web緩存設置不是後臺的事情嗎」這個問題，我心裏有本身的答案。

直接拋出結論容易，但並不意味着別人容易接受。因而我採起迂迴戰術，問妹紙：「大家的線上項目有沒有設置緩存？」

妹紙的回答再次讓我感到意外：

「沒有，設置了緩存後，有用戶訪問到了錯誤的版本，因此沒有設置緩存。」

從這回答能夠大體判斷，妹紙除了不瞭解緩存設置外，對於靜態資源的版本控制應該也不熟悉。

我忽然腦海中靈光一閃 —— 傳教的機會到了。因而現場瞬間從面試模式切換到上課模式。

緩存設置帶來的問題及解決方案

問題一：沒有設置緩存會帶來什麼問題？

答：首先固然是性能問題。用戶每次訪問都須要從新訪問服務器，用戶訪問速度、服務器負載堪憂。
其次是成本問題。用了雲服務的同窗應該瞭解，帶寬跟流量都是用毛爺爺換來的。

問題二：是緩存致使了版本訪問錯誤的問題嗎？

答：從出錯場景上來看，的確是緩存致使的。但緩存其實無辜的，罪魁禍首是不恰當的靜態資源版本控制。

問題三：有什麼解決方案？

答：首先對靜態資源進行版本控制（好比給靜態資源的文件名加上hash值），其次對網頁設置合適時長的緩存時間（長短取決於實際場景）。這樣就兼顧了版本升級和性能。

終極發問：web緩存設置真的只跟後臺有關嗎

看到這裏，相信各位已經得出了本身的答案。

從前端開發的角度來看，對靜態資源進行緩存設置，能夠減小用戶的訪問耗時，提高用戶的訪問體驗，在絕大部分時候都是基礎而重要的優化。

那麼，靜態資源的緩存應該設置多長呢？永不緩存？10分鐘？1小時？1年？。。。

其實並無標準答案，不少時候，都取決於技術架構、業務場景。

好比：像上面妹紙提到的，她們沒有作靜態資源的版本控制，那麼永不緩存也是能夠接受的。畢竟不少時候，相對於性能不佳，用戶對於服務出錯的容忍度是更低的。

再好比：若是已經實現相似文件名加hash這樣的版本控制方案，那麼大可將JavaScript、CSS、圖片等靜態資源的緩存時間設置長一些，好比1個月；而網頁的緩存時間能夠短一些，好比每隔10分鐘校驗一次。

若是前端同窗缺乏對web緩存設置的瞭解，認爲那是後臺的事，那麼不少時候就很難提出合理的技術方案。

退一萬步講，web緩存設置這件事假設就是由後臺包辦了（大公司裏頗有可能就是這樣），那麼緩存該怎麼設置？其實最終仍是由前端的場景說了算。緩存相關的header就那麼幾個，業務/技術場景可能成百上千，這個時候，前端能夠看做甲方，後臺能夠看做是乙方，需求只有前端知道。

寫在後面

前面囉囉嗦嗦講了一大通，實際上這個問題只佔了整個面試環節的很小一部分，當時也沒有在這個問題上過於糾纏。只是以爲很多同窗在相似的問題上存在必定的誤區，以爲不吐不快。

PS：雲漢金融科技招聘前端開發人員，座標深圳，年薪15w - 30w，有意者可私信或投遞簡歷。崗位介紹可點擊 傳送門。