前端面試——網絡以及瀏覽器相關

TCP、UDP的區別 ？

（1）TCP是面向鏈接的（三次握手，四次揮手），UDP是無鏈接的； 

（2）TCP提供可靠的服務，經過TCP鏈接傳輸的數據無差錯、不丟失、不重複，且按序到達（擁塞控制）；UDP則是盡最大努力交付，可是不保證可靠性； 

（3）TCP是面向字節流，UDP面向報文（UDP 只是報文的搬運工，不會對報文進行任何拆分和拼接操做）；

（4）TCP只能端對端；UDP支持一對1、多對多、一對多、多對一；

（5）TCP的首部較大，約有20字節；UDP有8字節（因此UDP具備高效性）；

擁塞控制相關博客：blog.csdn.net/m0_37962600…

TCP、UDP頭部相關博客：blog.csdn.net/xiaoxianerq…

三次握手以及四次揮手？

三次握手：

1.客戶端首先發送SYN=1；

2.服務端接收到，而後增長一個ACK=1返回給客戶端。（返回給客戶端的是ACK=1，SYN=1）

3.客戶端須要發送一個消息給服務端進行確認，因此給服務端發送了一個ACK=1；

四次揮手：

1.首先客戶端請求關閉與服務端的鏈接，客戶端先發送一個FIN=1；

2.服務端接收到消息後，返回一個ACK=1；

3.在這個狀態下實際上一個方向已經關閉了，因此服務端也須要給客戶端發送一個FIN=1，ACK=1；

4.客戶端接收到後發送ACK=1，表示接收到消息。

HTTP爲何須要三次握手？

若是發送2次就能創建鏈接的話，可能會出現如下問題：

若是一個鏈接請求在網絡中超時了，在這個時候客戶端會從新發送請求，可是最終超時的請求仍是會到服務端，服務端接收了兩個請求，就會建立出2個鏈接。浪費了資源。

可是在三次握手的狀況下，發生這種狀況，多出的一次請求會被拋棄掉。

HTTP爲何須要四次分手？

TCP是雙向的，因此須要在服務端和客戶端都須要關閉。當客戶端關閉和服務端的鏈接後，依舊是能夠接收到服務端的消息的，只是客戶端再也不往服務端發送消息。

FastTCP

FastTCP被認爲是目前全球最早進的電信級TCP/IP協議單邊部署加速技術。

FastTCP不修改TCP協議內TCP包頭(TCP Packet Header)的標準格式，只對TCP包頭裏的（Sequence Number, Window Scaling ）等數值做修改，而且優化了流量控制的算法，大大提升了TCP流量的效率，從而提升了廣域網帶寬的利用率。FastTCP對TCP包自己的內容(Payload)和標準的TCP包格式並不做改變。

FastTCP技術特色包括：

一、在現有架構中即插即用，與主要廠商網絡設備徹底兼容

二、單邊部署，客戶端不須要安裝任何軟、硬件

三、徹底兼容並加速各類標準及變種TCP協議流量

四、應用軟件無須做任何改變

五、能對不可壓縮或緩存內容進行加速

六、支持Bypass功能和高可靠組架構，保證網絡不會因FastSoft加速器故障而中斷

       

        與通常的TCP相比，FASTTCP的不一樣主要表如今三個方面：首先，它是一個基於平衡(Equilibrium)的算法，所以消除了包級振盪；第二：它使用隊列時延(Queuing Delay)做爲主要的擁塞測量，在高速、長距離網絡的中，隊列時延對擁塞的測量比丟包率具備更高的可靠性；第三，它具備穩定的流動態性，可以在平衡狀態得到加權指數級的公平性，且不會給長距離TCP流不公正的待遇。 FASTTCP擁塞控制算法可分爲四個部分，其中，數據控制(Data Control)部分決定哪些包將要被髮送，窗口控制(Window Control)部分決定要發送多少個包，爆發控制(Burstiness Control) 部分決定什麼時候發送這些包，這些決定都是在估計(Estimation)部分提供的信息的基礎上做出的。窗口控制以往返時間爲時標控制TCP包傳輸，而爆發控制工做在一個較小的時標。

