前端性能優化

時間  2019-11-10
標籤 前端 性能 優化 欄目 系統性能 简体版
原文   原文鏈接

 

圖中已經對前端性能作了一些歸納。javascript

從三個方面就前端性能進行總結：網絡方面、DOM操做及渲染方面、數據方面。php

網絡方面

web應用，老是會有一部分的時間浪費在網絡鏈接和資源下載方面。每每創建一次網絡鏈接是須要時間成本的。並且瀏覽器同一時間所發送的網絡請求數是有限的。因此，這個層面的優化能夠從「減小請求數目」開始：css

  1. 減小http請求：在YUI35規則中也有提到，主要是優化js、css和圖片資源三個方面，由於html是沒有辦法避免的。所以，咱們能夠作一下的幾項操做：html

    • 合併js文件
    • 合併css文件
    • 雪碧圖的使用(css sprite)
    • 使用base64表示簡單的圖片

    上述四個方法，前面二者咱們可使用webpack之類的打包工具進行打包；雪碧圖的話，也有專門的製做工具；圖片的編碼是使用base64的，因此，對於一些簡單的圖片，例如空白圖等，可使用base64直接寫入html中。前端

回到以前網絡層面的問題，除了減小請求數量來加快網絡加載速度，每每整個資源的體積也是，平時咱們會關注的方面。java

  1. 減少資源體積：能夠經過如下幾個方面進行實施：android

    • gzip壓縮
    • js混淆
    • css壓縮
    • 圖片壓縮

    gzip壓縮主要是針對html文件來講的，它能夠將html中重複的部分進行一個打包，屢次複用的過程。js的混淆能夠有簡單的壓縮(將空白字符刪除)、醜化(醜化的方法，就是將一些變量縮小)、或者可使用php對js進行混淆加密。css壓縮，就是進行簡單的壓縮。圖片的壓縮，主要也是減少體積，在不影響觀感的前提下，儘可能壓縮圖片，使用png等圖片格式，減小矢量圖、高清圖等的使用。這樣子的作法不只能夠加快網頁顯示，也能減小流量的損耗。webpack

除了以上兩部分的操做以外，在網絡層面咱們還須要作好緩存工做。真正的性能優化來講，緩存是效率最高的一種，每每縮短的加載時間也是最大的。ios

  1. 緩存：能夠經過如下幾個方面來描述：程序員

    • DNS緩存
    • CDN部署與緩存
    • http緩存

    因爲瀏覽器會在DNS解析步驟中消耗必定的時間，因此，對於一些高訪問量網站來講，作好DNS的緩存工做，就會必定程度上提高網站效率。CDN緩存，CDN做爲靜態資源文件的分發網絡，自己就已經提高了，網站靜態資源的獲取速度，加快網站的加載速度，同時也給靜態資源作好緩存工做，有效的利用已緩存的靜態資源，加快獲取速度。http緩存，也是給資源設定緩存時間，防止在有效的緩存時間內對資源進行重複的下載，從而提高總體網頁的加載速度。

其實，網絡層面的優化還有不少，特別是針對於移動端頁面來講。衆所周知，移動端對於網絡的敏感度更加的高，除了目前的4G和WIFI以外，其餘的移動端網絡至關於弱網環境，在這種環境下，資源的緩存利用是至關重要的。並且，減小http的請求次數，也是相當重要的，移動端弱網環境下，對於http請求的時間也會增長。因此，咱們能夠看一下咱們在移動端網絡方面能夠作的優化：

  1. 移動端優化：使用如下幾種方式來加快移動端網絡方面的優化：

    • 使用長cache，減小重定向
    • 首屏優化，保證首屏加載數據小於14kb
    • 不濫用web字體

    「使用長cache」，可使得移動端的部分資源設定長期緩存，這樣能夠保證資源不用向服務器發送請求，來比較資源是否更新，從而避免304的狀況。304重定向，在PC端或許並不會影響網頁的加載速度，可是，在移動端網絡不穩定的前提下，多一次請求，就多了一部分加載時間。「首屏優化」，對於移動端來講是相當重要的。2s時間是用戶的最佳體驗，一旦超出這個時間，將會致使用戶的流失。因此，針對移動端的網絡狀況，不可能在這麼短期內加載完成全部的網頁資源，因此咱們必須保證首屏中的內容被優先顯示出來，並且基於TCP的慢啓動和擁塞控制，第一個14kb的數據是很是重要的，因此須要保證首部加載數據可以小於14kb。「不濫用web字體」，web字體的好處就是，能夠代替某些圖片資源，可是，在移動端過多的web字體的使用，會致使頁面資源加載的繁重，因此，慎用web字體

