一羞芍、webpack方向

webpack優(yōu)化其實(shí)可以歸為HTTP層面的優(yōu)化（網(wǎng)絡(luò)層面）盒发。因?yàn)镠TTP這一層的優(yōu)化兩大方向就是：減少請(qǐng)求次數(shù)和縮短單次請(qǐng)求所花費(fèi)的時(shí)間。而這兩個(gè)優(yōu)化點(diǎn)的手段就是“資源的合并與壓縮”，正是我們每天用構(gòu)建工具在做的事情，webpack無(wú)疑是最主流的炮车。
webpack的優(yōu)化主要是兩個(gè)主題：構(gòu)建過(guò)程時(shí)間太長(zhǎng)和打包的文件體積太大。
（1）構(gòu)建過(guò)程時(shí)間太長(zhǎng)這個(gè)問(wèn)題馏颂，因?yàn)椴簧婕爱a(chǎn)品體驗(yàn)層面示血，所以不被重視很正常，打包慢的原因多是因?yàn)橹貜?fù)打包救拉，第三方庫(kù)（以node_modules為代表），CommonsChunkPlugin每次構(gòu)建時(shí)都會(huì)重新構(gòu)建一次vendor瘫拣，而平時(shí)一般從搭建工程開(kāi)始這些第三方庫(kù)就基本不會(huì)動(dòng)亿絮，不用每次打包時(shí)都從頭構(gòu)建一遍，浪費(fèi)時(shí)間麸拄。（補(bǔ)充：vendor.js文件是所有第三方庫(kù)打包合并的結(jié)果派昧，比如vuecli項(xiàng)目最終會(huì)在dist下打包生成一個(gè)chunk-vendors.js）。推薦用DllPlugin工具拢切，它會(huì)把第三方庫(kù)單獨(dú)打包到一個(gè)文件中蒂萎，這個(gè)文件就是一個(gè)單純的依賴庫(kù)，這個(gè)依賴庫(kù)不會(huì)跟著你的業(yè)務(wù)代碼一起被重新打包淮椰，只有當(dāng)依賴自身發(fā)生版本變化才會(huì)重新打包五慈。（其他的工具比如用happyPack將loader由單進(jìn)程轉(zhuǎn)為多進(jìn)程加快速度就不多說(shuō)了，補(bǔ)充下webpack是單線程的）
（2）打包的文件體積太大這個(gè)問(wèn)題主穗，有三個(gè)方面可以優(yōu)化：按需加載泻拦、清除冗余代碼、用Gzip壓縮忽媒。按需加載就不說(shuō)了争拐，清除冗余代碼從webpack2開(kāi)始就推出了tree-Shaking，它可以在編譯的過(guò)程中獲悉哪些模塊并沒(méi)有真正被使用晦雨，這些沒(méi)用的代碼架曹，在最后打包的時(shí)候會(huì)被去除。比如一個(gè)js文件export出了2個(gè)函數(shù)闹瞧，其中一個(gè)函數(shù)沒(méi)有在任何地方import使用過(guò)绑雄，打包時(shí)tree-shaking就會(huì)把它刪掉。到了webpack4就內(nèi)置了uglifyjs-webpack-plugin對(duì)代碼做壓縮了夹抗，它會(huì)刪掉一些console語(yǔ)句绳慎、注釋等一些對(duì)開(kāi)發(fā)者有用而對(duì)用戶無(wú)用的代碼。

二、Gzip方向