——估計部分：該估計信息被其它三部分使用。當收到確定確認，將RTT平滑計算到平均RTT；當收到否認確認，將生成丟失指示。

——窗口控制：使用隊列時延做爲其主要的擁塞測量。在通常的網絡條件下，FastTCP週期性的根據平均RTT來更新擁塞窗口。當網絡的流式樣或者拓撲結構改變時平衡點會發生偏移，FASTTCP採用平衡性和公平性算法實現效率最大化。

——數據控制：從候選池中選擇下一次要發送的數據包：新數據包，被否認確認的包，或傳輸後還未被確認的包。數據控制部分決定如何將三個候選池中數據包混合發送。特別是在當前帶寬-時延積愈來愈大的狀況下，這個決定變得尤爲重要。

——爆發控制：爆發控制部分經過使用一種類流方式追蹤可用帶寬，以達到平滑數據包發送的目的。FASTTCP使用兩種爆發控制機制，一個補充流出的單個包的自同步，另外一個使用小爆發使窗口平滑的增長。

什麼是XSS，如何防護？什麼是CSRF，如何防護？

XSS（跨站腳本攻擊）

XSS攻擊指的是攻擊者在網站上注入惡意的代碼，經過惡意腳本對客戶端網頁進行篡改，從而在客戶瀏覽網頁的時候，對用戶瀏覽器進行控制或獲取用戶的隱私數據。

XSS防護

1.httpOnly防止劫取Cookie，瀏覽器禁止JavaScript去訪問帶有HttpOnly屬性的Cookie。（注意：HttpOnly並非阻止了XSS，而是可以阻止XSS攻擊後的Cookie劫持攻擊。）

2.輸入、輸出檢查（針對<>這一類的特殊字符）。

3.CSP

CSP 本質上也是創建白名單，規定了瀏覽器只可以執行特定來源的代碼。

一般能夠經過 HTTP Header 中的 Content-Security-Policy 來開啓 CSP

只容許加載本站資源    Content-Security-Policy: default-src ‘self’

只容許加載 HTTPS 協議圖片   Content-Security-Policy: img-src https://*

容許加載任何來源框架  Content-Security-Policy: child-src 'none'

CSRF（跨站請求僞造）

CSRF指的是劫持受信任用戶向服務器發送非預期請求。

CSRF防護

1.驗證碼

2.token

3.referer，http頭中又一個字段叫作referer，它記錄了該HTTP請求的來源地址。經過Referer Check可以檢查請求是否來自合法的源。

4.SameSite

能夠對 Cookie 設置 SameSite 屬性。該屬性設置 Cookie 不隨着跨域請求發送。

其餘網絡安全相關（包含XSS、CSRF、SQL注入、clickjacking攻擊）：www.cnblogs.com/liqiongming…

介紹下如何實現 token 加密

1. 須要一個secret

2. 後端利用secret和加密算法，返回前端

3. 前端每次request在header中帶上token

4. 後端用一樣的算法解密

強緩存和協商緩存（包括瀏覽器機制）

緩存分爲強緩存和協商緩存。

強緩存不過服務器，協商緩存須要過服務器，協商緩存返回的狀態碼是304。

兩類緩存機制能夠同時存在，強緩存的優先級高於協商緩存。當執行強緩存時，如若緩存命中，則直接使用緩存數據庫中的數據，再也不進行緩存協商。

強緩存

Expires（HTTP1.0）：

Expires的值爲服務端返回的數據到期時間。當再次請求時的請求時間小於返回的此時間，則直接使用緩存數據。

缺點：使用的是絕對時間，若是服務端和客戶端的時間產生誤差，那麼會致使命中緩存產生誤差。

