高性能的網頁開發概要

不知道有多少人和我同樣，在之前的開發過程當中不多在意本身編寫的網頁的性能。或者說一直以來我是缺少開發高性能網頁的意識的，可是想作一個好的前端開發者，是須要在當本身編寫的程序慢慢複雜之後還能繼續保持網頁的高性能的。這須要咱們對JavaScript語句，對其運行的宿主環境(瀏覽器等)，對它的操做對象(DOM等)有更深刻的理解。

什麼樣的網頁是高性能的網頁？
我想一個網頁是否高性能主要體如今兩個方面，一是網頁中代碼真實的運行速度，二是用戶在使用時感覺到的速度，咱們一項項的來討論。

提升代碼執行的效率

想要提升代碼的執行效率，咱們首先得知道咱們使用JS作不一樣的事情時，其執行效率各是如何。通常說來，web前端開發中咱們常作的操做主要是數據獲取和存儲，操做DOM，除此以外，咱們知道JS中達到同一目的可能會有多種途徑，但其實各類途徑執行效率並不相同，咱們應該選擇最合適的途徑。

數據存儲和訪問

先說數據存儲，計算機中，數據確定是存在於內存之中，可是訪問到具體內存所在的位置卻有不一樣的方法，從這個角度看JS中有四種基本的數據存取位置：

- 字面量：只表明自身，不存儲在特定位置
* 本地變量：使用關鍵字var 存儲的數據存儲單元
* 數組元素：存儲在JavaScript的數組對象內部，以數字爲索引
* 對象成員：存儲在JavaScript對象內部，以字符串爲索引

不一樣存儲方式的訪問速度
其實很容易就能夠理解，訪問一個數據所經歷的層級越少，其訪問速度越快，這樣看來訪問字面量和局部變量速度最快，而訪問數組元素和對象成員相對較慢；

從數據存儲和訪問角度來看，提高效率的核心在於存儲和訪問要直接，不要拐彎抹角。咱們以原型鏈和做用域爲例來講明如何優化。

原型鏈
對象的原型決定了實例的類型，原型鏈能夠很長，實例所調用的方法在原型鏈層級中越深則效率越低。所以也許須要咱們保證原型鏈不要太長，對於常常須要使用到的方法或屬性，儘可能保證它在原型鏈的淺層。

做用域(鏈)
做用域也是JavaScript中一個重要的概念，通常說來變量在做用域中的位置越深，訪問所需的時間就越長。
局部變量存在於做用域鏈的起始位置，其訪問速度比訪問跨做用域變量快，而全局變量處於做用域鏈的最末端，其訪問速度也是最慢的。
通常說來JavaScript的詞法做用域在代碼編譯階段就已經肯定，這種肯定性帶來的好處是，代碼在執行過程當中，可以預測如何對變量進行查找，從而提升代碼運行階段的執行效率。咱們也知道JavaScript中有一些語句是會臨時改變做用域的，好比說with，eval,try...catch...中的catch子句，使用它們會破壞已有的肯定性，從而下降代碼執行效率，所以這些語句應該當心使用。

從數據的存儲和訪問角度，能夠從如下角度進行優化：

- 咱們應該儘可能少用嵌套的對象成員，多層嵌套時會明顯影響性能，若是實在要使用（尤爲是屢次使用）；
- 咱們能夠經過把經常使用的對象成員，數組元素，跨域變量保存在局部變量中，再使用來改善JavaScript性能。

DOM編程

經過DOM API，利用JavaScript咱們有了操做網頁上的元素的能力，這也使得咱們的網頁活靈活現。但是遺憾的是DOM編程是性能消耗大戶，它天生就慢，究其緣由，是由於在瀏覽器中DOM渲染和JavaScript引擎是獨立實現的，不一樣的瀏覽器實現機制不一樣，具體可見下表。

類別	IE	Safari	Chrome	Firefox
JS引擎	jscript.dll	JavaScriptCore	V8	SpiderMonkey(TraceMonkey)
DOM和渲染	mshtml.dll (Trident)	Webkit中的WebCore	Webkit中的WebCore	Gecko

DOM渲染和JavaScript引擎的獨立實現意味着這兩個功能好像位於一條大河的兩岸，兩者的每次交互都要渡過這條河，這很明顯會產生很多額外的性能消耗，這也是咱們常說操做DOM是很是消耗性能的緣由。
從這個角度咱們想到，想要減小DOM操做帶來的性能的消耗，核心咱們要作的是減小訪問和修改等DOM操做。
咱們能夠從如下幾方面着手DOM編程的優化：