Gzip壓縮背后的原理是在一個(gè)文本文件中找出一些重復(fù)出現(xiàn)的字符串杏愤，臨時(shí)替換他們靡砌，來(lái)使整個(gè)文件變小，所以比較適合文本文件珊楼，不適合圖片通殃，所以文件中代碼的重復(fù)率越高，壓縮率就越高厕宗，使用Gzip的收益就越大画舌。通常Gzip壓縮率能達(dá)到60%~70%，尤其是上面講的第三方庫(kù)打包合并成vendor.js文件已慢，體積就不小曲聂。Gzip壓縮可以是前端打包構(gòu)建的時(shí)候做，也可以服務(wù)端實(shí)時(shí)地去壓縮佑惠，我做過(guò)的項(xiàng)目通常都是我前端去壓縮朋腋。壓縮/解壓就是犧牲服務(wù)器壓縮的時(shí)間和瀏覽器解壓的時(shí)間去換網(wǎng)絡(luò)傳輸?shù)臅r(shí)間。我做過(guò)的項(xiàng)目一般會(huì)設(shè)置10KB這么一個(gè)閥值膜楷，打包后大于10KB的js\css\html文件才需要壓縮旭咽。如果打包出來(lái)的都是1K、2K的文件赌厅，就沒(méi)必要壓縮了穷绵。
簡(jiǎn)要說(shuō)下Vue項(xiàng)目配置Gzip的方法：1、首先npm安裝compression-webpack-plugin庫(kù)特愿，2仲墨、在vue.config.js里配置：

const CompressionPlugin = require("compression-webpack-plugin")
module.exports = {
    publicPath: process.env.NODE_ENV === 'production'? '/canteen/': '/',
    productionSourceMap:false, //不生成.js.map文件，加速構(gòu)建速度
    configureWebpack: config => { //webpack配置Gzip壓縮
        if(process.env.NODE_ENV === 'production'){
            return {
                plugins:[new CompressionPlugin({
                    test:/\.js$|\.html$|\.css$/,
                    threshold:10240, //超過(guò)10KB的才需要壓縮
                    deleteOriginalAssets:false //是否刪除原文件
                })]
            }
        }
},
}

服務(wù)端也需要配置洽议，當(dāng)支持Gzip的瀏覽器發(fā)起http請(qǐng)求時(shí)宗收，會(huì)自動(dòng)在請(qǐng)求頭帶上accept-encoding：gzip，服務(wù)端就返回壓縮后的文件亚兄，瀏覽器再解壓縮混稽。如果請(qǐng)求頭沒(méi)有這個(gè)就返回原文件。
服務(wù)端配置Gzip审胚。有動(dòng)態(tài)和靜態(tài)兩種匈勋。服務(wù)端動(dòng)態(tài)gzip是常見(jiàn)的方案，即服務(wù)端判斷瀏覽器http請(qǐng)求頭中的Accept-Encoding是否有g(shù)zip膳叨，有的話就說(shuō)明瀏覽器支持gzip洽洁，服務(wù)器就實(shí)時(shí)壓縮生成gzip返回給瀏覽器，否則就返回原文件菲嘴。但是這種模式是比較消耗服務(wù)器CPU的饿自，如果前端打包的時(shí)候就壓縮好汰翠，把原文件和gzip文件全丟到服務(wù)器上，服務(wù)器不干壓縮的活昭雌，只區(qū)分瀏覽器是不是支持gzip复唤，支持就返gzip文件，不支持就返原文件烛卧，那就能省去服務(wù)器動(dòng)態(tài)壓縮的環(huán)節(jié)佛纫。注意：因?yàn)長(zhǎng)inux系統(tǒng)下nginx不能向磁盤寫文件，所以服務(wù)端只能實(shí)時(shí)生成总放。另外呈宇，如果你公司分配給你的服務(wù)器數(shù)量少，就不要用nginx動(dòng)態(tài)壓縮了局雄。
服務(wù)器nginx配置靜態(tài)gzip方法：
在nginx.config的目標(biāo)應(yīng)用location下配置：

gzip_static on;
gzip_http_version 1.1;
gzip_proxied expired no-cache no-store private auth;
gzip_disable "MSIE [1-6]\.";
gzip_vary on;

三甥啄、圖片優(yōu)化方向

