前段時間花時間看了大半的《High Performance JavaScript》這本書啊,然後就開始忙專案了,慶幸最忙的一週已經熬過去了。由於空不出時間,這個月寫的學習筆記也不多,忙完最苦X的一週,這兩天晚上也算是挑燈夜讀了…終於是在殘血之際將這本書shut down了…
既然讀完了,總歸是要學到些什麼的。說說對這本書的看法先吧,整體的來說,內容還是不錯的,就是感覺有點老了(作為前端小白,也可能是自身水平有限,未能體會到其中真意)。看這本書的過程中也是寫了挺多程式碼用以測試的,並且對本書提倡的寫法和原先大眾的寫法的執行分別進行了斷點跟蹤,對於能實際測出的問題進行理解,當然,下斷點跟著執行也看不出的那也沒辦法咯。對於書中的知識點,這裡只是簡單的整理出個人所推崇的一部分,當然~ 不喜勿噴。
針對js檔案的載入位置
在HTML檔案中,標籤是可以加在區域和區域的。這裡鑑於JavaScript執行和UI渲染的單執行緒原因,如果js檔案載入會阻塞後面對於頁面的解析過程,頁面會等到js檔案完全載入並執行後才繼續執行該做的操作。那麼問題就來了,這樣可能會出現頁面空白or卡頓現象。作為一名前端開發,重要的不僅僅止於實現了需求,應該還有優質的使用者體驗。那麼我們就需要消除使用者枯燥的等待,針對這個問題,這裡有本獸想到的兩種解決方案:
1. 如果js檔案沒有特殊要求指明需要在頁面渲染之前載入及編譯完成的,那麼選擇將js檔案放到
標籤前(既所有的頁面所呈現內容的後面),css檔案還是放到
區域(誰也不願意看一個佈局雜亂無章的頁面)。這樣做就能先讓使用者看到有佈局的頁面而不是空白頁了,那麼也會有人指出:那資料得通過js請求載入進來啊,怎麼辦呢?可以對資料的載入做排序,急需呈現的介面放前面執行,不是那麼需要的可以延後執行,同時做個簡單的載入動畫or提示。
2. 如果這些js檔案有指明需要先執行了,才能更好的展示頁面內容,那麼就在第一個js或者頁面上先放個載入小動畫,可以一些有趣的或者萌萌的動畫場景。這樣也是能較好的避免使用者等待的無聊,說不定人家還對這個載入動畫更感興趣呢,這樣可提升專案的使用者體驗感。
最終推薦:將標籤儘可能的放到標籤前面載入,以提升使用者體驗。
針對js檔案的合併
在很多團隊開發中,我們可能會將不同功能的程式碼塊分別放置在不同的js檔案中,以便於開發過程中眾人合作寫程式碼會更加方便,畢竟只需要找對應資料夾或檔案而不是在一個很長的檔案中找一個方法。這確實是會提高團隊開發效率及新人加入後的更容易進行二次開發及維護。那麼將這個問題放到頁面效能裡呢?這正是問題所在,在這本書中指出:Each HTTP request brings with it additional performance overhead,so downloading one single 100 KB file will be faster than downloading four 25 KB files.
下載1個100KB的檔案比下載4個25KB的檔案要快,而開發過程中區分開各個檔案又有很大的好處,那麼合併這個問題也就放在開發完後再處理咯,相信這個操作大家都不會陌生吧,現在的前端工具這麼豐富,各位習慣用什麼壓縮就用什麼壓縮吧~
這裡簡單提出下,在載入檔案方面還可以用到defer和async屬性,用於延遲載入和非同步載入,在現代瀏覽器中,大多數是已經支援defer屬性了,還沒習慣用這個額,也不知道具體會不會存在什麼問題。有興趣的朋友可自行google該知識點,這裡件簡單提下吧。
現在的框架也大多配合懶載入和按需載入了。
更快速的資料訪問
對於瀏覽器來說,一個識別符號所處的位置越深,去讀寫他的速度也就越慢(對於這點,原型鏈亦是如此)。這個應該不難理解,簡單比喻就是:雜貨店離你家越遠,你去打醬油所花的時間就越長… 熊孩子,打個醬油那麼久,菜早燒焦了 -.-~
如果我們需要在當前函式內多次用到一個變數值,那麼我們可以用一個區域性變數先將其儲存起來,案例如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
//修改前 function showLi(){ var i = 0; for(;i<document.getElementsByTagName("li").length;i++){ //一次訪問document console.log(i,document.getElementsByTagName("li")[i]); //三次訪問document }; }; //修改後 function showLi(){ var li_s = document.getElementsByTagName("li"); //一次訪問document var i = 0; for(;i<li_s.length;i++){ console.log(i,li_s[i]); //三次訪問區域性變數li_s }; }; |
DOM操作的優化
眾所周知的,DOM操作遠比javascript的執行耗效能,雖然我們避免不了對DOM進行操作,但我們可以儘量去減少該操作對效能的消耗。
讓我們通過程式碼解釋這個問題:
1 2 3 4 5 6 |
function innerLi_s(){ var i = 0; for(;i<20;i++){ document.getElementById("Num").innerHTML="A"; //進行了20次迴圈,每次又有2次DOM元素訪問:一次讀取innerHTML的值,一次寫入值 }; }; |
針對以上方法進行一次改寫:
1 2 3 4 5 6 7 8 |
function innerLi_s(){ var content =""; var i = 0; for(;i<20;i++){ content += "A"; //這裡只對js的變數迴圈了20次 }; document.getElementById("Num").innerHTML += content; //這裡值進行了一次DOM操作,又分2次DOM訪問:一次讀取innerHTML的值,一次寫入值 }; |
減少Dom的重繪重排版
元素佈局的改變或內容的增刪改或者瀏覽器視窗尺寸改變都將會導致重排,而字型顏色或者背景色的修改則將導致重繪。
對於類似以下程式碼的操作,據說現代瀏覽器大多進行了優化(將其優化成1次重排版):
1 2 3 4 5 6 7 8 |
//修改前 var el = document.getElementById("div"); el.style.borderLeft = "1px"; //1次重排版 el.style.borderRight = "2px"; //又1次重排版 el.style.padding = "5px"; //還有1次重排版 //修改後 var el = document.getElementById("div"); el.style.cssText = "border-left:1px;border-right:2px;padding:5px"; //1次重排版 |
針對多重操作,以下三種方法也可以減少重排版和重繪的次數:
1.Dom先隱藏,操作後再顯示 2次重排 (臨時的display:none)
2.document.createDocumentFragment() 建立文件片段處理,操作後追加到頁面 1次重排
3.var newDOM = oldDOM.cloneNode(true)建立Dom副本,修改副本後oldDOM.parentNode.replaceChild(newDOM,oldDOM)覆蓋原DOM 2次重排
迴圈的優化
這應該是較多人都知道的寫法了,簡單帶過即可(後面還是用程式碼+註釋形式說明)~
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
//修改前 var i = 0; for(;i<arr.lengthli++){ //每次迴圈都需要獲取陣列arr的length console.log(arr[i]); } //修改後 var i = 0; var len = arr.length; //獲取一次陣列arr的length for(;i<len;i++){ console.log(arr[i]); } //or var i = arr.length;; for(;i;i--){ console.log(arr[i]); } |
合理利用二進位制
如:對2取模,則偶數最低位是0,奇數最低位是0,與1進行位與操作的結果是0,奇數的最低位是1,與1進行位與操作的結果是1。
程式碼如下:
1 2 |
.odd{color:red} .even{color:yellow} |
1 2 3 4 5 6 7 8 |
<ul> <li>1</li> <li>2</li> <li>3</li> <li>4</li> <li>5</li> <li>6</li> </ul> |
1 2 3 4 5 6 7 8 9 10 |
var i = 0; var lis = document.getElementsByTagName("li"); var len = lis.length; for(;i<len;i++){ if(i&1){ lis[i].className = "even"; } else{ lis[i].className = "odd"; } }; |
雖說現代瀏覽器都已經做的很好了,但是本獸覺得這是自己對程式碼質量的一個追求。並且可能一個點或者兩個點不注意是不會產生多大效能影響,但是從多個點進行優化後,可能產生的就會是質的飛躍了~