渲染和DOM操做方面

首先，簡單的聊一下優化渲染的重要性。在網頁初步加載時，獲取到HTML文件以後，最初的工做是構建DOM和構建CSSOM兩個樹，以後將他們合併造成渲染樹，最後對其進行打印。咱們能夠經過圖片來看一下，簡單的過程：

 
DOM渲染

這裏整個過程拉出來寫，具體能夠再寫一篇文章，恕我偷下懶，推薦一篇比較好的文章給你們吧。瀏覽器渲染過程與性能優化

繼續咱們的話題，咱們能夠如何去縮短這個過程呢？能夠從如下幾個操做進行優化。

  1. 優化網頁渲染：

    • css的文件放在頭部，js文件放在尾部或者異步
    • 儘可能避免內聯樣式

    css文件放在「頭部加載」，能夠保證解析DOM的同時，解析css文件。由於，CSS（外鏈或內聯）會阻塞整個DOM的渲染，然而DOM解析會正常進行，因此將css文件放在頭部進行解析，能夠加快網頁的構建速度。假設將其放在尾部，那時DOM樹幾乎構建，這時就得等到CSSOM樹構建完成，纔可以繼續下面的步驟。「js放在尾部」：js文件不一樣，將js文件放在尾部或者異步加載的緣由是JS（外鏈或內聯）會阻塞後續DOM的解析，後續DOM的渲染也將被阻塞，並且一旦js中遇到DOM元素的操做，極可能會影響。這方面能夠推薦一篇文章——異步腳本載入提升頁面性能。「避免使用內聯樣式」，能夠有效的減小html的體積，通常考慮內聯樣式的時候，每每是樣式自己體積比較小，每每加載網絡資源的時間會大於它的時候。

除了頁面渲染層面的優化，固然最重要的就是DOM操做方面的優化，這部分的優化應該是最多的，並且也是平時開發能夠注意的地方。若是開發前期明白這些原理，同時付諸實踐的話，就能夠在後期的性能完善上面少下不少功夫。那麼，接下來咱們能夠來看一下具體的操做：

  1. DOM操做優化：

    • 避免在document上直接進行頻繁的DOM操做
    • 使用classname代替大量的內聯樣式修改
    • 對於複雜的UI元素，設置position爲absolute或fixed
    • 儘可能使用css動畫
    • 使用requestAnimationFrame代替setInterval操做
    • 適當使用canvas
    • 儘可能減小css表達式的使用
    • 使用事件代理

    前面三個操做，其實都是但願『減小回流和重繪』。其實，進行一次DOM操做的代價是很是之大的，之前能夠經過網頁操做是否卡頓來進行判斷，可是，現代瀏覽器的進步已經大大減小了這方面的影響。可是，咱們仍是須要清楚，如何去減小回流和重繪的問題。由於這裏不想細說這方面的知識，想要了解的話，能夠看這篇文章——迴流與重繪：CSS性能讓JavaScript變慢？。這但是張鑫旭大大的一篇文章呦(^.^)。「儘可能使用css動畫」，是由於自己css動畫比較簡單，並且相較於js的複雜動畫，瀏覽器自己對其進行了優化，使用上面不會出現卡頓等問題。「使用requestAnimationFrame代替setInterval操做」，相信你們都有所耳聞，setInterval定時器會有必定的延時，對於變更性高的動畫來講，會出現卡頓現象。而requestAnimationFrame正好解決的整個問題。「適當使用canvas」，不得不說canvas是前端的一個進步，出現了它以後，前端界面的複雜性也隨之提高了。一些難以完成的動畫，均可以使用canvas進行輔助完成。可是，canvas使用頻繁的話，會加劇瀏覽器渲染的壓力，同時致使性能的降低。因此，適當時候使用canvas是一個不錯的建議。「儘可能減小css表達式的使用」，這個在YUI規則中也被提到過，每每css的表達式在設計之初都是美好的，但在使用過程當中，因爲其頻繁觸發的特性，會拖累網頁的性能，出現卡頓。所以在使用過程當中儘可能減小css表達式的使用，能夠改換成js進行操做。「使用事件代理」：每每對於具有冒泡性質的事件來講，使用事件代理不失爲一種好的方法。舉個例子：一段列表都須要設定點擊事件，這時若是你給列表中的每一項設定監聽，每每會致使總體的性能降低，可是若是你給整個列表設置一個事件，而後經過點擊定位目標來觸發相應的操做，每每性能就會獲得改善。