圖片的優(yōu)化其實(shí)就是根據(jù)業(yè)務(wù)場(chǎng)景，在不同格式的圖片之間做選擇哎榴。當(dāng)前廣泛使用的圖片格式有jpeg/jpg型豁、png、svg尚蝌、base64、webP充尉，再加個(gè)雪碧圖方案飘言。我們的目標(biāo)依然還是資源壓縮和減少HTTP請(qǐng)求。
（1）jpeg/jpg：有損壓縮驼侠、體積小姿鸿、加載快、不支持透明倒源。這種格式最大特點(diǎn)就是有損壓縮苛预，但是即使被稱為有損壓縮，jpg仍然是一種高質(zhì)量的壓縮方式笋熬，當(dāng)它的質(zhì)量問(wèn)題不被我們?nèi)庋鄄煊X(jué)热某，就沒(méi)問(wèn)題。JPG適合用于呈現(xiàn)色彩豐富的圖片胳螟，背景圖昔馋、輪播圖、Banner圖基本都會(huì)用jpg格式糖耸。淘寶京東首頁(yè)大圖都是jpg的秘遏。他也有缺陷，不支持透明是第一個(gè)嘉竟、第二個(gè)是展示logo等線條感比較強(qiáng)的圖形時(shí)模糊感比較明顯邦危。
（2）png：無(wú)損壓縮洋侨、質(zhì)量高、體積大、支持透明。唯一的bug就是體積大俄精，特點(diǎn)是支持透明赴恨。png-8和png-24，就是位數(shù)不一樣抡草，8位的最多支持2的8次方（256）種顏色，24位的最多支持2的24次方（1600萬(wàn)）種顏色，相應(yīng)的體積也更大锅知，一般場(chǎng)景用png-8足夠了。一般logo脓钾、顏色簡(jiǎn)單售睹、線條明顯的圖片用png。淘寶首頁(yè)不論logo大小可训，全都用的png昌妹。
（3）svg：文本文件、體積小握截、不失真飞崖、兼容性好。唯一bug是渲染成本比較高谨胞。svg文件的體積甚至比jpg更小固歪，它最顯著的特點(diǎn)是可以無(wú)限放大而不失真，一張svg足以適配n種分辨率胯努。svg是文本文件牢裳，可編程，可以寫到html里和html一起下載不占用HTTP請(qǐng)求叶沛。實(shí)際開(kāi)發(fā)中蒲讯，我們一般會(huì)把svg寫入獨(dú)立文件后再引入html：<img src="xxx.svg" alt=""> 如果設(shè)計(jì)師沒(méi)有給我們svg文件，我們也可以用阿里的iconfont在線矢量圖形庫(kù)去做灰署。
（4）base64：文本文件判帮、雪碧圖的補(bǔ)充方案。base64也一樣可以寫到html里氓侧，不占用HTTP請(qǐng)求脊另。base64編碼后圖片體積會(huì)比原來(lái)的大1/3，如果你頁(yè)面圖標(biāo)很小约巷，又很少偎痛，又不想合成雪碧圖，就可以用base64独郎。如果大圖也用base64轉(zhuǎn)碼踩麦，比起省掉的HTTP請(qǐng)求枚赡，體積膨脹反而會(huì)帶來(lái)性能開(kāi)銷。所以base64適合小圖標(biāo)谓谦。
（5）webP：年輕的全能型選手贫橙。硬傷是很新，兼容性差反粥。它是谷歌專為web開(kāi)發(fā)的圖片格式卢肃，目的是加快圖片加載速度，所以只有chrome全程兼容才顿。它支持有損壓縮莫湘、無(wú)損壓縮、支持透明郑气、動(dòng)圖等等幅垮，如果兼容性解決了，是最合適的方案尾组。兼容的話可以交給服務(wù)端忙芒，服務(wù)器根據(jù)HTTP請(qǐng)求頭的accept字段來(lái)決定返回什么格式的圖片。accept包含image/webp時(shí)就返回webp格式讳侨。

四呵萨、CDN方向