Pragma（HTTP1.0）:

當值爲"no-cache"時強制驗證緩存，服務端響應添加'Pragma': 'no-cache'，瀏覽器表現行爲和刷新(F5)相似。

Cache-Control（HTTP1.1）：

• private：客戶端能夠緩存

• public：客戶端和代理服務器均可以緩存

• max-age=t：緩存內容將在t秒後失效

• no-cache：須要使用協商緩存來驗證緩存數據

• no-store：全部內容都不會緩存 

協商緩存

一、瀏覽器第一次請求數據時，服務器會將緩存標識與數據一塊兒響應給客戶端，客戶端將它們備份至緩存中。

二、再次請求時，客戶端會將緩存中的標識發送給服務器，服務器根據此標識判斷。若未失效，返回304狀態碼，當瀏覽器拿到此狀態碼就能夠直接使用緩存數據了。

相關的http頭部

1.etag -- if-none-match

        1）若是緩存中有ETag 令牌，客戶端請求時會自動在「If-None-Match」 HTTP 請求標頭內提供 ETag 令牌。

        2）服務器根據當前資源覈對令牌，驗證是否發生變化，將驗證結果通知給客戶端，客戶端根據結果看看是否須要從緩存中讀取仍是發送資源請求。

參考文獻：www.jianshu.com/p/3e2afe089…

2.last-modified -- if-modified-since

Last-Modified 是由服務器往客戶端發送的 HTTP 頭，另外一個 If-Modified-Since是由客戶端往服務器發送的頭。

blog.csdn.net/tianmohust/…

緩存的場景

一、不須要緩存使用 Cache-control: no-store。

二、頻繁變更的資源使用 Cache-Control: no-cache 並配合 ETag 使用，表示該資源已被緩存，可是每次都會發送請求詢問資源是否更新。

三、對於代碼文件來講，一般使用 Cache-Control: max-age=31536000 配合策略緩存使用，而後對文件進行指紋處理，一旦文件名變更就會馬上下載新的文件。

DNS解析時，有什麼算法和方式減小重複操做？

DNS解析的時候可使用DNS緩存去減小重複操做。

DNS緩存有瀏覽器DNS緩存、系統DNS緩存、路由DNS緩存、服務商DNS緩存。

DNS有兩種查詢的方式，分爲遞歸查詢和迭代查詢。

遞歸查詢是訪問根域名服務器，根域名服務器層層下發，找到目標域名的IP地址後返回。

迭代查詢是訪問根域名服務器後，根域名服務器返回一個其餘DNS服務器的地址，而後再向其餘DNS服務器去查詢。

DNS緩存

在瀏覽器中輸入URL的時候，DNS會根據域名找到對應的IP地址。

在DNS查找目標域名對應的IP地址的時候，首先會去訪問瀏覽器緩存，看最近訪問的網址中有沒有目標域名。若是沒有則會訪問系統DNS緩存中的是否存在，依舊不存在則會去路由緩存中查找，可是仍是不存在的話就會去ISP服務商的緩存中查找是否有目標域名的IP地址。

若是緩存中都不存在則會訪問根域名服務器去查找目標域名的IP地址，根域名服務器會層層下發直到找到對應域名的IP地址爲止。

Cookie 和Session、LocalStorage

生命週期：

cookie：可設置失效時間，沒有設置默認是關閉瀏覽器後失效。

localStorage：除非被手動清除，不然將會永久保存。

sessionStorage： 僅在當前網頁會話下有效，關閉頁面或瀏覽器後就會被清除。

存放數據大小：

cookie：4KB左右

localStorage和sessionStorage：能夠保存5MB的信息。

http請求：

cookie：每次都會攜帶在HTTP頭中，若是使用cookie保存過多數據會帶來性能問題

localStorage和sessionStorage：僅在客戶端（即瀏覽器）中保存，不參與和服務器的通訊