DOM操做的優化，還有不少，固然也包括移動端的。這個會在以後移動端優化部分被說起，此處先賣個關子。上面咱們概述了開始渲染的時候和DOM操做的時候的一些注意事項。接下來要講的是一些小細節的注意，這些細節可能對於頁面影響不大，可是一旦堆積多了，性能也會有所影響。

  1. 操做細節注意：

    • 避免圖片或者frame使用空src
    • 在css屬性爲0時，去掉單位
    • 禁止圖像縮放
    • 正確的css前綴的使用
    • 移除空的css規則
    • 對於css中可繼承的屬性，如font-size，儘可能使用繼承，少一點設置
    • 縮短css選擇器，多使用僞元素等幫助定位

    上述的一些操做細節，是平時在開發中被要求的，更能夠理解爲開發規範。(基本操做，坐下^_^)

列舉完基本操做以後，咱們再來聊一下移動端在DOM操做方面的一些優化。

  1. 移動端優化：

    • 長列表滾動優化
    • 函數防抖和函數節流
    • 使用touchstart、touchend代替click
    • HTML的viewport設置
    • 開啓GPU渲染加速

    首先，長列表滾動問題，是移動端須要面對的，IOS儘可能使用局部滾動，android儘可能使用全局滾動。同時，須要給body添加上-webkit-overflow-scrolling: touch來優化移動段的滾動。若是有興趣的同窗，能夠去了解一下ios和android滾動操做上的區別以及優化。「防抖和節流」，設計到滾動等會被頻繁觸發的DOM事件，須要作好防抖和節流的工做。它們都是爲了限制函數的執行頻次，以優化函數觸發頻率太高致使的響應速度跟不上觸發頻率，出現延遲，假死或卡頓的現象。

    介紹：函數防抖，當調用動做過n毫秒後，纔會執行該動做，若在這n毫秒內又調用此動做則將從新計算執行時間；函數節流，預先設定一個執行週期，當調用動做的時刻大於等於執行週期則執行該動做，而後進入下一個新週期。

    「touchstart、touchend代替click」，也是移動端比較經常使用的操做。click在移動端會有300ms延時，這應該是一個常識唄。(不知道的小夥伴該收藏一下呦)。這種方法會影響用戶的體驗。因此作優化時，最簡單的方法就是使用touchstart或者touchend代替click。由於它們事件執行順序是touchstart->touchmove->touchend->click。或者，使用fastclick或者zepto的tap事件代替click事件。「HTML的viewport設置」，能夠防止頁面的縮放，來優化性能。「開啓GPU渲染加速」，小夥伴們必定聽過CPU吧，可是這裏的GPU不能和CPU混爲一談呦。GPU的全名是Graphics Processing Unit，是一種硬件加速方式。通常的css渲染，瀏覽器的渲染引擎都不會使用到它。可是，在3D渲染時，計算量較大，繁重，瀏覽器會開啓顯卡的硬件加速來幫助完成這些操做。因此，咱們這裏可使用css中的translateZ設定，來欺騙瀏覽器，讓其幫忙開啓GPU加速，加快渲染進程。