使用CDN目的是使http傳輸路徑變短。CDN （Content Delivery Network跨跨，即內(nèi)容分發(fā)網(wǎng)絡(luò)）指的是一組分布在各個(gè)地區(qū)的服務(wù)器甘桑。這些服務(wù)器存儲(chǔ)著數(shù)據(jù)的副本，服務(wù)器可以按照就近原則把距離客戶端最近的服務(wù)器上的資源返回歹叮。
瀏覽器緩存和本地存儲(chǔ)帶來(lái)的性能提升，是在“已經(jīng)獲取到資源了再存起來(lái)铆帽，方便下一次的訪問(wèn)”咆耿，只能加快二次請(qǐng)求的速度，而CDN可以縮短首次請(qǐng)求的時(shí)間爹橱。CDN服務(wù)器上一般只存靜態(tài)資源萨螺。它的核心是是緩存和回源，緩存就是部署時(shí)把靜態(tài)資源copy一份到CDN服務(wù)器上愧驱，回源就是CDN發(fā)現(xiàn)自己沒(méi)有這個(gè)資源（一般是靜態(tài)資源過(guò)期了）慰技，轉(zhuǎn)頭再向根服務(wù)器訪問(wèn)資源。
另外组砚，一般CDN服務(wù)器和根服務(wù)器的域名會(huì)用不一樣的吻商，比如www.taobao.com它用的CDN服務(wù)器域名是g.alicdn.com。這樣做有一個(gè)額外的好處糟红，原本訪問(wèn)www.taobao.com帶上的Cookie艾帐，在訪問(wèn)g.alicdn.com不會(huì)被帶上乌叶，節(jié)省了開(kāi)銷，因?yàn)镃ookie 是緊跟域名的柒爸，同一個(gè)域名下的所有請(qǐng)求准浴，都會(huì)攜帶 Cookie，換種說(shuō)法就是訪問(wèn)CDN獲取靜態(tài)資源時(shí)HTTP不會(huì)帶上Cookie捎稚，而獲取靜態(tài)資源時(shí)也壓根用不到Cookie乐横。

五、服務(wù)端渲染方向

先說(shuō)客戶端渲染今野。是把HTML葡公，JS這些都下載下來(lái)，在瀏覽器里跑一遍JS腥泥，根據(jù)JS的運(yùn)行結(jié)果生成DOM匾南。服務(wù)端渲染就是在服務(wù)端運(yùn)行js，生成DOM蛔外，再把完整的html返回給瀏覽器蛆楞。所以服務(wù)端也是實(shí)時(shí)渲染的，消耗服務(wù)器CPU夹厌，高并發(fā)是個(gè)瓶頸豹爹，所以如果不是服務(wù)器性能很強(qiáng)大，不會(huì)優(yōu)先考慮服務(wù)端渲染矛纹，就算做臂聋，一般也只會(huì)給首屏頁(yè)面做服務(wù)端渲染。
另外或南，很多網(wǎng)站做服務(wù)端渲染的首要目的也并不是性能向的考慮孩等，而是出于SEO優(yōu)化的目的〔晒唬客戶端渲染時(shí)肄方，搜索引擎可不會(huì)去跑js，只會(huì)查找當(dāng)前html靜態(tài)的關(guān)鍵字蹬癌。所以权她，一般都是其他性能優(yōu)化的招數(shù)都用盡了再考慮服務(wù)端渲染。有人說(shuō)：“ssr這個(gè)東西好是好逝薪，可是流量上來(lái)的話隅要，即便優(yōu)化的再好也是非常吃硬件資源的。虛擬運(yùn)維的話1核CPU的容器也就能支撐幾十甚至十幾的QPS”董济。

六步清、HTTP2方向

http1.1的并行加載資源數(shù)為6到8個(gè)（準(zhǔn)確的說(shuō)是每個(gè)域最多只能同時(shí)建立6個(gè)鏈接）
http2的優(yōu)點(diǎn)在于一個(gè)域只建立一次TCP連接，使用多路復(fù)用感局，同時(shí)傳輸?shù)馁Y源數(shù)幾乎沒(méi)有上限尼啡，這樣就不用使用雪碧圖暂衡、合并JS/CSS等方法了。如果沒(méi)有正確配置崖瞭，nginx會(huì)自動(dòng)切換到HTTP/1.1狂巢，所以兼容性很好。
不需要開(kāi)發(fā)书聚，只需要服務(wù)端nginx配置：要求openssl版本高于1.0.2唧领，然后修改nginx.config：listen 443 ssl 改為listen 443 ssl http2，重啟nginx即可雌续。

七斩个、瀏覽器緩存（HTTP緩存）方向