1. 把運算儘可能留在ECMAScript這一端處理，在實際開發過程當中咱們應該對DOM不作非必要的操做，在得到必要的值之後，能夠把這些值存儲在局部變量之中，純使用JS對該值進行相關運算，直接用最後的結果來修改DOM元素，可能這麼說來並非很直觀，可是回頭看看咱們的項目，咱們有沒有過在循環或者會屢次使用的函數中，每次都從新獲取某個不變的DOM相關的值；

2. 當心處理HTML集合：

HTML集合是包含了 DOM節點引用的類數組對象，相似於如下方法，獲取的都是這種HTML集合：
document.getElementsByName()；
document.getElementByClassName();
document.getElementByTagName();
這種類數組對象具有普通數組的一些特色，好比擁有length屬性，能夠經過數字索引的方式訪問到對應的對象，可是卻並無數組的push和slice等方法，重點在於在使用過程當中這個集合實時連繫着底層的文檔，每次訪問這種HTML集合，都會重複執行查詢的過程，形成較大的性能消耗；下面是一個典型的屢次訪問的例子：

var alldivs = document.getElementsByTagName('div');
    for(var i = 0;i<alldivs.length;i++){
        document.body.appendChild(document.createElement('div'));
    }

上述代碼是一個死循環，在每次循環的時候alldivs都會從新遍歷DOM，得到更新，產生了沒必要要的性能消耗；
合理的使用方式應該是，把集合的長度緩存到一個變量中，在迭代中使用這個局部變量。若是須要常常操做集合元素，咱們能夠把這個集合拷貝到一個數組中，操做數組比操做HTML集合性能高；使用下述方法能夠把一個HTML集合拷貝爲普通的數組：

// 拷貝函數
function toArray(coll){
    for(var i=0,a=[],len=coll.length;i<len;i++){
        a[i]=coll[i]
    }
    return a;
}

// 使用方法
var coll = document.getElementByTagName('div');
var ar = toArray(coll);

1. JS代碼的運行須要宿主環境，就web前端來講，這個環境就是咱們的瀏覽器，通常說來瀏覽器會對一些常見操做進行必定的優化，使用優化後的API，性能更高，咱們應該儘可能使用那這些優化過的API，對現代瀏覽器中的DOM操做來講，有如下一些優化後的API：

優化後	原始
children	childnodes
childElementCount	children.length
firstElementChild	firstChild
lastElementChild	lastChild
nextElementSibling	nextSibling
previousElementSibling	previousSibling
document.querySelector()	document.getElemnetByClassName…

1. 減小重繪與重排
   重排和重繪也是你們常常聽到的概念：

重排：DOM變化影響了元素的幾何屬性（好比改變邊框寬度），引發其它元素的位置也所以受到影響，瀏覽器會使得渲染樹中受到影響的部分失效，並從新構建渲染樹;
重繪：重排完成後，瀏覽器會從新繪製受影響的部分到屏幕中（並非全部的DOM變化都會影響幾何屬性，例如改變一個元素的背景色並不會影響它的寬和高）；

重排和重繪都是代價很高的操做，會直接致使Web應用程序的UI反應遲鈍，應該儘可能減小這類過程的發生。通常說來下面的操做會致使重排：

- 添加刪除可見的DOM元素；
* 元素位置改變；
* 元素尺寸改變（`padding,margin,border,width,height...`）
* 內容改變;（文本內容，或圖片被另一個不一樣尺寸的圖片替代）;
* 頁面渲染器初始化;
* 瀏覽器窗口尺寸改變;

每次重排都會產生計算消耗，大多數瀏覽器會經過隊列化修改，批量執行來優化重排過程，減小性能消耗。可是也有部分操做會強制刷新隊列，要求重排任務當即執行。以下：

- `offsrtTop`,`offsetLeft`,`offsetWidth`,`offsetHeight`；
* `scrollTop`,`scrollLeft`,`scrollWidth`,`scrollHeight`;
* `clientTop`,`clientLeft`,`clientWidth`,`clientHeight`;
* `getComputedStyle()`

上述操做都要求返回最新的佈局信息，瀏覽器不得不執行渲染隊列中待處理的任務，觸發重排返回正確的值。經過緩存佈局信息能夠減小重排次數，這一點是我一直忽略的一點，曾經屢次在循環或屢次調用的函數中直接使用上述操做獲取距離；

