本文由@IT·平頭哥聯(lián)盟-首席填坑官?蘇南 分享

引言

? 大家好，這里是@IT·平頭哥聯(lián)盟，我是首席填坑官——蘇南(South·Su)，今天是國慶節(jié)的第二天，這個假期沒有外出(不要問我為什么，自己腦補～??)，前些天分享了一篇前端面試匯總的文章，有些同學(xué)在群里問了其中的一些細節(jié)，其中大家最關(guān)心的性能優(yōu)化這塊，今天整理了公司項目中的一些認為不錯的點，跟大家一起分享，如有理解錯誤，請糾正。

優(yōu)化概括

1、首先最基本的，CSS樣式表放在頁面頭部Head內(nèi)且link鏈?zhǔn)揭?，javascript放在底部body結(jié)束標(biāo)簽前避免阻塞。

2、js/html/css/圖片都做壓縮合并，圖片預(yù)加載、懶加載，也是老生常談了，在這里推薦一個圖片無損極限壓縮的工具，能壓小60～80%左右,比較麻煩的是每次要手動操作——TinyPNG，有興趣的同學(xué)了可以了解一下他們的API，自己封裝一個服務(wù)調(diào)用壓縮，不過免費次數(shù)有限制哦。

3、減少DOM元素數(shù)量，減少DOM的操作：

• 減少 DOM 元素數(shù)量，合理利用:after、:before等偽類，避免頁面過深的層級嵌套;
• 優(yōu)化javascript性能,減少DOM操作次數(shù)(或集中操作)，能有效規(guī)避頁面重繪/重排;
• 如何才算少？抱歉，這個沒有辦法給出一個標(biāo)準(zhǔn)精確的答案，只能說盡可能去做優(yōu)化，如數(shù)據(jù)分頁、首屏直出、按需加載等。

4、靜態(tài)資源CDN分發(fā)：

• CDN的意圖就是盡可能的減少資源在轉(zhuǎn)發(fā)、傳輸、鏈路抖動等情況下順利保障信息的連貫性；
• 通俗的講就是CDN系統(tǒng)能夠?qū)崟r地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點的連接、負載狀況以及到用戶的距離和響應(yīng)時間等綜合信息將用戶的請求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點上———曾經(jīng)人們都說距離產(chǎn)生美，后來變了都說距離產(chǎn)生小三，在這里距離產(chǎn)生的是用戶跑路了，所以足以說明CDN的重要性；
• CDN采用各節(jié)點緩存的機制緩存很嚴重，當(dāng)我們項目的靜態(tài)資源(只是之前存放在cdn上的資源)修改后，如果CDN緩存沒有做相應(yīng)更新，則看到的還是舊的網(wǎng)頁，解決的辦法是刷新緩存，七牛云、騰訊云都可單獨針對某個文件/目錄進行刷新；
• 廣告常說：XX酒雖好，可不要貪杯哦，CDN托管也是如此，合理使用：圖片、常用js組件、css重置樣式等，即不常改動的文件即可走CDN，包括項目內(nèi)的一些介紹頁；
• img標(biāo)簽要設(shè)置高寬,同樣這么做它也能減少頁面重繪/重排，使用 WebP 格式圖片，它能對原圖(png)做到近98%壓縮，當(dāng)然它也不是完美的：

WebP最初在2010年發(fā)布，目標(biāo)是減少文件大小，支持無損、有損壓縮，動態(tài)、靜態(tài)圖片，壓縮比率優(yōu)于 GIF、JPEG、JPEG2000、PNG 等格式，非常適合用于網(wǎng)絡(luò)等圖片傳輸，現(xiàn)在開始已經(jīng)被越來越多的瀏覽器支持，當(dāng)然 WebP 格式也有它的缺點，算法相對其他格式更加復(fù)雜，會在節(jié)省流量資源的同時會占用計算資源，對計算機造成更大的負擔(dān),WebP支持的像素最大數(shù)量是16383x16383。有損壓縮的WebP僅支持8-bit的YUV4:2:0格式。而無損壓縮（可逆壓縮）的WebP支持VP8L編碼與8-bit之ARGB色彩空間。又無論是有損或無損壓縮皆支持Alpha透明通道、ICC色彩配置、XMP詮釋數(shù)據(jù)，更詳細支持說明:caniuse.com

優(yōu)勢：