HTTP緩存是指當(dāng)下一次發(fā)HTTP請(qǐng)求資源前，判斷下是否應(yīng)該從客戶端本地拿緩存驯杜。分為強(qiáng)緩存和協(xié)商緩存受啥。如果命中強(qiáng)緩存，則客戶端不再詢問(wèn)服務(wù)器而直接去客戶端本地讀取資源鸽心；如果命中協(xié)商緩存滚局，就發(fā)HTTP詢問(wèn)服務(wù)器是否應(yīng)該讀本地的資源，服務(wù)器不會(huì)返回所請(qǐng)求的資源顽频，而是告訴客戶端可以直接從客戶端本地加載這個(gè)資源藤肢，于是瀏覽器就又會(huì)從自己的緩存中去加載這個(gè)資源。當(dāng)兩種模式都沒(méi)命中糯景，瀏覽器直接從服務(wù)器加載資源嘁圈。

所以，強(qiáng)緩存與協(xié)商緩存的共同點(diǎn)是：如果命中蟀淮，都是從客戶端緩存中加載資源最住，而不是從服務(wù)器加載資源數(shù)據(jù)；區(qū)別是：強(qiáng)緩存不發(fā)請(qǐng)求到服務(wù)器怠惶，協(xié)商緩存會(huì)發(fā)請(qǐng)求到服務(wù)器温学。

1、強(qiáng)緩存怎么做的：

先說(shuō)早期的expire甚疟。早些年沒(méi)有協(xié)商緩存的概念，緩存指的也是強(qiáng)緩存逃延，一直用expire览妖。expire的值是一個(gè)時(shí)間戳——expires: Wed, 11 Sep 2019 16:12:18 GMT，是服務(wù)器響應(yīng)HTTP時(shí)返回給瀏覽器的揽祥，意思就是“我返回給你的文件資源讽膏，你要緩存起來(lái)，在這個(gè)時(shí)間節(jié)點(diǎn)前你都去讀緩存拄丰，不要再問(wèn)我要了”府树。所以expire有個(gè)bug俐末，服務(wù)器返回的時(shí)間戳是服務(wù)器時(shí)間，而瀏覽器發(fā)HTTP前用來(lái)和expire比較的是本地時(shí)間奄侠，兩個(gè)時(shí)間可能不一致卓箫。

再說(shuō)cache-control。cache-control就是expire的升級(jí)版了垄潮，強(qiáng)緩存和協(xié)商緩存都由它控制烹卒。如果和expire同時(shí)出現(xiàn)，cache-control優(yōu)先級(jí)更高弯洗。cache-control有很多種取值：

private: 只有瀏覽器可以緩存旅急，(默認(rèn)值)
public:可以被任何緩存區(qū)緩存，包括瀏覽器和代理服務(wù)器
max-age=xxx: 緩存將在 xxx 秒后失效
s-maxage=xxx: 代理服務(wù)上的緩存將在 xxx 秒后失效
no-cache:需要使用協(xié)商緩存來(lái)驗(yàn)證緩存數(shù)據(jù)
no-store: 所有內(nèi)容都不會(huì)緩存牡整，強(qiáng)制緩存和協(xié)商緩存都不會(huì)觸發(fā)

max-age的值就是一個(gè)時(shí)間段了（36000秒這樣）藐吮，這是個(gè)相對(duì)時(shí)間，解決了expire的bug逃贝。max-age=xxx并不是獨(dú)立的屬性谣辞，如你設(shè)置了cache-control:max-age=1800，等價(jià)于cache-Control:private, max-age=1800秋泳。

s-maxage 不像 max-age 一樣為大家所熟知潦闲。它用來(lái)表示代理服務(wù)器上的資源緩存期限，所以只對(duì) public 緩存有效（如果寫了s-maxage迫皱，pubic可以省略不寫）歉闰。cache-control: max-age=36000,s-maxage=31536000，兩者同時(shí)出現(xiàn)時(shí)s-magage優(yōu)先級(jí)更高卓起。

2和敬、協(xié)商緩存怎么做的：

