總結了一些優化性能的小技巧,看官請收好

性能優化幾乎是面試的時候很是高頻的問題,所以總結了這麼幾條特別常見的優化方案送給你們。本文專業詞彙較多,基礎或者接觸比較少的同窗可能概念理解起來比較複雜。但仍是請硬着頭皮把這些概念搞懂,由於特別高頻。css

1.重繪和重排(迴流)

描述

當元素的位置或尺寸發生變化的時候會致使頁面的重排,當元素的信息改變可是不改變位置和尺寸的時候會發生重繪。重繪不必定重排,可是重排必定會發生重繪。並且重排耗費的資源要比重繪大的多html

理解爲何重排和重繪會提升性能?

打個比方,一個靜態網頁。沒有任何交互,從瀏覽器渲染出來以後就不須要改變了,是否是瀏覽器對這個頁面的計算量就特別小。web

假如這是一個動態頁面呢,上面有個輪播圖。那是否是須要瀏覽器事實的進行新的頁面繪製工做,那必然是須要消耗資源的面試

知道了重排和重繪我能夠這樣提升性能

1.減小重繪重排的次數

常看法決方式1:ajax

有的時候須要往 UI 標籤中添加多個 LI 標籤。這個時候不要一個一個的添加 LI 標籤。而是在本地建立好了 LI 標籤組一次性加載進去後端

常看法決方式2:瀏覽器

將元素屬性變爲 none,而後在對其進行修改工做性能優化

2.能重繪別重排

給元素設置某些屬性的時候元素會脫離文檔流,這樣元素的改變就不會形成大面積的重排了,例如絕對定位,瀏覽器定位,使用 CSS3 的某些特性。能夠參考這個網站查看具體哪些屬性會致使重排重繪csstriggers.com/bash

我能夠這樣知道頁面哪些地方重繪重排嚴重

一般性能優化都不是有碰見性的剛開始就對其進行了優化,而是項目遇到性能瓶頸了在對其進行優化,因此知道哪些地方進行了大量的重繪重排是極其重要的。服務器

打開谷歌控制檯 -> More tools -> Rendering -> 選中 Paint flashing

2.防抖和節流

描述

防抖:法師發技能的時候要讀條,技能讀條沒完再按技能就會從新讀條。

節流:法師普攻是須要時間的。無論點的多快,一秒鐘攻擊的次數是有限制的。

實用場景

搜索框搜索內容時請求後端接口

不防抖的方式:輸入內容:12345 , 內容發生改變就請求接口。這樣會請求五次接口

防抖的方式:一樣輸入內容:12345,防抖時間設置爲 500ms,500ms 內用戶輸入新的內容從新讀條。正常狀況下只會請求一次接口

圖片進行懶加載

不節流的方式:滾動條一滾動就監聽頁面元素顯示狀況,顯示的元素就進行圖片加載。滾動條滾動事件是一個很是頻繁的操做,滾動一丟丟就會執行幾十次。

節流的方式:仍是一樣的操做,可是執行代碼進行節流。設置節流時間 30ms 。這就無論這 30ms 滾動事件出發了幾回,個人執行代碼都只執行一次

3.CSS 選擇器優化

描述

.parent .children p span {}
複製代碼

css 的匹配規則是從右往左,而不是從左往右的。道理也很簡單,從右往左是孩子找父親,找曾祖父,從左往右是父親找孩子,找孫子。由於一個孩子只有一個父親,因此只要往上一找發現他父親不符合條件,就說名這個孩子規則不匹配就能夠排除掉。反過來就麻煩了,一個父親有多個孩子,這個孩子不是,換下一個孩子。要排除掉一個父親是很是麻煩的,須要屢次來回尋找

優化方法

最右側命名的惟一性

描述說了匹配規則是從右往左匹配,也就是說最右側的名字惟一性越強,首次符合要求的元素也就越少,須要查找的次數就少。你若是用 * 那完蛋了,全部的元素都要跑一邊,不只僅是 * 。像標籤名的匹配方式能少用就少用

減小層級

雖然多世同堂是一件蠻幸福的事情,老者能夠看到本身的孫子,曾孫子。。。可是這在代碼中確是比較費事的事情。所以少的嵌套會更快速的匹配

4.關於文件的優化

描述

文件的優化須要考慮數量、大小。換言之文件越小、數量越少加載的順序是更快的。

優化

減小代碼體積

最多見的幾種方式就是,對代碼進行壓縮、重複代碼抽取成公共代碼,可是這裏特別強調一下代碼壓縮。如今瀏覽器支持 Gzip 壓縮格式。他是在的將空格、變量名之類的壓縮了以後還能壓縮的一種格式。

像上面這張圖片,就是經典的 Vue 打包以後出現的內容了。途中一共三列,第一列 file(文件名),第二列 size(簡單壓縮以後的大小),第三列 gzipped(gzip壓縮以後的大小)。能夠看出來Gzip 壓縮以後的大小比原來幾乎小了三倍。