• 體積小幾乎可以毫不夸張的說，已經(jīng)小的不能再小了；
  
• 小而美的同時，還質(zhì)量好，幾乎看不出來與原圖差別；
  
• 曾經(jīng)的動態(tài)圖gif、jpeg壓縮都會不清晰，但現(xiàn)在對它來說都是so easy～。

缺點/困難：

• 目前并不是所有瀏覽器都支持WebP，因此需要解決瀏覽器適配問題；
  
• 對于已上線的項目，采用WebP需要替換大量圖片，工作量太大(不確定后臺程序是否能搞定)。

5、域名拆分：

• 什么叫拆分域名？很多公司初始項目搭建，都只申請了一個域名，站點的所有內(nèi)容(html/php/jsp、js、css、img等都放在一個域名下)，域名拆分主要為了增加瀏覽器資源請求的并行度即并發(fā)問題，讓瀏覽器能同時發(fā)起更多的請求，也解決了請求默認攜帶的cookie問題，減少了數(shù)據(jù)傳輸字節(jié)；
• 如何拆分？以現(xiàn)在前后端分離式開發(fā)為例，建議分為三大類：
  • 前端類 - 項目業(yè)務(wù)本身的htm、css、js、圖標(biāo)/片等；
  • 靜態(tài)類 - 即上述提到的CDN資源類；
  • 動態(tài)類 - 可歸為后端API接口類；

以下為各瀏覽器請求并發(fā)數(shù)，數(shù)據(jù)來源于chorme搜索，珍愛生命，遠離某……??：

6、 減少http請求次數(shù)

• 是的，你沒有看錯，就是減少http請求次數(shù)，節(jié)省網(wǎng)絡(luò)請求時間，但你可能又會問，前面不是讓拆分域名嗎？？一個是部署拆分，一個是請求減少，沒毛病哦；
• 首先我們來了解一下http的請求過程（簡單通俗的闡述一下）：
  • DNS 域名解析 - 1. 拿出電話，找到某個接頭人的號碼；
  • 發(fā)起 TCP 的 3 次握手 - 2. 接通后暗號：A)、你好，你好，我是長江一號，請問能聽到嗎？B),你好，我是長江二號，能聽到你講話，你能聽到我說什么嗎？A)、能聽到，我們開始講正事吧……;
  • 正常數(shù)據(jù)傳輸中…… - 3. 聊的很嗨；
  • 結(jié)束傳輸斷鏈的 4 次揮手 - 4. 聊完了，準(zhǔn)備告別：A)、(可以是服務(wù)端，也可以是客戶端)該說的我都說完了，你自己看著辦吧；B)、好的我也說完了；B)、(B緊接著又跟A發(fā)了條信息)，再見；A)、然后A收到B的話，而B那邊已經(jīng)放下手機掛了，A等了一下聽B沒有再說啥，也就掛了(掛個毛啊，婊子無情，戲子無義，陪你嘮嗑這么久，都不給個好評～??)；
  • 當(dāng)然，現(xiàn)在的HTTP/2.0的處理有所不同，2.0過程還有TLS/SSL的處理，HTTP是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS則是具有安全性的SSL(Certificate Authority，申請證書)加密傳輸協(xié)議,HTTPS加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議,內(nèi)容傳輸經(jīng)過完整性校驗、內(nèi)容經(jīng)過對稱加密，每個連接生成一個唯一的加密密鑰、第三方無法偽造服務(wù)端(客戶端)身份等眾多優(yōu)勢，同時也有劣勢因為做的事情多了中間對接的次數(shù)同樣需要時間，這也是HTTPS更慢的根本原因。
  • 上兩圖吧，這樣大家看著清晰一些，但暫時只列了HTTP/1.0的，HTTP/2.0的圖下次有時間再補，是有一個大佬指點我的哦，說這樣看起來更騷氣，大家會更喜歡，哈哈～：
    
    本文由@IT·平頭哥聯(lián)盟-首席填坑官?蘇南 分享 - 三次握手

本文由@IT·平頭哥聯(lián)盟-首席填坑官?蘇南 分享 - 四次揮手

結(jié)論：從上面的這個過程可以看出，每一次請求都這么復(fù)雜，減少http的請求次數(shù)是不是很有必要呢？？答案是肯定的，我們會以以下幾個維度來進行優(yōu)化：