緩存位置

1.from Service Worker

2.from memory cache

3.from disk cache

Service Worker

Service Worker相比於LocalStorage、SessionStorage，後二者只是單純的接口數據緩存，而前者能夠緩存靜態資源，甚至攔截網絡請求，根據網絡情況做出不一樣的緩存策略。

memory cahce

事實上，全部的網絡請求都會被瀏覽器緩存到內存中。可是緩存不能無限存放在內存中，由於內存是有限的。 內存緩存的控制權在瀏覽器，先後端都不能干涉。

disk cache 

disk cache也叫http cahce，它將資源緩存在硬盤中，由於其嚴格遵照http響應頭的字段來判斷哪些資源是否要被緩存，哪些資源是否已通過期。緩存的控制權在後端。

localStorage和sessionStorage

localStorage永久保存在瀏覽器裏面（在沒被清除的狀況下），sessionStorage是關閉網頁就清除了信息。

localStorage能夠用來跨頁面（跨窗口）傳遞參數，而sessionStorage用來保存一些臨時的數據，防止用戶刷新頁面以後丟失了一些參數。

WebSocket

WebSocket 是在最初創建鏈接時須要藉助於現有的HTTP協議，通訊是基於TCP的。

經過WebSocket能夠在客戶端和服務器之間以數據流的形式實現各類應用數據交換（包括JSON 及自定義的二進制消息格式），並且兩端均可以隨時向另外一端發送數據。

Keep-alive

Connection:Keep-alive

HTTP協議採用「請求-應答」模式。

在不開啓KeepAlive模式時，每一個req/res客戶端和服務端都要新建一個鏈接，完成後當即斷開鏈接（HTTP協議爲無鏈接的協議）；

當開啓Keep-Alive模式（又稱持久鏈接、鏈接重用）時，Keep-Alive功能使客戶端到服務器端的鏈接持續有效，當出現對服務器的後繼請求時，Keep-Alive功能避免了創建或者從新創建鏈接。

HTTP各個版本

相對於HTTP1.0，HTTP1.1的優化：

一、緩存處理：多了Entity tag，If-Unmodified-Since, If-Match, If-None-Match等緩存信息（HTTTP1.0 If-Modified-Since,Expires）

二、帶寬優化及網絡鏈接的使用

三、錯誤通知的管理

四、Host頭處理

五、長鏈接： HTTP1.1中默認開啓Connection： keep-alive。

相對於HTTP1.1，HTTP2的優化：

• HTTP2支持二進制傳送（實現方便且健壯），HTTP1.x是字符串傳送

• HTTP2支持多路複用（多路複用容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息）

• HTTP2採用HPACK壓縮算法壓縮頭部，減少了傳輸的體積

• HTTP2支持服務端推送

HTTP/2的多路複用

HTTP/2引入二進制數據幀和流的概念，其中幀對數據進行順序標識，以下圖所示，這樣瀏覽器收到數據以後，就能夠按照序列對數據進行合併，而不會出現合併後數據錯亂的狀況。一樣是由於有了序列，服務器就能夠並行的傳輸數據，這就是流所作的事情。

• 解決第二個問題：HTTP/2對同一域名下全部請求都是基於流，也就是說同一域名無論訪問多少文件，也只創建一路鏈接。

而後還多了個HTTP3.0

QUIC新功能

一、0-RTT

經過使用相似 TCP 快速打開的技術，緩存當前會話的上下文，在下次恢復會話的時候，只須要將以前的緩存傳遞給服務端驗證經過就能夠進行傳輸了。0RTT 建連能夠說是 QUIC 相比 HTTP2 最大的性能優點。

二、多路複用

同HTTP2.0同樣，同一條 QUIC鏈接上能夠建立多個stream，來發送多個HTTP請求，可是，QUIC是基於UDP的，一個鏈接上的多個stream之間沒有依賴。假如stream2丟了一個UDP包，不會影響後面跟着 Stream3 和 Stream4，不存在 TCP 隊頭阻塞。雖然stream2的那個包須要從新傳，可是stream三、stream4的包無需等待，就能夠發給用戶。