總的來講最小化重繪和重排的核心是合併屢次對DOM和樣式的修改，而後一次處理掉，主要有如下幾種方法：

- 使用cssText屬性(適用於動態改變)

var el = document.getElementById(‘mydiv’);
// 下面這種寫法能夠覆蓋已存在的樣式信息
el.style.cssText = ‘border-left:1px;border-right:2px;padding:5px’;
// 下面這種寫法能夠把新屬性附加在cssTest字符串後面
el.style.cssText += ‘;border-left:1px;’;

- 對於不依賴於運行邏輯和計算的狀況，直接改變CSS的`class`名稱是一種比較好的選擇
- 批量修改DOM:操做以下
    - 使元素脫離文檔流；
        * 隱藏元素，應用修改，從新顯示；
        * 使用文檔片斷，在當前DOM外構建一個子樹，再把它拷貝到文檔；
        * 將原始元素拷貝到一個脫離文檔的節點中，修改副本，完成後替換原始元素；
    * 對其應用多重改變；
    * 把元素帶回文檔中；
在這個過程當中只有第一步和第三步會觸發重排，可參加下述代碼。

var fragment = document.createDocumentFragment();//一個輕量級的document對象
// 組裝fragment...(省略)
// 加入文檔中
document.getElementById(‘mylist’).appendChild(fragment);

var old = document.getElementById(‘mylist’);
var clone = old.cloneNode(true);
// 對clone進行處理
old.parentNode.replaceChild(clone,old);

- 對動畫元素可進行以下優化
    - 對動畫元素使用絕對定位，將其脫離文檔流；
    * 讓元素動起來，懂的時候會臨時覆蓋部分頁面（不會產生重排並繪製頁面的大部份內容）;
    * 當動畫結束時恢復定位，從而只會下移一次文檔的其它元素；

此外若是頁面中對多個元素綁定事件處理器，也是會影響性能的，事件綁定會佔用處理時間，瀏覽器也須要跟蹤每一個事件處理器，會佔用更多的內存。針對這種狀況咱們能夠採用使用事件委託機制：也就是說把事件綁定在頂層父元素，經過e.target獲取點擊的元素，判斷是不是但願點擊的對象，執行對應的操做，幸運的是如今的不少框架已經幫咱們作了這一點（React中的事件系統就用到了事件委託機制）。

選擇合適的JavaScript語句

異曲同工付出的代價卻不同，和任何編程語言同樣，代碼的寫法和算法會影響運行時間。而咱們寫的最多的語句是迭代和判斷。

選擇合適的迭代語句

JavaScript提供了多種迭代方法：

1. 四種循環類型：

   • for;

   • while;

   • do…while循環；

   • for…in…循環；

就四種循環類型而言，前三種循環性能至關，第四種for...in...用以枚舉任意對象的屬性名，所枚舉的屬性包括對象實例屬性及從原型鏈中繼承來的屬性，因爲涉及到了原型鏈，其執行效率明顯慢於前三種循環。就前三種而言影響性能的主要因素不在於選擇哪一種循環類型，而在於每次迭代處理的事務和迭代的次數。

減小每次迭代的工做量
很明顯，達到一樣的目的，每次迭代處理的事務越少，效率越高。舉例來講

// 普通循環體
for(var i=0;i<items.length;i++){
    process(item[i])
}

// 優化後的循環體
for(var i= items.length;i--;){
    process(item[i])
}

普通循環體每次循環都會有如下操做：

1. 在控制條件中查找一次屬性（`items.length`）;
2. 在控制條件中執行一次數值比較（`i<items.length`）；
3. 一次比較操做查看控制條件的計算結果是否爲`true`(`i<item.length==true`);
4. 一次自增操做(`i++`)；
5. 一次數組查找(`item[i]`)；
6. 一次函數調用(`process[items[i]`);

優化後的循環體每次迭代會有如下操做：

1. 一次控制條件中的比較(`i==true`)；
2. 一次減法操做(`i—`);
3. 一次數組查找(`item[i]`);
4. 一次函數調用(`process(item[i])`);

明顯優化後的迭代操做步驟更少，若是迭代次數不少，屢次這樣小的優化就能節省不錯的性能，若是process()函數自己也充滿了各類小優化，性能的提高仍是很可觀的；