• 合并 JS、CSS 文件；
• 圖片/圖標(biāo) sprites 合并，或使用iconfont字體圖標(biāo)，或者SVG Sprites；什么是Svg Sprites?；
• 資源按需加載，即當(dāng)前頁面用到什么，就加載什么，避免加載與當(dāng)前頁面無關(guān)的事情，這一點現(xiàn)在的React/Vue/Angular等MVVM框架，基于webpack編譯打包工具，做的很好；
• 前端數(shù)據(jù)的緩存（如：一個列表頁，進入詳情，再返回，這個用戶的交互行為是很頻繁的，可以對列表的數(shù)據(jù)進度一個緩存，不用每次返回都進行加載，比如5分鐘更新一次。

7、 數(shù)據(jù)設(shè)置緩存，好累寫不動了，http緩存的設(shè)置，之前的面試匯總??如何設(shè)置http緩存？吧；
8、 站點服務(wù)端開啟Gzip壓縮，當(dāng)然還可以了解一下Brotli 或 Zopfli ，據(jù)說 Brotli 比 Gzip 和 Deflate更有效，有興趣的同學(xué)可以了解一下；
8、 避免重定向，盡量減少 iframe 使用，它會阻塞主頁面的渲染;
9、 避免使用CSS Expression（css表達式)又稱Dynamic properties(動態(tài)屬性);
10、 合理使用dns-prefetch、prefetch、 preload、 defer、async：

• dns-prefetch：使用dns-prefetch對項目中用到的域名進行 DNS 預(yù)解析，減少 DNS 查詢，如： <link rel="dns-prefetch" />；BAT各大巨頭都是這么干的，請看下圖，dns的詳細解析過程今天先不講了，碼字碼不動了，寫分享比加班做項目還累，望體諒～；
• prefetch： 它是一個優(yōu)先級非常低的資源加載標(biāo)識，瀏覽器會在空閑時(即主進程資源加載完成后)下載帶有 prefetch標(biāo)識的資源并緩存到disk，在后續(xù)模塊使用到這個文件的時候，會直接從緩存讀取；該功能webpack有個插件，配置后編譯能自動插入到頁面上;
• preload：沒錯，它就是一個可以預(yù)加載資源的屬性，詳細說明請看官方API,一般情況下我們可能會對接下來的業(yè)務(wù)需要的audio、img、font、script等資源進行預(yù)先加載（甚至是下一個路由頁面哦），這樣能達到0秒打開頁面的效果！

• 暫時就想到這么多了，歡迎補充……

  
  
  阿里巴巴的天貓首頁
  
  
  京東首頁
  
  
  首席填坑官?蘇南 的react-redux入門示例

總結(jié)：

• 推薦幾個工具：WebPagetest、Lighthouse、SpeedCurve、New Relic 等主動/被動監(jiān)測工具，都能高效幫助我們分析發(fā)現(xiàn)問題的所在，從而對癥下藥;
• DNS預(yù)解析的是非重要的，它是一個url到解析IP，到查詢根服務(wù)器的一個過程，可能會在下一次單獨總結(jié)出來分享，有興趣的同學(xué)也可以自行先了解一下，
• 要把一個項目做好，每一個細節(jié)都很重要，希望今天的分享能給大家的工作帶來些許幫助，謝謝！
  
  @IT·平頭哥聯(lián)盟專注于前端、測試的分享

文章分享計劃：

最近一直在思考，如何有規(guī)化的分享工作中的積累，國慶這些天也一直看了很多大神寫的博客，最后綜合自身的能力及時間，決定先嘗試寫一個# 動畫 #系列文章，動畫可能主要包含（CSS/Canvas）兩部分，歡迎大家持續(xù)關(guān)注！

　　以上就是今天的分享，新手上路中，我會努力讓自己變得更優(yōu)秀、寫出更好的文章，文章中有不對之處，煩請各位大神斧正。如果你覺得這篇文章對你有所幫助，那就請關(guān)注下方的 公眾號吧。

寶劍鋒從磨礪出，梅花香自苦寒來，做有溫度的攻城獅，公眾號：honeyBadger8

作者：蘇南 - 首席填坑官
交流群：912594095，公眾號：honeyBadger8
本文原創(chuàng)，著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系@IT·平頭哥聯(lián)盟獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明原鏈接及出處。