只要服務(wù)器響應(yīng)的頭里寫上cache-control:no-cache，就表示瀏覽器下一次請(qǐng)求相同文件時(shí)需要使用協(xié)商緩存戏阅。

先說(shuō)Last-Modified / If-Modified-Since昼弟。和expire一樣last-modified是一個(gè)時(shí)間戳，瀏覽器第一次跟服務(wù)器請(qǐng)求資源文件時(shí)奕筐，服務(wù)器會(huì)在響應(yīng)頭寫上last-modified表示文件最后修改的時(shí)間舱痘，瀏覽器要把這個(gè)文件和最后修改時(shí)間都緩存起來(lái)，下一次請(qǐng)求相同文件時(shí)离赫，把這個(gè)時(shí)間寫到if-modified-since字段上芭逝，發(fā)給服務(wù)器，服務(wù)器根據(jù)瀏覽器傳過(guò)來(lái)if-modified-since和資源在服務(wù)器上的最后修改時(shí)間判斷資源是否有變化渊胸，如果沒(méi)有變化則返回304 Not Modified旬盯，但是不會(huì)返回資源內(nèi)容；如果有變化，就正常返回資源文件胖翰。瀏覽器收到304后就從本地緩存加載資源接剩。值得注意的是，如果服務(wù)器判斷資源文件沒(méi)變化時(shí)不會(huì)再往響應(yīng)頭里寫last-modified字段了萨咳。這種方式在絕大多數(shù)情況是足夠可靠的懊缺，但一般文件系統(tǒng)能感知到文件修改的最小粒度是s，所以一些極限情況下某弦，文件內(nèi)容修改了修改時(shí)間不一定變桐汤。所以產(chǎn)生了ETag方式。

再說(shuō)ETag / If-None-Match靶壮。ETag的值是根據(jù)資源文件內(nèi)容生成的唯一標(biāo)識(shí)字符串怔毛，比如：ETag: W/"2a3b-1602480f459"，只要文件內(nèi)容變化唯一標(biāo)識(shí)就不一樣腾降。它的工作流程和“最后修改時(shí)間”基本一樣：第一次請(qǐng)求資源文件時(shí)拣度，服務(wù)器計(jì)算好ETag值并寫在響應(yīng)頭，瀏覽器收到后把資源文件和ETag值緩存起來(lái)螃壤，下一次請(qǐng)求相同文件時(shí)抗果，把這個(gè)ETag寫到if-none-match字段上，發(fā)給服務(wù)器奸晴，服務(wù)器計(jì)算文件當(dāng)前的ETag冤馏，比較瀏覽器傳來(lái)的if-none-match。我們看到寄啼，Etag的計(jì)算是實(shí)時(shí)的逮光，會(huì)影響服務(wù)端的性能，而且文件越大墩划，開(kāi)銷越大涕刚。因此這個(gè)方案要謹(jǐn)慎使用，有的公司甚至直接不讓用ETag方法乙帮。

Etag可以是ETag: W/"2a3b-1602480f459"杜漠，也可以是ETag:"2a3b-1602480f459"，以W/開(kāi)頭的表示weak tag（弱Etag察净，不帶W/的就是強(qiáng)Etag）驾茴。

最后總結(jié)下協(xié)商緩存。大多數(shù)情況下氢卡，可以關(guān)掉ETag而只用Last-Modified沟涨。ETag是特殊情況下Last-Modified的補(bǔ)充，而不是替代异吻。兩者都存在的情況下ETag優(yōu)先級(jí)比Last-Modified高。不管哪個(gè)方法，“最后修改時(shí)間”和“唯一標(biāo)識(shí)”都由瀏覽器來(lái)存诀浪，服務(wù)器是不可能花費(fèi)空間來(lái)保存緩存狀態(tài)的棋返。

3、瀏覽器把資源文件緩存在什么地方雷猪？

可以看到睛竣，瀏覽器會(huì)從3個(gè)地方讀緩存：

from memory cache：從內(nèi)存讀緩存，最快也最短命求摇，頁(yè)面關(guān)閉射沟，文件就沒(méi)了。