減小迭代次數
每次迭代實際上是須要付出額外的性能消耗的，可使用Duff’s Device方法減小迭代次數，方法以下；

// credit:Jeff Greenberg
var i = items.length%8;
whild(i){
    process(items[i--]);
}

i = Math.floor(items.length/8);

// 若是循環次數超過1000，與常規循環結構相比，其效率會大幅度提升
while(i){
    process(items[i--]);
    process(items[i--]);
    process(items[i--]);
    process(items[i--]);
    process(items[i--]);
    process(items[i--]);
    process(items[i--]);
    process(items[i--]);
}

‘Duff’s Device’循環體展開技術，使得一次迭代實際上執行了屢次迭代的操做。若是迭代次數大於1000次，與常規循環結構相比，就會有可見的性能提高。

1. 基於函數的迭代

   • forEach();

   • map();

   • every();

   • 等…

基於函數的迭代是一個很是便利的迭代方法，但它比基於循環的迭代要慢一些。每一個數組項都須要調用外部方法所帶來的開銷是速度慢的主要緣由。經測試基於函數的迭代比基於循環的迭代慢八倍，選擇便利仍是性能這就是咱們本身的選擇了；

選擇合適的條件語句

條件表達式決定了JavaScript運行流的走向，常見的條件語句有if…else...，switch...case...兩種：
switch語句的實現採用了branch table(分支表)索引進行優化，這使得switch...case是比if-else快的，可是隻有條件數量很大時才快的明顯。這兩個語句的主要性能區別是，當條件增長時，if...else性能負擔增長的程度比switch大。具體選用那個，仍是應該依據條件數量來判斷。

若是選用if...else,也有優化方法，一是把最可能出現的條件放在最前面，二是能夠經過嵌套的if...else語句減小查詢時間；

在JavaScript中還能夠經過查找表的方式來獲取知足某條件的結果。當有大量離散值須要測試時，if...else和switch比使用查找錶慢不少。查找表能夠經過數組模擬使用方法以下：

var results = [result0,result1,result2,result3,result4,result5,result6,result7,result8,result9];

return results[value];

從語言自己的角度來看，作到上述各點，咱們的代碼性能就會有比較大的提高了，可是代碼性能的提高，只是代碼執行自己變快了，並不必定是用戶體驗到的時間變短了，一個好的web網頁，還應該讓用戶感受到咱們的網頁很快。

更好的交互體驗

人類對時間的感受實際上是不許確的，考慮兩種場景，

一種場景是，一段代碼執行10s，10s後全部內容一會兒所有顯示出來；
另一種場景是，總共須要執行12s，可是每秒都在頁面上添加一些內容，主體內容先添加，次要內容後添加；

上述兩種場景給人的感受徹底不同。大部分人會以爲後面那個12s時間更短。

用戶感受到的時間的長短取決於用戶與網頁交互時收到的反饋，通常說來100ms是個時間節點，若是界面沒在100ms內對用戶的行爲做出反饋，用戶就會有卡頓的感受，開發過手機版的網頁的童鞋都知道，當你觸發手機端默認的onClick事件時，有些瀏覽器出於要確認你是否想要雙擊，會在單擊事件觸發300ms後，才執行相應的操做，用戶在這時候會有明顯卡頓的感受的。爲了達到更好的交互體驗，咱們能夠從腳本加載時機，不阻塞瀏覽器的UI線程，高效使用Ajax，合理構建和部署JavaScript應用等方面進行優化：

加載和執行

咱們都知道多數瀏覽器使用單一進程來處理UI刷新和JavaScript腳本執行，當執行較大的JavaScript腳本時會阻塞UI的刷新。這是一種很是很差的體驗。全部在頁面初始化時期，咱們都會把JavaScript放在</body>標籤以前。咱們也能夠採用動態加載的方式，不管在什麼時候啓動，文件的下載和執行過程都不會阻塞頁面其餘進程，一種常見的動態加載方式以下，固然咱們也可使用AJAX進行動態加載。

var script = document.createElement("script");
    script.type = "text/javascript";
    script.src="file1.js";
    document.getElementsByTagName("head")[0].appendChild(script);
    // 不管在什麼時候啓動下載，文件的下載和執行過程不會阻塞頁面其餘進程
    // 經過檢測load事件能夠得到腳本加載完成時的狀態

構建快速響應的用戶界面

咱們已經知道，當JavaScript代碼執行時，用戶界面實際上是屬於鎖定狀態的，管理好JavaScript的運行時間對Web應用的性能相當重要。