另外QUIC 在移動端的表現也會比 TCP 好。由於 TCP 是基於 IP 和端口去識別鏈接的，這種方式在多變的移動端網絡環境下是很脆弱的。可是 QUIC 是經過 ID 的方式去識別一個鏈接，無論你網絡環境如何變化，只要 ID 不變，就能迅速重連上。

三、加密認證的報文

TCP 協議頭部沒有通過任何加密和認證，因此在傳輸過程當中很容易被中間網絡設備篡改，注入和竊聽。可是 QUIC 的 packet中除了個別報文好比 PUBLIC_RESET 和 CHLO，全部報文頭部都是通過認證的，報文 Body 都是通過加密的。

四、向前糾錯機制

QUIC協議可以向前糾錯 ，因爲每一個數據包除了它自己的內容以外，還包括了部分其餘數據包的數據，所以少許的丟包能夠經過其餘包的冗餘數據直接組裝而無需重傳。

HTTP2.0的多路複用和HTTP1.X中的長鏈接複用有什麼區別？

• HTTP/1.* 一次請求-響應，創建一個鏈接，用完關閉；每個請求都要創建一個鏈接；

• HTTP/1.1 Pipeling解決方式爲，若干個請求排隊串行化單線程處理，後面的請求等待前面請求的返回才能得到執行機會，一旦有某請求超時等，後續請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞；

• HTTP/2多個請求可同時在一個鏈接上並行執行。某個請求任務耗時嚴重，不會影響到其它鏈接的正常執行；

websocket和長鏈接區別

長鏈接：創建SOCKET鏈接後無論是否使用都保持鏈接。

長鏈接：鏈接->傳輸數據->保持鏈接 -> 傳輸數據-> ........ ->關閉鏈接。

WebSocket： 瀏覽器和服務器只須要要作一個握手的動做，在創建鏈接以後，雙方能夠在任意時刻，相互推送信息。同時，服務器與客戶端之間交換的頭信息很小。

長輪詢和短輪詢是什麼？

 短輪詢指瀏覽器向服務器發送一個請求，詢問是否有數據更新，服務裏馬上返回響應。一段時間後瀏覽器又發起一個到服務器的新請求。 

長輪詢指瀏覽器向服務器發送一個請求，服務一直保持鏈接打開，直到有數據可發送，發送完數據後，瀏覽器關閉鏈接，隨即又發起一個到服務器的新請求。（使用XHR對象和setTimeout()實現） 

常見的HTTP狀態碼

100：表示請求頭已經發送到服務端，服務端表示容許訪問，須要客戶端再發送主體部分

200：表示請求成功

204：No content，表示請求成功，但響應報文不含實體的主體部分

206：處理了部分請求

301：永久重定向，請求的網頁已永久移動到新地址。

302：臨時重定向

303：see other，請求者應當對不一樣的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。 

304：no modify，自從上次請求後，請求的網頁未修改過。

305：請求者只能使用代理訪問請求的網頁

307：臨時重定向

400：服務器不理解請求的語法

401：請求要求身份驗證 

403：服務器拒絕請求 

404：服務器找不到請求的網頁

405：禁用請求中指定的方法

406：沒法使用請求的內容特性響應請求的網頁

500：服務器內部錯誤，沒法完成請求

501：服務器不具有完成請求的功能

502：錯誤網關

503：服務不可用

504：網關超時

瀏覽器是如何渲染頁面的

一、編碼： 先將HTML的原始字節數據轉換爲文件指定編碼的字符。 

二、令牌化： 而後瀏覽器會根據HTML規範來將字符串轉換成各類令牌（如<html>、<body>這樣的標籤以及標籤中的字符串和屬性等都會被轉化爲令牌，每一個令牌具備特殊含義和一組規則）。

