体系吃透前端工程化，大厂级实战项目以战带练
前言
一份简約、地道的Web前端性能優化清單。每個優化點都包含有概念、實操和參考材料。面試、實戰兩相宜。
這是一個大工程。在正式開端之前，先統一下言语，廓清每一局部的目的和請求，避免跑偏。
概念：把官話翻译成能看懂、能記住的人話，準繩上易讀性 > 專業性
實操：本人操作一遍，不做雲玩家；記载中心完成，便當CV
參考材料：信息來源選用一手材料，以便保證信息的完好性、精確性和時效性。除非看一手的了解不了……
一、網络層面
1. DNS預解析
概念
DNS-prefetch 是一種 DNS 預解析技術。它會在懇求跨域資源之前，預先解析並停止DNS緩存，以減少真正懇求時DNS解析招致的懇求延遲。關於翻開包含有許多第三方衔接的網站，效果明顯。
實操
添加ref屬性爲“dns-prefetch”的link標簽。普通放在在html的head中。
復製代码
href的值就是要預解析的域名，對應後面要加载的資源或用戶有可能翻開链接的域名。
備注
同理，也有“ TCP/IP預衔接”，叫preconnect。參考材料中有完好的描绘。
2. 應用阅讀器緩存
概念
阅讀器緩存是阅讀器寄存在本地磁盤或者内存中的懇求結果的備份。當有相同懇求進來時，直接響應本地備份，而無需每次都從原始效勞器獲取。這樣不只提升了客戶端的響應效率，同時還能緩解效勞器的訪問壓力。
其間，商定何時、如何運用緩存的規則，被稱爲緩存戰略。分爲強緩存和協商緩存。
整個緩存執行的過程大致如下：
①. 懇求發起，阅讀器判別本地緩存，假如有且未到期，則命中強緩存。阅讀器響應本地備份，狀態码爲200。控製台Network中size那一項顯現disk cache;
②. 假如沒有緩存或者緩存已過時，則懇求原始效勞器訊問文件能否有變化。效勞器依據懇求頭中的相關字段，判別目的文件新穎度；
③. 假如目的文件沒變卦，則命中協商緩存，效勞器設置新的過時時間，阅讀器響應本地備份，狀態码爲304；
④. 假如目的文件有變化，則效勞器響應新文件，狀態码爲200。阅讀器更新本地備份。
上述過程有幾個關键點
如何判別緩存能否過時？
阅讀器讀取緩存的懇求結果中響應頭的Expires 和Cache-Control，與當前時間停止比擬。
其中，Expires是HTTP 1.0的字段，值是一個是絕對時間。
Expires: Tue, 18 Jan 2022 09:53:23 GMT
復製代码
比擬絕對時間，有一個弊端，它依賴計算機時鍾被正確設置。
爲理解決這個問題，HTTP1.1 新增了Cache-Control字段，它的值是一個是相對時間。
Cache-Control: max-age=60 //單位是秒
復製代码
如何判別文件能否變化？
首先能夠經過比擬 最後修正時間。
// 緩存結果的 響應頭
Last-Modified: Mon, 10 Jan 2022 09:06:14 GMT
// 新懇求的 懇求頭
If-Modified-Since: Mon, 10 Jan 2022 09:06:14 GMT
復製代码
阅讀器取出緩存結果中Last-Modified的值，經過If-Modified-Since上送到效勞端。與效勞器中目的文件的最後修正時間做比擬。
再者能夠經過比擬 Etag。
Etag實體標簽是附加到文檔上的恣意標簽(援用字符串)。它們可能包含了文檔的序列號或版本名，或者是文檔内容的校驗和及其他指纹信息。當發佈者對文檔停止修正時，會修正文檔的實體標簽來阐明這是個新的版本。
從響應頭的ETag取值，經過懇求頭的If-None-Match上送，與效勞器目的文件的Etag標簽比對。
// 緩存的 響應頭
ETag: "61dbf706-142"
// 上送的 懇求頭
If-None-Match: "61dbf706-142"
復製代码
和上面一樣，新增的字段也是爲理解決前一種計劃的某些缺陷：
有些文檔可能會被周期性地重寫(比方，從一個後台進程中寫入)，但實践包含的數據常常是一樣的。雖然内容沒有變化，但修正日期會發作變化。
有些文檔可能被修正了，但所做修正並不重要，不需求讓世界範圍内的緩存都重裝數據(比方對拚寫或注释的修正)。
有些效勞器無法精確地斷定其頁面的最後修正日期。
有些效勞器提供的文檔會在亞秒間隙發作變化(比方，實時監視器)，對這些效勞器來說，以一秒爲粒度的修正日期可能就不夠用了。
假如兩個版本的字段同時存在，怎樣辦？
出於阅讀器兼容方面的思索 ，普通兩組字段會被同時運用。他們沒有優先級一說，取並集。
同時呈現時，只要當兩個條件都滿足，才會命中相應緩存。
實操
緩存是web效勞器和阅讀器的中心才能，主流的web效勞框架 nginx、koa-static等都内置有上述緩存戰略的完成。開箱即用，無需額外編程或配置。
以Nginx舉例。強緩存的配置字段是expires，它承受一個數字，單位是秒。
server {
listen 8080;
location / {
root /Users/zhp/demo/cache-koa/static;
index index.html;
# 留意try_files會招致緩存配置不生效
# try_files $uri $uri/ /index.html;
expires 60;
}
}
復製代码
實践工作中的確配置一下就好了，但這表現不出什麼學問點。爲了加深印象，我這用koa粗陋的模仿了一下，算是對上面那些學問點的考證。
下面是一個極简的静態資源效勞，不帶緩存的。
app.use(async (ctx) => {
// 1.依據訪問途径讀取指定文件
const content = fs.readFileSync(`./static${ctx.path}`, "utf-8");
// 2.設置響應
ctx.body = content;
});
復製代码
這種狀況，無論訪問幾次都是不進緩存的。
如今，在響應頭加上強緩存所需的Exprise和Cache-Control字段
app.use(async (ctx) => {
// 1.依據訪問途径讀取指定文件
const content = fs.readFileSync(`./static${ctx.path}`, "utf-8");
// 2.設置緩存
ctx.response.set("Cache-Control", "max-age=60");
ctx.response.set('Exprise', new Date(new Date().getTime()+60*1000));
// 3.設置響應
ctx.body = content;
});
復製代码
查看Network，響應頭會多出下面兩個字段，且距離60秒内的懇求會走緩存，契合預期。
Expires: Tue, 18 Jan 2022 10:05:09 GMT
Cache-Control: max-age=60
復製代码
download链接：https://pan.baidu.com/s/1a_2b4x24sgTNjdFX47wSkA?pwd=lvxn
提取码：lvxn
--来自百度网盘超级会员V4的分享