用來執行JavaScript和更新用戶界面的進程一般稱爲「瀏覽器UI線程」。其工做基於一個簡單的任務隊列系統，具體原理是全部的前端任務會被保存在任務隊列中直到進程空閒，一旦空閒，隊列中的下一個任務就會被提取出來並運行。這些任務多是一段待執行的JavaScript代碼，UI更新（重排重繪等）。
通常瀏覽器有本身的JavaScript長時間運行限制，不一樣瀏覽器限制的時間不一樣，有的是5~10s，有的是運行超過500萬行語句時提醒；達到限制時間後對頁面的處理方式也不一樣，有的直接致使瀏覽器崩潰，有的會發出明顯可見的警告信息。

前面咱們已經討論過若是等待時間不超過100ms，通常人就會以爲操做是連貫的。這給咱們提供了一個思路，咱們的一段JavaScript代碼的執行時間若是不超過100ms，操做起來感受就是連貫的。

經過分隔JavaScript代碼的執行，咱們可讓JavaScript的執行時間不超過100ms，主要途徑主要有兩種：
使用定時器讓出時間片斷，使用web worker。

經過定時器是分割UI線程的時間片斷

JavaScript中有兩種不一樣的定時器setTimeout()和setInterval(),它們都接受兩個參數，第一個參數是一個函數，第二個參數是一段時間。當定時器被調用時，它們會告訴JavaScript引擎在等待咱們所定的時間後，添加一個JavaScript任務到UI線程中。
定時器的意義在於，每當咱們建立一個定時器，UI線程就會暫停，並從一個任務切換到下一個任務，定時器也會重置全部相關的瀏覽器限制，包括長時間運行腳本限制，調用棧的限制。

咱們也應該明確，定時器的延遲時間並不是老是精確的，每次相差大約幾毫秒，因此定時器不太適合拿來計時（好比說在windows系統中定時器分辨率爲15ms），通常建議的延遲的最小值爲25ms，以確保至少有15ms的延遲。

咱們經過下面的代碼看看如何利用定時器無阻塞的處理大數組

var todo = items.concat();//items是原始的大數組

setTimeout(function(){
    // 取出數組的下個元素並進行處理
    process(todo.shift());

    // 若是還有須要處理的元素，建立另外一個定時器，再25ms執行一次
    if(todo.length>0){
        // arguments.callee指向當前正在運行的匿名函數
        setTimeout(arguments.callee,25);
    }else{
        // 若是全部的數組都被處理了，執行callback()函數
        callback(items);
    }
},25);

利用定時器能夠按照下述方法分割運行時間過長的函數

//原函數
function saveDocument(id){
    //保存文檔
    openDocument(id);
    writeText(id);
    closeDocument(id);

    //將信息更新到界面
    updateUI(id);
}

// 使用定時器分割任務的方法
function saveDocument(id){
    var tasks=[openDocument,writeText,closeDocument,updateUI];

    setTimeout(function(){
        var task = tasks.shift();
        task(id);

        if(tasks.length>0){
            setTimeout(arguments.callee,25);
        }
    },25);
}

定時器把咱們的任務分解成了一個個的不致於阻塞的片斷，雖然總的執行時間多是變長了，可是會讓咱們的交互體驗發生翻天覆地的變化，使用得當，咱們能夠避免大部分徹底卡住的狀況了。不過定時器的使用也有一個限制，咱們應該保證同一時間只有一個定時器的存在，防止由於定時器使用過分致使的性能問題。

WebWorker給Web應用帶來的巨大性能潛力提高

WebWorker是HTML5新提供的一組API，它引入了一個接口，能使代碼運行且不佔用瀏覽器UI線程的時間，這裏只作簡單介紹，具體使用請查看相關文檔：
一個WebWorker實際上是JavaScript特性的一個子集，其運行環境由如下部分組成：

- 一個`navigator`對象，包含四個屬性：`appName`,`appVeision`,`userAgent,platform`;
* 一個`location`對象（與`window.location`相同，不過全部屬性都是隻讀的）；
* 一個`self`對象，指向全局`worker`對象；
* 一個`importScript()`方法，用來加載`Worker`所用到的外部JavaScript文件；
* 全部的ECMAScript對象，諸如：`Object，Array，Date`等；
* `XMLHttpRequest`構造器；
* `setTimeout()`和`setInterval()`方法；
* 一個`close()`方法，它能夠當即中止Worker運行；