三、生成對象： 接下來每一個令牌都會被轉換成定義其屬性和規則的對象。 

四、構建完畢： DOM樹構建完成，整個對象集合就像是一棵樹形結構。 

五、當HTML代碼碰見<link>標籤時，瀏覽器會發送請求得到該標籤中標記的CSS文件，構建CSSOM樹。  

六、在構建了DOM樹和CSSOM樹以後，將DOM樹與CSSOM樹結合在一塊兒成渲染樹。 

七、渲染樹構建完畢後，瀏覽器獲得了每一個可見節點的內容與其樣式，而後計算每一個節點在窗口內的確切位置與大小，也就是佈局階段。 

八、當Layout佈局事件完成後，瀏覽器會當即發出Paint Setup與Paint事件，開始將渲染樹繪製成像素。

GET和POST的區別

一、Get 請求能緩存，Post 不能。

二、Post 相對 Get 安全一點點，由於Get 請求都包含在 URL 裏，且會被瀏覽器保存歷史紀錄，可是Post 不會。在抓包的狀況下都是同樣的。

三、Post 能夠經過 request body來傳輸比 Get 更多的數據，可是Get不行。

四、URL有長度限制，會影響 Get 請求，這個長度限制是瀏覽器規定的。

五、Post 支持更多的編碼類型且不對數據類型限制。

URL輸入瀏覽器的整個過程

（1）、DNS緩存

（2）、TCP的三次握手

（3）、瀏覽器頁面的渲染

（4）、TCP的四次握手

迴流和重繪

何時會發生迴流：

一、添加或刪除可見的DOM元素

二、元素的位置發生變化

三、元素的尺寸發生變化（包括外邊距、內邊框、邊框大小、高度和寬度等）

四、內容發生變化，好比文本變化或圖片被另外一個不一樣尺寸的圖片所替代。

五、瀏覽器的窗口尺寸變化（由於迴流是根據視口的大小來計算元素的位置和大小的）

什麼時候發生重繪（迴流必定會觸發重繪）：

當頁面中元素樣式的改變並不影響它在文檔流中的位置時（例如：color、background-color、visibility等），瀏覽器會將新樣式賦予給元素並從新繪製它，這個過程稱爲重繪。

如何避免觸發迴流和重繪：

CSS：

一、避免使用table佈局。

二、儘量在DOM樹的最末端改變class。

三、避免設置多層內聯樣式。

四、將動畫效果應用到position屬性爲absolute或fixed的元素上

五、避免使用CSS表達式（例如：calc()）

六、CSS3硬件加速（GPU加速）

JavaScript：

一、避免頻繁操做樣式，最好一次性重寫style屬性，或者將樣式列表定義爲class並一次性更改class屬性

二、避免頻繁操做DOM，建立一個documentFragment，在它上面應用全部DOM操做，最後再把它添加到文檔中

三、也能夠先爲元素設置display: none，操做結束後再把它顯示出來。由於在display屬性爲none的元素上進行的DOM操做不會引起迴流和重繪

四、避免頻繁讀取會引起迴流/重繪的屬性，若是確實須要屢次使用，就用一個變量緩存起來

五、對具備複雜動畫的元素使用絕對定位，使它脫離文檔流，不然會引發父元素及後續元素頻繁迴流 

HTTPS的握手

一、客戶端向服務端發送消息，發送的信息包含 SSL 版本、客戶端支持的加密套件和使用的數據壓縮算法及隨機數1。

二、服務器響應客戶端消息，返回的信息包含選定的加密套件、選定的數據壓縮方法、會話標識，數字證書及另外一個隨機數2。

三、客戶端驗證服務器的SSL數字證書的有效性，若是不經過則提示警告。

四、客戶端發送密鑰交換的消息。消息包含隨機數3。