減小文件數量

一樣 1M 的大小的文件。一個拆分紅了 5份,一個拆分紅了 100 份。5份的是會優先於 100 份的加載出來的,由於這一塊牽扯到了瀏覽器策略和 http 協議。

  • http 協議:100 份文件會請求 100 次。http 協議請求也是包含內容的,像請求頭,響應頭。這個內容 * 100 也是很大的
  • 瀏覽器策略:同一個域名下面併發請求的個數是有限制的,根據瀏覽器的不一樣這個數量也不固定,100 份文件會請求 100 次。可是他確定不是同時請求的

談一談典型場景

圖標合併成一個。下面是一張圖片帶有六個圖表,這樣使用圖標的時候請求一次就能夠了。

5.使用 CDN 進行優化

描述

CDN的全稱是Content Delivery Network,即內容分發網絡。他簡單說有倆個優點:

  1. 他在不少地區有服務器,用戶下載文件的時候能夠就近下載。好比你在深圳,你能夠直接用深圳的服務器下載文件。而不用千里迢迢的從北京下載文件。專業術語解釋就是:中心平臺的負載均衡、內容分發、調度等功能模塊,使用戶就近獲取所需內容,下降網絡擁塞,提升用戶訪問響應速度和命中率
  2. 上文提到瀏覽器對於一個域名併發請求有數量限制,放到 CDN 上他就是另一個域名。跟公司自己的域名不衝突就能夠提升併發數量

6.利用好存儲技術

描述

首先明確一點是啥能存儲,我這裏想到了三個點:文件存儲、請求存儲、計算存儲

文件存儲

一個 web 項目是由不少的 CSS、JS、HTML 文件組成的,這些文件基本上只有在版本迭代的時候纔會有改動,所以將他們存儲在本地對性能的提高是頗有幫助的

請求存儲

存在交互的項目請求必然分爲倆種,穩定數據請求和非穩定數據請求。穩定數據請求存儲起來能夠減小 ajax 交互。固然了穩定跟不穩定之間的界限是很差界定的,所以須要你本身去進行斷定是永久存儲仍是短暫存儲,比較有表明性的方法就是 localStorage 和 sessionStorage

計算存儲

不少數據並非拿來就能用的,都須要進行處理。像分跟元之間單位換算、求和、求平均值。其實數據計算存在這麼一種狀況,計算的過程複雜,可是結果能夠用屢次。就能夠存儲起來。這裏沒有上面倆種方式通俗,舉個簡單例子:

function storageFn () {
    let obj = {}
    return function (val) {
        if (obj[val]) {
            return obj[val]
        } else {
            // 大量計算,假設結果爲 1
            obj[val] = 1
            return obj[val]
        }
        
    }
}
let a = storageFn()
a('b')
複製代碼

從上面的例子能夠看出來若是是已經計算過得結果能夠不須要計算直接用,這就是計算存儲。(這段代碼看不懂的能夠了解一下閉包)

7.冒泡和捕獲

描述

界面元素都是一層套一層的,當你給元素添加事件的時候,好比單擊事件。那麼究竟是單擊的哪一個元素呢?針對這個問題就有了冒泡和捕獲倆種選擇:

  • 冒泡,從單擊的元素往外擴散,這裏也能夠設置 event.stopPropagation()阻止事件冒泡
  • 捕獲,從根元素一直尋到目標元素

利用這個如何進行優化? -> 事件代理

給元素添加事件是很耗費資源的事情,普通狀況下也不會大量添加事件。可是當使用到列表的時候可能就會跟不少重複的元素循環添加事件了。其實你能夠利用冒泡的特性只給父元素添加事件。這樣無論你點了哪一個子元素最終父元素都會接收到,最後用 event.target 來確認目標元素就能夠了。

8.SPA 開發首屏優化

將一些依賴放到 CDN 上

SPA 打包的文件很大就會形成首屏加載過慢,若是把經常使用的一些第三方包單獨拿出來放到 CDN 上就會大大提升首屏速度。例如 UI 框架, echarts 庫。這裏面單獨拿出來放到 index.html 裏面並不複雜,複雜的是你有可能項目檢查的時候缺乏某個變量報錯

非首屏內容懶加載

這個你看着懶加載好像十分複雜同樣,其實就是一個語法球。掌握這個語法球就能夠輕鬆實現懶加載了。

終極方案

首頁不放到 SPA 應用裏面,單獨寫一個 html 頁面。這個我剛開始作的時候感受比較麻煩的是由於 VUE 全家桶給提供了開箱即用的腳手架,因此我居然不知道如何單獨使用 CSS 預加載,現學習這個花了一點時間。

總結

自古評論出人才,我的的知識畢竟是有限的,但願你可以評論留言補充。若是以爲評論交流不過癮能夠掃描下面的公衆號二維碼加羣交流討論

相關文章
相關標籤/搜索