主網頁與Worker相互通訊的方法
Worker與網頁代碼經過事件接口進行通訊。主網頁和Worker都會經過postMessage()傳遞數據給對方；使用onmessage事件處理器來接收來自對方的信息；

// 主頁面
var worker = new Worker('code.js');
worker.onmessage = function(event){
    alert(event.data);
};
worker.postMessage("Nicholas");

//code.js內部的代碼
self.onmessage = function(event){
    self.postMessage("Hello,"+ event.data+"!");
}

相互傳遞的原始值能夠是字符串，數字，布爾值，null，undefined，也能夠Object和Array的實例。

加載外部文件的方法
在一個web worker中可使用importScript()方法加載外部JavaScript文件，該方法接收一個或多個url做爲參數，調用過程是阻塞式的，全部文件加載並執行完成之後，腳本纔會繼續運行。但並不會影響UI響應。
加載容許異步發送和接收數據。能夠在請求中添加任何頭信息和參數，並讀取服務器返回的全部頭信息，以及響應文本。
importScripts(‘file1.js’,’file2.js’);

WebWorker的實際應用

- 適合處理純數據，或者與UI無關的長時間運行腳本；
* 編碼，解碼大字符串；
* 複雜數學運算；
* 大數組排序；

總的說來，Web應用越複雜，積極主動管理UI線程越重要，複雜的前端應用更應該合理使用定時器分割任務或使用WebWorker進行額外計算從而不影響用戶體驗。

使用Ajax

Ajax是高性能JavaScript的基礎，它經過異步的方式在客戶端和服務器端之間傳輸數據，避免頁面資源一窩蜂的下載，從而起到防止阻塞，提升用戶體驗的效果，在使用時咱們應該選擇最合適的傳輸方式和最有效的數據格式。

傳輸方式

數據請求方式
異步從服務器端獲取數據有多種方法，經常使用的請求有如下三種：

1. XHR
   這是目前最經常使用的技術，能夠在請求中添加任何頭信息和參數，讀取服務器返回的全部頭信息以及響應文本。

這種方法的缺點在於不能使用XHR從外域請求數據，從服務器傳回的數據會被看成字符串或者XML對象，處理大量數據時會很慢。經GET請求的數據會被緩存起來，若是須要屢次請求同一數據的話，使用GET請求有助於提高性能，當請求的URL加上參數的長度接近或超過2048個字符時，才應該用POST獲取數據。

XHR的使用可見如下示例：

var url = ‘/data.php’;
var params = [
    ‘id=123123’,
    ‘limit = 20’,
];

var req = new XMLHttpRequest();

req.onreadystatechange = function(){
    if(req.readyState===4){
        var responseHeader = req.getAllResponseHeaders(); // 獲取響應頭信息
        var data = req.responseText; // 獲取數據
        // 數據處理相關程序
    }
}

req.open(‘GET’,url+’?’+params.join(‘&’),true);
req.setRequestHeader(‘X-Requested-With’,’XMLHttpRequest’);// 設置請求頭信息
req.send(null); //發送一個請求

1. 動態腳本注入
   這種技術克服了XHR的最大限制，它能跨域請求數據。可是這種方法也有本身的限制，那就是提供的控制是有限的，

   • 不能設置請求的頭信息；

   • 只能使用GET，不能POST；

   • 不能設置請求的超時處理和重試；

   • 不能訪問請求的頭信息。
     這種請求的請求結果必須是可執行的JavaScript代碼。因此不管傳輸來的什麼數據，都必須封裝在一個回調函數中。儘管限制諸多，可是這項技術的速度很是快。動態腳本注入的使用方法以下：

var scriptElement = document.createElement('script');
scriptElement.src = 'http://.../lib.js';
document.getElementsByTagName('head')[0].appendChild(scriptElement);

function jsonCallback(jsonString){
    var data = eval('('+jsonString+')')
}

jsonCallback({"state":1,"colors":["#fff","#000","#ff0000"]});

1. multipart XHR
   這種方法容許客戶端只用一個HTTP請求就從服務器端向客戶端傳送多個資源，他經過在服務器端將資源（CSS文件，HTML片斷，JavaScript代碼或base64編碼的圖片）打包爲一個由雙方約定的字符串分割的長字符串併發送給客戶端；而後用JavaScript代碼處理這個長字符串，並根據它的mime-type類型和傳入的其它「頭信息」解析出每一個資源。

