- 已經建立連接了，但是服務器崩潰了，怎麼辦？
- HSTS
- 緩存校驗
- DNS解析（20ms到120ms）
一，url解析以及緩存
二，DNS解析
1，首先本地解析，沒有的話再去別的地方找（遞歸過程--深度搜索）
2，去DNS服務器上找（迭代過程--廣度搜索），2，3，4，5，6，7步驟，最後到權威域名服務器找，20-120ms
優化點：
1，減少DNS請求次數，儘量不用請求太多不同服務器資源。但是爲了做負載均衡，服務器分離部署，需要儘量多的請求不同服務器資源，所以這個很難做到。
2，DNS預解析，這個是異步處理，節省時間，針對的是頁面的圖片等資源
<link rel="dns-prefetch" href="//g.alicdn.com">
三，減少HTTP請求和請求資源大小
優化點：
1，資源合併壓縮
2，字體圖標
3，base64（小圖片）
4，GZIP
5，圖片懶加載（骨架屏技術）
6，數據延遲分批加載（第一次只加載首頁）
7，CDN資源（地域式分佈，請求離自己最近的服務器）
8，雪碧圖（基本淘汰）
四，發送http請求之後應用緩存（把內容緩存起來，他不香嗎）
緩存位置：
1，Service Worker：瀏覽器獨立線程進行緩存（基本不用）
2，Memory Cache：內存緩存（小而快，瀏覽器操作）
3，Disk Cache：硬盤緩存（大而慢，瀏覽器操作）
4，Push Cache：推送緩存（HTTP2中，基本不用）
緩存流程：
- 初次加載url：查找disk cache，有的話直接拿，沒有的話從服務器請求，服務器返回緩存規則
- 刷新頁面（f5）：memory cache，然後再disk cache
- 強制刷新（ctrl+f5）：瀏覽器不使用緩存，發送的頭部帶有cache-control:no-cache（爲了兼容，也會有pragma：no-cache），服務器直接返回200和最新內容
4.1，強緩存（Expires/Cache-Control）
瀏覽器對於強緩存的處理：根據第一次請求資源時服務器返回的相應頭來確定
緩存規則：
- Expries：緩存過期時間，用來指定資源到期時間（http1，過時了，現在用http1.1）
-
Cache-Control： Cache-Control:max-age=2592000，也就是30天，再次發請求，讀取緩存中的信息（http1.1），具體是在memory cache中還是disk cache中讀取，由瀏覽器規定
規則（兩者同時寫時，Cache-Control優先級更高）：
![]()
問題：服務器在30天內更新資源，客戶端無法同步更新。
解決：webpack打包之後，文件名會添加hash值，當成新的資源請求服務器（也就是沒有緩存）
4.2，協商緩存
強緩存失效（過期）後，瀏覽器攜帶緩存標識向服務器發起請求，由服務器根據緩存標識決定是否使用緩存的過程。
資源未更新，返回304過程：
資源更新，返回200的過程：
Last-Modified和If-Modified-Since：
- 初次訪問，服務器返回資源，響應頭中設置了Last-Modified（上次修改時間），緩存文件和響應頭
- 再次訪問，瀏覽器檢測到有Last-Modified，於是設置If-Modified-Since=Last-Modified，並將If-Modified-Since添加到請求頭。
- 服務器收到請求，將If-Modified-Since與服務器的Last-Modified相同，則返回304和空的響應體，瀏覽器直接從緩存中讀取；如果If-Modified-Since小於服務器的Last-Modified，則說明服務器資源有更新，則返回新的資源文件和200.
注意：Last-Modified是秒級，如果在不可感知的時間內修改文件，則服務器會以爲沒有修改
ETag和If-None-Match：
服務器資源改變時，ETag就會改變，用法和上面一樣
七，瀏覽器渲染
構建DOM樹，CSS樹，Render樹
7.1，DOM樹
初始字節碼-通過utf-8轉換：Bytes：3c 62 6f ......
（1）轉換 字符集
Characters:<html><head></head><body><p></p></body></html>
（2）令牌
Tokens: StartTag:html StartTag:head EndTag:head StartTag:body EndTag:body ...
（3）詞法分析
Nodes:html body p span ...
（4）DOM構建
優化點：
1，標籤語義化
2，避免多級嵌套（儘量4級以下）
7.2，CSSDOM樹，link,@import
流程和DOM一樣
優化點：
（1）css選擇器是從右到左，比如 .div a 是先找所有的a，然後再找.div，因此選擇器層級不要太多
7.3，RENDER樹
計算在視口的位置和大小，也就是迴流（因元素位置，大小變化導致的重新佈局）
根據渲染樹和迴流得到的幾何信息，進行繪製（寬高，大小，顏色）
重繪不一定會流，但是會流一定重繪
優化點：
1，減少操作dom（react之類框架很少需要）：
（1）動畫效果放在absolute上面
（2）css3硬件加速（GPU加速），但是可能消耗過多性能，佔用內存，導致字體模糊等
（3）犧牲平滑度換取速度，也就是動畫時不以1px爲基準，而以3px以上，看上去略有不流暢，但可以減少因cpu打滿而產生的卡頓
（4）讀寫分離
2，link是發送http請求，每個http請求都是單獨線程處理，chorme可以允許6-7個http請求
（1）@import是同步的，會導致阻塞，因此要減少使用
（2）問：react項目中使用@import，打包之後是什麼情況？
優化點：
1，style不需要發請求，速度比link快，如果內容不多的話
2，減少@import
3，link寫在頭部，和html併發請求
7.4，JS加載
優化點
1，js也是阻塞的，需要放到底部
藍色加載，紅色渲染
async是誰先加載完成，誰先渲染，不分先後順序，不依賴其他js文件，不產生衝突的common.js可以使用。（淘寶基本都用的async，和我想的有點不一樣...）
defer會有設置依賴，有順序，一般使用defer。（webpack打包也可以加上）
參考資源：去b站看了下，視頻涼了