from ServiceWorker：從瀏覽器的service worker讀取緩存与境，service worker是一個(gè)瀏覽器中的進(jìn)程而不是瀏覽器內(nèi)核下的線程验夯，因此它在被注冊(cè)安裝之后，能夠被在多個(gè)頁(yè)面中使用摔刁，也不會(huì)因?yàn)轫?yè)面的關(guān)閉而被銷毀挥转。所以瀏覽器關(guān)了文件才銷毀。

from disk cache：從瀏覽器客戶端本地磁盤讀緩存共屈，瀏覽器關(guān)閉绑谣，磁盤文件還在。

至于緩存到哪里這個(gè)事不是標(biāo)準(zhǔn)規(guī)范拗引，純屬瀏覽器個(gè)人行為借宵。各家瀏覽器的策略不盡相同，比如chrome會(huì)把體積大的js矾削、css放到磁盤壤玫，小的放內(nèi)存；而火狐瀏覽器就只會(huì)存在內(nèi)存里怔软，沒(méi)有from disk cache垦细，不會(huì)放到磁盤。

八挡逼、從瀏覽器渲染頁(yè)面機(jī)制的方向

我們一般說(shuō)的瀏覽器內(nèi)核可以分成2部分：JS引擎和渲染引擎括改。JS引擎就是專門解釋js代碼的；渲染引擎又包含了：HTML解釋器家坎、CSS解釋器嘱能、布局、網(wǎng)絡(luò)虱疏、存儲(chǔ)惹骂、圖形、音視頻做瞪、圖片解碼器等等零部件对粪。整體來(lái)看瀏覽器的一次渲染過(guò)程就是：調(diào)用瀏覽器各個(gè)零部件把網(wǎng)頁(yè)資源文件從服務(wù)器上下載下來(lái)右冻，轉(zhuǎn)換為圖像的過(guò)程。渲染過(guò)程對(duì)我們前端開(kāi)發(fā)來(lái)說(shuō)是個(gè)黑盒著拭，但了解了其中的機(jī)制可以幫助我們避免一些問(wèn)題纱扭。
再詳細(xì)點(diǎn)的渲染過(guò)程是：
（1）HTML文件下載完以后，HTML解析器就開(kāi)始工作了儡遮，它自頂向下地解析HTML元素乳蛾，最終生成DOM樹(shù)；
（2）當(dāng)HTML解析到link標(biāo)簽或者style標(biāo)簽之后鄙币，CSS解析器就開(kāi)始工作了肃叶，開(kāi)始構(gòu)建CSSOM樹(shù)；
（3）DOM樹(shù)和CSSOM樹(shù)都構(gòu)建完成后十嘿，兩者結(jié)合生成了Render Tree——渲染樹(shù)因惭，其實(shí)就是帶有樣式規(guī)則的DOM樹(shù)；
（4）然后布局引擎開(kāi)始工作详幽，遞歸地為渲染樹(shù)的每個(gè)元素計(jì)算它的尺寸筛欢、位置，給出它們出現(xiàn)在屏幕上的精確坐標(biāo)唇聘；
（5）最后圖形引擎（和GPU有關(guān)）開(kāi)始工作版姑，遍歷渲染樹(shù)，把每個(gè)節(jié)點(diǎn)繪制出來(lái)迟郎。
可以看到從創(chuàng)建渲染樹(shù)開(kāi)始就是徹底的黑盒了剥险，我們能優(yōu)化的地方不多。另外可以看到宪肖，剛才我說(shuō)的這個(gè)流程里是沒(méi)有JS參與的表制，因?yàn)镴S的本質(zhì)是修改DOM，沒(méi)有它渲染照樣是完整的控乾，這里先不考慮么介，后面再說(shuō)。這個(gè)流程里很重要的一點(diǎn)是HTML解析和CSS解析是并行的蜕衡，DOM樹(shù)和CSSOM樹(shù)都生成完畢了才能進(jìn)行下一步——構(gòu)建渲染樹(shù)壤短。所以如果DOM樹(shù)已經(jīng)生成了，但CSSOM樹(shù)還沒(méi)生成慨仿，我們就說(shuō)CSS阻塞了久脯，這個(gè)時(shí)候頁(yè)面是空白的，即便已經(jīng)有DOM樹(shù)了镰吆，只要CSSOM不ok帘撰，渲染就沒(méi)法進(jìn)行下去（目的是避免HTML文本裸奔在用戶眼前）。所以万皿，業(yè)內(nèi)的一個(gè)共識(shí)是：把CSS放在HTML盡量靠前摧找，盡早解析到link或style標(biāo)簽核行，讓CSS解析器工作起來(lái)。
ok蹬耘，我們一方面要讓CSS解析器盡早工作起來(lái)钮科，還要讓它工作快起來(lái)。我們能做的就是減少CSS選擇器復(fù)雜度婆赠。提升的方案主要是：
（1）后代選擇器的開(kāi)銷是最高的，深度不要超過(guò)3層佳励，盡可能使用id和類來(lái)關(guān)聯(lián)休里；
（2）少用標(biāo)簽選擇器，用類選擇器替代赃承；
（3）那些可以繼承的屬性妙黍，避免重復(fù)匹配重復(fù)定義；
（4）避免使用通配符瞧剖，只對(duì)需要用到的元素進(jìn)行選擇拭嫁。
另外非常重要一點(diǎn)的是，css選擇器是從右到左解析的抓于，#myList li{} 像這種寫法做粤，看上去是先找到了id為myList的元素，縮短了時(shí)間捉撮，但它實(shí)際是先找到所有l(wèi)i標(biāo)簽怕品，再找到哪個(gè)是包含在myList下的。所以這種情況直接用類選擇器最合適了巾遭。
最后來(lái)說(shuō)有JS參與進(jìn)來(lái)的情況肉康。JS的問(wèn)題是阻塞。JS引擎雖然獨(dú)立于渲染引擎（也就是不同線程）灼舍，按理說(shuō)吼和，他們也可以并行工作，但是JS代碼里充滿了DOM的操作骑素、CSS的操作炫乓，所以為了保證JS執(zhí)行的時(shí)候有確定的DOM和CSS，JS執(zhí)行的時(shí)候DOM和CSSOM的構(gòu)建都會(huì)暫停砂豌。也就是當(dāng)HTML解析到script標(biāo)簽時(shí)厢岂，瀏覽器會(huì)暫停渲染過(guò)程，將控制權(quán)交給JS引擎阳距，JS引擎執(zhí)行script標(biāo)簽內(nèi)的代碼（外部的JS還要先下載再執(zhí)行）塔粒，執(zhí)行完了再把控制權(quán)交給渲染引擎，繼續(xù)DOM和CSSOM的構(gòu)建筐摘。所以這種情況你把script標(biāo)簽寫在html最后也無(wú)濟(jì)于事卒茬，還是會(huì)阻塞船老。瀏覽器之所以會(huì)一股腦的暫停DOM樹(shù)構(gòu)建，是因?yàn)闉g覽器不知道這塊js代碼有沒(méi)有操作DOM圃酵， 但是我們開(kāi)發(fā)是知道的柳畔，如果js代碼沒(méi)有操作DOM和CSS，那就完全可以并行執(zhí)行郭赐，所以HTML也提供了async和defer屬性薪韩，來(lái)避免沒(méi)必要的阻塞。
默認(rèn)模式（阻塞下載捌锭，下載完立刻執(zhí)行）俘陷。
async模式（異步下載，下載完立刻執(zhí)行）：<script async src="xxx.js"></script> HTML解析器解析到這兒時(shí)會(huì)異步的下載xxx.js文件观谦，但是當(dāng)下載結(jié)束時(shí)拉盾，js會(huì)立刻執(zhí)行，這個(gè)時(shí)候渲染引擎也會(huì)被暫停豁状。
defer模式（異步下載捉偏，下載完延遲執(zhí)行）：<script defer src="xxx.js"></script> 和async一樣，xxx.js也是異步下載泻红，但是它會(huì)等到DOM樹(shù)和CSSOM樹(shù)都構(gòu)建完成后再執(zhí)行夭禽。