基於這種方法，咱們能夠經過監聽readyState爲3的狀態來實如今每一個資源收到時就當即處理，而不是等待整個響應消息完成。

此技術最大的缺點是以這種方式得到的資源不能被瀏覽器緩存。不過在某些狀況下MXHR依然能顯著提高頁面的總體性能：

- 頁面中包含了大量其它地方用不到的資源好比圖片；
* 網站在每一個頁面中使用一個獨立打包的JavaScript或CSS文件用以減小HTTP請求；

HTTP請求是Ajax中最大的瓶頸之一，所以減小HTTP請求的數量也許明顯的提高整個頁面的性能。

數據發送方式
主要有兩種數據發送方法

-     `XHR`
- 信標`beacons`

XHR咱們較熟悉，使用示例以下：

var url = ‘/data/php’;
var parms = [
    ‘id=934345’,
    ‘limit=20’
]

var req = new XMLHttpRequest();

req.onerror = function(){
    //出錯
};

req.onreadystatechange = function(){
    if(req.readyState==4){
        // 成功
    }
}

req.open(‘POST’,url,true);
req.setRequestHeader(‘Content-Type’,’application/x-www-form-urlencoded’);
req.setRequestHeader(‘Content-Length’,params.length);
req.send(params.join(‘&’));

須要注意的是，使用XHR發送數據時，GET方式更快，對少許數據而言，一個GRT請求往服務器只發送一個數據包。而一個POST請求至少發送兩個數據包，一個裝載頭信息，另一個裝載POST正文，POST適合發送大量數據到服務器的狀況。

Beacons技術相似於動態腳本注入。
Beacons技術具體作法爲使用JavaScript建立一個新的Image對象，並把src屬性設置爲服務器上腳本的URL，該URL包含了咱們要經過GET傳回的鍵值對數據。實際上並無建立img元素或把它傳入DOM。

var url = ‘/status_tracker.php’;
var params = [
    ‘step=2’,
    ‘time=1248027314’
];

(new Image()).src = url + ‘?’ + params.join(‘&’);

beacon.onload = function(){
    if(this.width==1){
        // 成功
    }else if(this.width==2){
        // 失敗，請重試並建立另外一個信標
    }
}；

beacon.onerror = function(){
    // 出錯，稍後重試並建立另外一個信標
}

這種方法最大的優點是能夠發送的數據的長度被限制得很是小。Beacons技術是向服務器回傳數據最快且最有效的方式。惟一的缺點是能接收到的響應相似是有限的。

數據格式

說完傳輸方式，咱們再討論一下傳輸的數據格式：
考慮數據格式時，惟一須要比較的標準是速度。
沒有那種數據格式會始終比其它格式更好。優劣取決於要傳輸的數據以及它在頁面上的用途，有的數據格式可能下載速度更快，有的數據格式可能解析更快。常見的數據格式有如下四種：

1. XML
   優點：極佳的通用性（服務端和客戶端都能完美支持），格式嚴格，易於驗證；

缺點：極其冗長，每一個單獨的數據片斷都依賴大量結構，有效數據比例很是低，XML語法有些模糊，解析XML要佔用JavaScript程序員至關部分的精力。

1. JSON
   優點：體積更小，在響應信息中結構所佔的比例小，JSON有着極好的通用性，大多數服務器端編程語言都提供了編碼和解碼的類庫。對於web開發而言，它是性能表現最好的數據格式；

使用注意：

- 使用`eval()`或儘可能使用JSON.parse()方法解析字符串自己。
- 數組JSON的解析速度最快，可是可識別性最低。
- 使用XHR時，JSON數據被當作字符串返回，該字符串緊接着被eval()裝換爲原生對象；
- JSON-P（JSON with padding）：JSON-P由於回調包裝的緣由略微增大了文件尺寸，可是其被當作原生js處理，解析速度快了10倍。

1. HTML
   優點：獲取後能夠直接插入到DOM中，適用於前端CPU是瓶頸而帶寬非瓶頸的狀況；

缺點：做爲數據結構，它即緩慢又臃腫。

1. 自定義格式
   通常咱們採用字符分隔的形式。並用split()對字符串進行分割，split()對字符串操做其實也是很是快的，一般它能在數毫秒內處理包含10000+個元素的‘分隔符分隔’列表。

對數據格式的總結