DOM部分的優化，更多的是習慣。須要本身強制要求本身在開發過程當中去注意這些規範。因此，這部分的內容能夠多關注一下，纔可以慢慢了解。同時，本人對於上述幾點的描述是歸納性的。並無對其進行詳細的展開。所以，也要求你去細細的查閱Google呦。

數據方面

數據，也能夠說是前端優化方面比較重要的一塊內容。頁面與用戶的交互響應，每每伴隨着數據交互，處理，以及ajax的異步請求等內容。因此，咱們也能夠來聊聊這一塊的知識。首先是對於圖片數據的處理：

  1. 圖片加載處理：

    • 圖片預加載
    • 圖片懶加載
    • 首屏加載時進度條的顯示

    「圖片預加載」，預加載的寓意就是提早加載內容。而圖片的預加載每每會被用在圖片資源比較大，即時加載時會致使很長的等待過程時，纔會被使用的。常見場景：圖片漫畫展現時。每每會預加載一張到兩張的圖片。「圖片懶加載」，懶加載或許你是第一次據說，可是，這種方式在開發中會被常用。首先，咱們須要明白一個道理：每每只有看到的資源是必須的，其餘資源是能夠隨着用戶的滾動，隨即顯示的。因此，特別是對於圖片資源特別多的網站來講，作好圖片的懶加載是能夠大大提高網頁的載入速度的。

    常見的圖片懶加載的方式就是：在最初給圖片的src設置一個比較簡單的圖片，而後將圖片的真實地址設置給自定義的屬性，作一個佔位，而後給圖片設置監聽事件，一旦圖片到達視口範圍，從圖片的自定義屬性中獲取出真是地址，而後賦值給src，讓其進行加載。

    「首屏進度條的顯示」：每每對於首屏優化後的數據量並不滿意的話，同時也不能進一步縮短首屏包的長度了，就可使用進度條的方式，來提醒用戶進行等待。

講完了圖片這一塊數據資源的處理，每每咱們須要去優化一下異步請求這一部分的內容。由於，異步的數據獲取也是前端不可分割的。這一部分咱們也能夠作必定的處理：

  1. 異步請求的優化：

    • 使用正常的json數據格式進行交互
    • 部分經常使用數據的緩存
    • 數據埋點和統計

    「JSON交互」，JSON的數據格式輕巧，結構簡單，每每能夠大大優化先後端的數據通訊。「經常使用數據的緩存」，能夠將一些用戶的基本信息等經常使用的信息作一個緩存，這樣能夠保證ajax請求的減小。同時，HTML5新增的storage的內容，也不用怕cookie暴露，引發的信息泄漏問題。「數據埋點和統計」，對於資深的程序員來講，比較瞭解。並且目前的大部分公司也會作這方面的處理。有心的小夥伴能夠自行查閱。

最後，還有就是大量數據的運算。對於javascript語言來講，自己的單線程就限制了它並不能計算大量的數據，每每會形成頁面的卡頓。而可能業務中有些複雜的UI須要去運行大量的運算，因此，webWorker的使用是相當重要的。或許，前端標準普及的落後，會致使你們對於這些新生事物的短暫缺失吧。

瀏覽器訪問優化

瀏覽器請求處理流程以下圖：

 

