IT工程師數位筆記本

背景介紹

團隊最近在招前端開發，早上收到一封簡歷，是個妹紙，從技能點來看還算符合要求，于是約了下午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，有意者可私信或投遞簡歷。崗位介紹可點擊 傳送門。