- 使用JSON-P數據，經過動態腳本注入使用這種數據，這種方法把數據當作可執行JavaScript而不是字符串，解析速度極快，能跨域使用，可是設計敏感數據時不該該使用它；
* 咱們也能夠採用經過字符分隔的自定義格式，能夠經過使用XHR或動態腳本注入獲取對於數據，並用`split()`解析。這項技術解析速度比JSON-P略快，一般文件尺寸更小。

針對Ajax的數據緩存

- 在服務器端，設置HTTP頭信息以確保響應會被瀏覽器緩存；
- 設置頭信息後，瀏覽器只會在文件不存在緩存時纔會向服務器發送Ajax請求；
* 在客戶端，將獲取到的信息存儲到本地，從而避免再次請求；

總的來講，對XHR創造性的使用是一個反應遲鈍且平淡無奇的頁面與響應快速且高效的頁面的區別所在，是一個用戶痛恨的站點與用戶迷戀的站點的區別所在，合理使用Ajax意義非凡。

合理構建和部署JavaScript應用

上文所述的都是在編碼過程當中應該注意的一些事項，除此以外，在代碼上線時，咱們也能夠作一些相關的優化。

1. 合併多個JavaScript文件用以減小頁面渲染所需的HTTP請求數；
2. JavaScript壓縮：經過剝離註釋和沒必要要的空白字符等，能夠將文件大小減半，有多種工具能夠完成壓縮：好比在線的YUI Compressor，在webpack中使用UglifyJsPlugin插件等;完全的壓縮常作如下事情：
    * 將局部變量變爲更短的形式；
    * 儘量用雙括號表示法替換點表示法；
    * 儘量去掉直接量屬性名的引號；
    * 替換字符串的中的轉義字符；’aaa\bbb’被替換爲」aaa’bbb」
    * 合併常量；
3. 除了常規的JavaScript壓縮，咱們還能夠對代碼進行Gzip壓縮，Gzip是目前最流行的編碼方式，它一般能減小70%的下載量，其主要適用於文本包括JS文件，其它類型諸如圖片或PDF文件，不該該使用Gzip；
4. 基於不一樣的瀏覽器環境，咱們應該選擇發送最合適的代碼，好比說目前iPhone版的微信內置瀏覽器是支持解壓Gzip的而安卓端默認不支持，那對iPhone端就能夠發送xxx.js,gz文件而對安卓端發送xxx.js文件，這樣是能夠提升iPhone端的webApp的加載效率的；
5. 合併，預處理，壓縮等都既能夠在構建時完成，也能夠在項目運行時完成，可是推薦能在構建時完成的就儘可能在構建時完成；
6. 合理緩存JavaScript文件也能提升以後打開相同網頁的效率：
    - Web服務器經過「Expires HTTP響應頭」來告訴客戶端一個資源應當緩存多長時間；
    * 移動端瀏覽器大多有緩存限制（iPhone Safari 25k），這種狀況下應該權衡HTTP組件數量和它們的可緩存性，考慮將它們分爲更小的塊；
    * 合理利用HTML5 離線應用緩存
    - 應用更新時有緩存的網頁可能會來不及更新（這種狀況能夠經過更新版本號或開發編號來解決）；
7. 使用內容分發網絡(CDN);
 CDN是在互聯網上按地理位置分佈的計算機網絡，它負責傳遞內容給終端用戶。使用CDN的主要緣由是加強Web應用的可靠性，可拓展性，更重要的是提高性能；
8. 值得注意的是，上述不少操做是能夠經過自動化處理完成的，學習相關自動化處理工具能夠大大提升咱們的開發效率

總結

本文從多方面敘述了web前端的優化思路，謝謝你讀到這裏，但願你有所收穫，不少知識經過屢次刻意的重複就能成爲本身的潛意識，但願咱們在從此都能在本身的實際開發過程當中，都能以效率更高的方式寫JS語句，操做DOM，咱們的應用都很是流暢，UI都不會阻塞，若是你有別的關於優化的具體建議，歡迎一塊兒討論。

後記

本文其實算是我讀Nicbolas C.Zakas的《高性能JavaScript》的讀書筆記，針對某個話題系統的讀書對我來講，是很是有好處的。系統的讀前端方面,計算機方面的經典書籍也是我給本身安排的2017年最主要的任務之一，預計每個月針對某本書或某幾本書關於某一個方面，寫一篇讀書筆記，本文是2017年的第一篇。