一、減小http請求，合理設置 HTTP緩存

        http協議是無狀態的應用層協議，意味着每次http請求都須要創建通訊鏈路、進行數據傳輸，而在服務器端，每一個http都須要啓動獨立的線程去處理。這些通訊和服務的開銷都很昂貴，減小http請求的數目可有效提升訪問性能。

        減小http的主要手段是合併CSS、合併javascript、合併圖片。將瀏覽器一次訪問須要的javascript和CSS合併成一個文件，這樣瀏覽器就只須要一次請求。圖片也能夠合併，多張圖片合併成一張，若是每張圖片都有不一樣的超連接，可經過CSS偏移響應鼠標點擊操做，構造不一樣的URL。
         緩存的力量是強大的，恰當的緩存設置能夠大大的減小 HTTP請求。假設某網站首頁，當瀏覽器沒有緩存的時候訪問一共會發出 78個請求，共 600多 K數據，而當第二次訪問即瀏覽器已緩存以後訪問則僅有 10個請求，共 20多 K數據。 (這裏須要說明的是，若是直接 F5刷新頁面的話效果是不同的，這種狀況下請求數仍是同樣，不過被緩存資源的請求服務器是 304響應，只有 Header沒有Body，能夠節省帶寬 )

        怎樣纔算合理設置 ?原則很簡單，能緩存越多越好，能緩存越久越好。例如，不多變化的圖片資源能夠直接經過 HTTP Header中的Expires設置一個很長的過時頭 ;變化不頻繁而又可能會變的資源可使用 Last-Modifed來作請求驗證。儘量的讓資源可以在緩存中待得更久。關於 HTTP緩存的具體設置和原理此處就再也不詳述了。

二、使用瀏覽器緩存

        對一個網站而言，CSS、javascript、logo、圖標這些靜態資源文件更新的頻率都比較低，而這些文件又幾乎是每次http請求都須要的，若是將這些文件緩存在瀏覽器中，能夠極好的改善性能。經過設置http頭中的cache-control和expires的屬性，可設定瀏覽器緩存，緩存時間能夠是數天，甚至是幾個月。

        在某些時候，靜態資源文件變化須要及時應用到客戶端瀏覽器，這種狀況，可經過改變文件名實現，即更新javascript文件並非更新javascript文件內容，而是生成一個新的JS文件並更新HTML文件中的引用。
        使用瀏覽器緩存策略的網站在更新靜態資源時，應採用逐量更新的方法，好比須要更新10個圖標文件，不宜把10個文件一次所有更新，而是應該一個文件一個文件逐步更新，並有必定的間隔時間，以避免用戶瀏覽器突然大量緩存失效，集中更新緩存，形成服務器負載驟增、網絡堵塞的狀況。

三、啓用壓縮

        在服務器端對文件進行壓縮，在瀏覽器端對文件解壓縮，可有效減小通訊傳輸的數據量。若是能夠的話，儘量的將外部的腳本、樣式進行合併，多個合爲一個。文本文件的壓縮效率可達到80%以上，所以HTML、CSS、javascript文件啓用GZip壓縮可達到較好的效果。可是壓縮對服務器和瀏覽器產生必定的壓力，在通訊帶寬良好，而服務器資源不足的狀況下要權衡考慮。

四、CSS Sprites

合併 CSS圖片，減小請求數的又一個好辦法。

五、LazyLoad Images

        這條策略實際上並不必定能減小 HTTP請求數，可是卻能在某些條件下或者頁面剛加載時減小 HTTP請求數。對於圖片而言，在頁面剛加載的時候能夠只加載第一屏，當用戶繼續日後滾屏的時候才加載後續的圖片。這樣一來，假如用戶只對第一屏的內容感興趣時，那剩餘的圖片請求就都節省了。

六、CSS放在頁面最上部，javascript放在頁面最下面

       瀏覽器會在下載完成所有CSS以後纔對整個頁面進行渲染，所以最好的作法是將CSS放在頁面最上面，讓瀏覽器儘快下載CSS。若是將 CSS放在其餘地方好比 BODY中，則瀏覽器有可能還未下載和解析到 CSS就已經開始渲染頁面了，這就致使頁面由無 CSS狀態跳轉到 CSS狀態，用戶體驗比較糟糕，因此能夠考慮將CSS放在HEAD中。

        Javascript則相反，瀏覽器在加載javascript後當即執行，有可能會阻塞整個頁面，形成頁面顯示緩慢，所以javascript最好放在頁面最下面。但若是頁面解析時就須要用到javascript，這時放到底部就不合適了。

        Lazy Load Javascript（只有在須要加載的時候加載，在通常狀況下並不加載信息內容。）隨着 Javascript框架的流行，愈來愈多的站點也使用起了框架。不過，一個框架每每包括了不少的功能實現，這些功能並非每個頁面都須要的，若是下載了不須要的腳本則算得上是一種資源浪費 -既浪費了帶寬又浪費了執行花費的時間。目前的作法大概有兩種，一種是爲那些流量特別大的頁面專門定製一個專用的 mini版框架，另外一種則是 Lazy Load。