五、客戶端使用加密運算將全部隨機數轉化爲 master secret。

六、服務器使用加密運算將全部隨機數轉化爲 master secret。

七、客戶端告知服務器以後使用協商好的對稱加密算法生成的密鑰通訊。

八、服務器告知客戶端以後使用協商好的對稱加密算法生成的密鑰通訊。

九、SSL握手結束，接下去使用對稱加密算法進行加密通訊。

介紹下 HTTPS 中間人攻擊

中間人攻擊過程以下：

1. 服務器向客戶端發送公鑰。

2. 攻擊者截獲公鑰，保留在本身手上。

3. 而後攻擊者本身生成一個【僞造的】公鑰，發給客戶端。

4. 客戶端收到僞造的公鑰後，生成加密hash值發給服務器。

5. 攻擊者得到加密hash值，用本身的私鑰解密得到真祕鑰。

6. 同時生成假的加密hash值，發給服務器。

7. 服務器用私鑰解密得到假祕鑰。

8. 服務器用加祕鑰加密傳輸信息

防範方法：

1. 服務端在發送瀏覽器的公鑰中加入CA證書，瀏覽器能夠驗證CA證書的有效性

爲何利用多個域名來存儲網站資源會更有效？

1.CDN緩存更方便;

2.突破瀏覽器併發限制;

3.節約cookie帶寬;

4.節約主域名的鏈接數，優化頁面響應速度;

5.防止沒必要要的安全問題。

談一談對CDN的理解

(1)節省骨幹網帶寬，減小帶寬需求量；

(2)提供服務器端加速，解決因爲用戶訪問量大形成的服務器過載問題；

(3)服務商能使用Web Cache技術在本地緩存用戶訪問過的Web頁面和對象，實現相同對象的訪問無須佔用主幹的出口帶寬，並提升用戶訪問因特網頁面的相應時間的需求；

(4)能克服網站分佈不均的問題，而且能下降網站自身建設和維護成本；

(5)下降「通訊風暴」的影響，提升網絡訪問的穩定性。

osi模型

物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層；

前端性能優化

網絡相關

一、儘可能減小 HTTP 請求個數——須權衡

二、使用 CDN（內容分發網絡）

三、爲文件頭指定 Expires 或 Cache-Control ，使內容具備緩存性

四、使用 gzip 壓縮內容

五、減小 DNS 查找次數

六、配置 ETags

七、減小 Cookie 的大小

八、使用無 cookie 的域

九、避免 404

十、DNS預解析

css相關

一、避免使用 CSS 表達式

二、用 <link> 代替 @import

三、避免使用濾鏡

js相關

一、精簡 CSS 和 JS

二、剔除重複的 JS 和 CSS

三、開發智能事件處理程序

html相關

一、避免空的 src 和 href

二、把 CSS 放到頂部

三、把 JS 放到底部

四、將 CSS 和 JS 放到外部文件中

五、避免跳轉

六、使 AJAX 可緩存

七、儘早刷新輸出緩衝

八、使用 GET 來完成 AJAX 請求

九、減小 DOM 元素個數

十、根據域名劃分頁面內容

十一、儘可能減小 iframe 的個數

十二、減小 DOM 訪問

1三、預渲染

圖像、文件相關

一、延遲加載

二、預加載

三、優化圖像

四、優化 CSS Spirite

五、不要在 HTML 中縮放圖像——須權衡

六、保持單個內容小於25K

七、favicon.ico要小並且可緩存

八、打包組件成複合文本

Webpack相關

一、對於 Webpack4，打包項目使用 production 模式，這樣會自動開啓代碼壓縮

二、使用 ES6 模塊來開啓 tree shaking，這個技術能夠移除沒有使用的代碼

三、優化圖片，對於小圖可使用 base64 的方式寫入文件中

四、按照路由拆分代碼，實現按需加載

五、給打包出來的文件名添加哈希，實現瀏覽器緩存文件