七、異步請求Callback（就是將一些行爲樣式提取出來，慢慢的加載信息的內容）

在某些頁面中可能存在這樣一種需求，須要使用 script標籤來異步的請求數據。相似：

 
<span style="font-size:14px;">/*Callback 函數*/
 
function myCallback(info){
 
//do something here
 
}
 
　HTML:
 
　　Callback返回的內容 :
 
myCallback('Hello world!');
 
</span>

 

像以上這種方式直接在頁面上寫 <script> 對頁面的性能也是有影響的，即增長了頁面首次加載的負擔，推遲了 DOMLoaded和window.onload 事件的觸發時機。若是時效性容許的話，能夠考慮在 DOMLoaded事件觸發的時候加載，或者使用 setTimeout方式來靈活的控制加載的時機。

八、減小cookie傳輸

        一方面，cookie包含在每次請求和響應中，太大的cookie會嚴重影響數據傳輸，所以哪些數據須要寫入cookie須要慎重考慮，儘可能減小cookie中傳輸的數據量。另外一方面，對於某些靜態資源的訪問，如CSS、script等，發送cookie沒有意義，能夠考慮靜態資源使用獨立域名訪問，避免請求靜態資源時發送cookie，減小cookie傳輸次數。

九、Javascript代碼優化

(1). DOM　　

a.HTML Collection（HTML收集器，返回的是一個數組內容信息） 
　　在腳本中 document.images、document.forms、getElementsByTagName()返回的都是HTMLCollection類型的集合，在平時使用的時候大多將它做爲數組來使用，由於它有 length屬性，也可使用索引訪問每個元素。不過在訪問性能上則比數組要差不少，緣由是這個集合並非一個靜態的結果，它表示的僅僅是一個特定的查詢，每次訪問該集合時都會從新執行這個查詢從而更新查詢結果。所謂的「訪問集合」 包括讀取集合的 length屬性、訪問集合中的元素。 
　　所以，當你須要遍歷 HTML Collection的時候，儘可能將它轉爲數組後再訪問，以提升性能。即便不轉換爲數組，也請儘量少的訪問它，例如在遍歷的時候能夠將 length屬性、成員保存到局部變量後再使用局部變量。　　 
b. Reflow & Repaint　　 
　　除了上面一點以外， DOM操做還須要考慮瀏覽器的Reflow和Repaint ，由於這些都是須要消耗資源的。

(2). 慎用 with　

with(obj){ p = 1}; 代碼塊的行爲其實是修改了代碼塊中的執行環境 ，將obj放在了其做用域鏈的最前端，在 with代碼塊中訪問非局部變量是都是先從 obj上開始查找，若是沒有再依次按做用域鏈向上查找，所以使用 with至關於增長了做用域鏈長度。而每次查找做用域鏈都是要消耗時間的，過長的做用域鏈會致使查找性能降低。 
　　所以，除非你能確定在 with代碼中只訪問 obj中的屬性，不然慎用 with，替代的可使用局部變量緩存須要訪問的屬性。

(3). 避免使用 eval和 Function

每次 eval 或Function 構造函數做用於字符串表示的源代碼時，腳本引擎都須要將源代碼轉換成可執行代碼。這是很消耗資源的操做 —— 一般比簡單的函數調用慢 100倍以上。 
　　eval 函數效率特別低，因爲事先沒法知曉傳給 eval 的字符串中的內容，eval在其上下文中解釋要處理的代碼，也就是說編譯器沒法優化上下文，所以只能有瀏覽器在運行時解釋代碼。這對性能影響很大。 
　　Function 構造函數比 eval略好，由於使用此代碼不會影響周圍代碼 ;但其速度仍很慢。 
　　此外，使用 eval和 Function也不利於Javascript 壓縮工具執行壓縮。

(4). 減小做用域鏈查找

前文談到了做用域鏈查找問題，這一點在循環中是尤爲須要注意的問題。若是在循環中須要訪問非本做用域下的變量時請在遍歷以前用局部變量緩存該變量，並在遍歷結束後再重寫那個變量，這一點對全局變量尤爲重要，由於全局變量處於做用域鏈的最頂端，訪問時的查找次數是最多的。 
低效率的寫法：

 
<span style="font-size:14px;">// 全局變量
 
var globalVar = 1;
 
function myCallback(info){
 
for( var i = 100000; i--;){
 
//每次訪問 globalVar 都須要查找到做用域鏈最頂端，本例中須要訪問 100000 次
 
globalVar += i;
 
}
 
}
 
</span>

 

更高效的寫法：

 
<span style="font-size:14px;">// 全局變量
 
var globalVar = 1;
 
function myCallback(info){
 
//局部變量緩存全局變量
 
var localVar = globalVar;
 
for( var i = 100000; i--;){
 
//訪問局部變量是最快的
 
localVar += i;
 
}
 
//本例中只須要訪問 2次全局變量
 
在函數中只須要將 globalVar中內容的值賦給localVar 中
 
globalVar = localVar;
 
}
 
</span>

 

此外，要減小做用域鏈查找還應該減小閉包的使用。

(5). 數據訪問

　　Javascript中的數據訪問包括直接量 (字符串、正則表達式 )、變量、對象屬性以及數組，其中對直接量和局部變量的訪問是最快的，對對象屬性以及數組的訪問須要更大的開銷。當出現如下狀況時，建議將數據放入局部變量： 
　　a. 對任何對象屬性的訪問超過 1次 
　　b. 對任何數組成員的訪問次數超過 1次 
　　另外，還應當儘量的減小對對象以及數組深度查找。

(6). 字符串拼接

在 Javascript中使用」+」號來拼接字符串效率是比較低的，由於每次運行都會開闢新的內存並生成新的字符串變量，而後將拼接結果賦值給新變量。與之相比更爲高效的作法是使用數組的 join方法，即將須要拼接的字符串放在數組中最後調用其 join方法獲得結果。不過因爲使用數組也有必定的開銷，所以當須要拼接的字符串較多的時候能夠考慮用此方法。

十、CSS選擇符優化

在大多數人的觀念中，都以爲瀏覽器對 CSS選擇符的解析式從左往右進行的，例如 
#toc A { color: #444; }這樣一個選擇符，若是是從右往左解析則效率會很高，由於第一個 ID選擇基本上就把查找的範圍限定了，但實際上瀏覽器對選擇符的解析是從右往左進行的。如上面的選擇符，瀏覽器必須遍歷查找每個 A標籤的祖先節點，效率並不像以前想象的那樣高。根據瀏覽器的這一行爲特色，在寫選擇符的時候須要注意不少事項，有興趣的童鞋能夠去了解一下。

CDN加速

CDN（contentdistribute network，內容分發網絡）的本質仍然是一個緩存，並且將數據緩存在離用戶最近的地方，使用戶以最快速度獲取數據，即所謂網絡訪問第一跳，以下圖。

 

因爲CDN部署在網絡運營商的機房，這些運營商又是終端用戶的網絡服務提供商，所以用戶請求路由的第一跳就到達了CDN服務器，當CDN中存在瀏覽器請求的資源時，從CDN直接返回給瀏覽器，最短路徑返回響應，加快用戶訪問速度，減小數據中心負載壓力。 
CDN緩存的通常是靜態資源，如圖片、文件、CSS、script腳本、靜態網頁等，可是這些文件訪問頻度很高，將其緩存在CDN可極大改善網頁的打開速度。

反向代理

傳統代理服務器位於瀏覽器一側，代理瀏覽器將http請求發送到互聯網上，而反向代理服務器位於網站機房一側，代理網站web服務器接收http請求。以下圖所示：

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程