當前位置:首頁 » 網頁前端 » 怎麼優化前端
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

怎麼優化前端

發布時間: 2022-05-01 04:34:45

① 怎麼優化前端代碼,讓百度高效識別移動頁面

優化前端代碼有一下幾點:
(1)CSS代碼簡寫。這里說的簡寫主要解決的問題是,網站代碼冗餘,去除不必要的空格等等。如果可以用一句表達的語言,就不要多出幾行代碼,符合W3C標准。
(2)同屬性提出
如果2個樣式帶有同樣的屬性,可以把同屬性單獨提出處理。例如A樣式和B樣式的字體顏色、大小、邊框都一樣,那麼就可以考慮提出。
(3)結構清晰優化
網站代碼清晰是指,把代碼分區處理:網站頭部、網站身體,網站底部,3個區域進行不同的布局。不同區間的代碼要區別總的選擇器,選擇不同顏色加以區分隔開處理。
代碼簡化,爬行的目錄層次淺,這樣加強了搜索引擎對代碼的友好程度,進而提高網站的權重,關鍵詞才會有良好的排名。如果代碼冗餘,煩瑣,搜索引擎也就關注的少了。

② 如何做好網站前端優化

一. 清理 HTML 文檔
二. 優化 CSS 性能
三.減少外部HTTP請求
四. 壓縮 CSS, JS 和 HTML
五. 使用預先獲取
六. 使用 CDN 和緩存提高速度
七. 壓縮文件
八. 優化你的圖片
九. 使用輕量級框架
十.前端優化 – 總結
進行前端優化似乎需要花費很大的精力,相信這篇應用指南中的一些小技巧能幫你極大改善網站載入速度。網站載入地越快,則用戶體驗越佳。因此, 對前端進行優化能使給你和你的用戶都帶來益處。如果你有任何其他好的優化方法,請在評論區留下您的寶貴建議。

③ 如何進行Web前端優化

web前端優化要從幾個方面入手
1.考慮頁面的用戶體驗。用戶體驗包括界面的美觀性、頁面請求響應速度、資源消耗要盡量少(如腳本執行時cpu資源的消耗要盡可能的少)、界面是否友好,可交互性強不強等方面去優化。
2.前端代碼的可維護性。代碼的規范,組件的可重用性,注釋是否充分,盡量加強代碼的可讀性等方面去優化。

④ 前端性能優化的具體方法有哪些

解決辦法一:

減少http請求次數:CSS Sprites, JS、CSS源碼壓縮、圖片大小控制合適;網頁Gzip,CDN託管,data緩存 ,圖片伺服器。
前端模板 JS+數據,減少由於HTML標簽導致的帶寬浪費,前端用變數保存AJAX請求結果,每次操作本地變數,不用請求,減少請求次數
用innerHTML代替DOM操作,減少DOM操作次數,優化javascript性能。
當需要設置的樣式很多時設置className而不是直接操作style。
少用全局變數、緩存DOM節點查找的結果。減少IO讀取操作。
避免使用CSS Expression(css表達式)又稱Dynamic properties(動態屬性)。
圖片預載入,將樣式表放在頂部,將腳本放在底部 加上時間戳。
解決辦法二:

減少HTTP請求次數
使用CDN:CDN在前端開發的作用
避免空的src和href
為文件頭指定Expires
使用gzip壓縮內容
把CSS放到頂部
把JS放到底部
避 免使用CSS表達式
將CSS和JS放到外部文件中
避免跳轉
可緩存的AJAX
使用GET來完成AJAX請求

⑤ 你有用過哪些前端性能優化的方法

這個是面試常問的問題了。

我來簡單說下幾個方面:

1.減少http請求:在YUI35規則中也有提到,主要是優化js、css和圖片資源三個方面,因為html是沒有辦法避免的。因此,我們可以做一下的幾項操作:

  • 合並js文件

  • 合並css文件

  • 雪碧圖的使用(css sprite)

  • 使用base64表示簡單的圖片

2.減少資源體積

  • 壓縮css

  • 壓縮js

  • 壓縮圖片

3.圖片載入處理:

  • 圖片預載入

  • 圖片懶載入

  • 首屏載入時進度條的顯示

就簡單說這些,特別詳細的可以網上看下。

⑥ 如何對前端性能進行優化

前端開發代碼優化、可維護性、瀏覽器兼容性是非常重要的課題。從實際的工程應用角度出發,最常遇見的前端優化問題。前端性能進行優化規則,基本可以涵蓋現在前端大部分的性能優化原則了,很多更加geek和精細優化方法都是從這些原則裡面延伸出來的。

前端性能進行優化都有哪些規則

  1. 減少HTTP請求次數

    盡量合並圖片、CSS、JS。比如載入一個頁面有5個css文件的話,把這個5個文件合成一個的話,就只需要發出一次http請求,節省網路請求時間,加快頁面的載入。

2. 使用CDN

網站上靜態資源即css、js全都使用cdn分發,包括圖片

3. 避免空的src和href

當link標簽的href屬性為空、script標簽的src屬性為空的時候,瀏覽器渲染的時候會把當前頁面的URL作為它們的屬性值,從而把頁面的內容載入進來作為它們的值。所以要避免犯這樣的疏忽。

4. 為文件頭指定Expires

Exipres是用來設置文件的過期時間的,一般對css、js、圖片資源有效。 他可以使內容具有緩存性,這樣下回再訪問同樣的資源時就通過瀏覽器緩存區讀取,不需要再發出http請求。如下例子:

新浪微博的這個css文件的Expires時間是2016-5-04 09:14:14.

5. 使用gzip壓縮內容

gzip能夠壓縮任何一個文本類型的響應,包括html,xml,json。大大縮小請求返回的數據量。

6. 把CSS放到頂部

網頁上的資源載入時從上網下順序載入的,所以css放在頁面的頂部能夠優先渲染頁面,讓用戶感覺頁面載入很快。

7. 把JS放到底部

載入js時會對後續的資源造成阻塞,必須得等js載入完才去載入後續的文件 ,所以就把js放在頁面底部最後載入。

8. 避免使用CSS表達式

舉個css表達式的例子

font-color: expression( (new Date()).getHours()%3 ? 「#FFFFFF" : 「#AAAAAA" );

這個表達式會持續的在頁面上計算樣式,影響頁面的性能。並且css表達式只被IE支持。

9. 將CSS和JS放到外部文件中

目的是緩存文件,可以參考原則4。 但有時候為了減少請求,也會直接寫到頁面里,需根據PV和IP的比例權衡。

10. 權衡DNS查找次數

減少主機名可以節省響應時間。但同時,需要注意,減少主機會減少頁面中並行下載的數量。

IE瀏覽器在同一時刻只能從同一域名下載兩個文件。當在一個頁面顯示多張圖片時,IE 用戶的圖片下載速度就會受到影響。所以新浪會搞N個二級域名來放圖片。

下面是新浪微博的圖片域名,我們可以看到他有多個域名,這樣可以保證這些不同域名能夠同時去下載圖片,而不用排隊。不過如果當使用的域名過多時,響應時間就會慢,因為不用響應域名時間不一致。

11. 精簡CSS和JS

這里就涉及到css和js的壓縮了。比如下面的新浪的一個css文件,把空格回車全部去掉,減少文件的大小。現在的壓縮工具有很多,基本主流的前端構建工具都能進行css和js文件的壓縮,如grunt,glup等。

12. 避免跳轉

有種現象會比較坑爹,看起來沒什麼差別,其實多次了一次頁面跳轉。比如當URL本該有斜杠(/)卻被忽略掉時。例如,當我們要訪問http:// .com時,實際上返回的是一個包含301代碼的跳轉,它指向的是http:// .com/(注意末尾的斜杠)。在nginx伺服器可以使用rewrite;Apache伺服器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。

另一種是不用域名之間的跳轉, 比如訪問http:// .com/bbs跳轉到http:// bbs..com/。那麼可以通過使用Alias或者mod_rewirte建立CNAME(保存一個域名和另外一個域名之間關系的DNS記錄)來替代。

13. 刪除重復的JS和CSS

重復調用腳本,除了增加額外的HTTP請求外,多次運算也會浪費時間。在IE和Firefox中不管腳本是否可緩存,它們都存在重復運算JavaScript的問題。

14. 配置ETags

它用來判斷瀏覽器緩存里的元素是否和原來伺服器上的一致。比last-modified date更具有彈性,例如某個文件在1秒內修改了10次,Etag可以綜合Inode(文件的索引節點(inode)數),MTime(修改時間)和Size來精準的進行判斷,避開UNIX記錄MTime只能精確到秒的問題。 伺服器集群使用,可取後兩個參數。使用ETags減少Web應用帶寬和負載

15. 可緩存的AJAX

非同步請求同樣的造成用戶等待,所以使用ajax請求時,要主動告訴瀏覽器如果該請求有緩存就去請求緩存內容。如下代碼片段, cache:true就是顯式的要求如果當前請求有緩存的話,直接使用緩存

$.ajax({ url : 'url', dataType : "json", cache: true, success : function(son, status){ }

16. 使用GET來完成AJAX請求

當使用XMLHttpRequest時,瀏覽器中的POST方法是一個「兩步走」的過程:首先發送文件頭,然後才發送數據。因此使用GET獲取數據時更加有意義。

17. 減少DOM元素數量

這是一門大學問,這里可以引申出一堆優化的細節。想要具體研究的可以看後面推薦書籍。總之大原則減少DOM數量,就會減少瀏覽器的解析負擔。

18. 避免404

比如外鏈的css、js文件出現問題返回404時,會破壞瀏覽器的並行載入。

19. 減少Cookie的大小

Cookie裡面別塞那麼多東西,因為每個請求都得帶著他跑。

20. 使用無cookie的域

比如CSS、js、圖片等,客戶端請求靜態文件的時候,減少了 Cookie 的反復傳輸對主域名的影響。

21. 不要使用濾鏡

IE獨有屬性AlphaImageLoader用於修正7.0以下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在於瀏覽器載入圖片時它會終止內容的呈現並且凍結瀏覽器。在每一個元素(不僅僅是圖片)它都會運算一次,增加了內存開支,因此它的問題是多方面的。

完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替,這種格式能在IE中很好地工作。如果你確實需要使用AlphaImageLoader,請使用下劃線_filter又使之對IE7以上版本的用戶無效。

22. 不要在HTML中縮放圖片

比如你需要的圖片尺寸是50* 50

那就不用用一張500*500的大尺寸圖片,影響載入

23. 縮小favicon.ico並緩存

⑦ 常用的前端性能優化方法有哪些

1、減少http請求,合理設置HTTP緩存

2、使用瀏覽器緩存

3、啟用壓縮

4、CSS Sprites,合並 CSS圖片,減少請求數

5、CSS放在頁面最上部,javascript放在頁面最下面

⑧ 如何優化前端頁面體驗和訪問速度

1.優化圖片

這個絕對是顯而易見的,可以看到圖片占據的頁面內容分量最重。在現代網頁設計中,圖片絕對占據了大部分的內容。你需要針對你的頁面重新定義圖片大小。這能夠有效地幫助你減少頁面大小。而且,這里有很多的功能能夠幫助你針對圖片減肥,例如,Smush.it和TinyPNG
在photoshop中保存web所用格式圖片時候適當的進行壓縮。或者採用圖片延遲載入技術
2.壓縮CSS和Javascript代碼

有效地壓縮CSS和javascript代碼能夠有效地減少頁面大小,你可以刪除空格優化代碼。當然,壓縮代碼對於代碼閱讀不是非常有用,但是一般作為產品環境來說,我們通過這種方式可以有效地減少頁面載入時間。css&js壓縮工具
3.避免使用@import

@import CSS語法允許你載入其它的CSS文件。有時間非常有幫助,但是它並不是和主文件一起下載的,所以可能會增加頁面載入時間。建議使用link標簽,這樣會更加高效。
4.減少HTTP請求次數

減少HTTP請求次數可以幫助你有效的增加網站載入速度。你可以使用如下方式:
a.融合文件
將不同的樣式表css合成一個文件可以減少http請求的次數。同樣對於javascript來說也適用。
b.使用CSS sprites
使用sprites可以幫助你把多個圖片文件放置到一個文件里,這樣可以減少圖片下載的次數。
5.javascript引用位置
例如:javascript的引用和cnzz的統計放到在代碼中放到body之後。

⑨ 常見的前端性能優化手段都有哪些都有多大收益

前端是龐大的,包括 HTML、 CSS、 Javascript、Image 、Flash等等各種各樣的資源。前端優化是復雜的,針對方方面面的資源都有不同的方式。那麼,前端優化的目的是什麼 ?
1. 從用戶角度而言,優化能夠讓頁面載入得更快、對用戶的操作響應得更及時,能夠給用戶提供更為友好的體驗。
2. 從服務商角度而言,優化能夠減少頁面請求數、或者減小請求所佔帶寬,能夠節省可觀的資源。
總之,恰當的優化不僅能夠改善站點的用戶體驗並且能夠節省相當的資源利用。
前端優化的途徑有很多,按粒度大致可以分為兩類,第一類是頁面級別的優化,例如 HTTP請求數、腳本的無阻塞載入、內聯腳本的位置優化等 ;第二類則是代碼級別的優化,例如 Javascript中的DOM 操作優化、CSS選擇符優化、圖片優化以及 HTML結構優化等等。另外,本著提高投入產出比的目的,後文提到的各種優化策略大致按照投入產出比從大到小的順序排列。
一、頁面級優化
1. 減少 HTTP請求數
這條策略基本上所有前端人都知道,而且也是最重要最有效的。都說要減少 HTTP請求,那請求多了到底會怎麼樣呢 ?首先,每個請求都是有成本的,既包含時間成本也包含資源成本。一個完整的請求都需要經過 DNS定址、與伺服器建立連接、發送數據、等待伺服器響應、接收數據這樣一個 「漫長」 而復雜的過程。時間成本就是用戶需要看到或者 「感受」 到這個資源是必須要等待這個過程結束的,資源上由於每個請求都需要攜帶數據,因此每個請求都需要佔用帶寬。另外,由於瀏覽器進行並發請求的請求數是有上限的 (具體參見此處 ),因此請求數多了以後,瀏覽器需要分批進行請求,因此會增加用戶的等待時間,會給用戶造成站點速度慢這樣一個印象,即使可能用戶能看到的第一屏的資源都已經請求完了,但是瀏覽器的進度條會一直存在。
減少 HTTP請求數的主要途徑包括:
(1). 從設計實現層面簡化頁面
如果你的頁面像網路首頁一樣簡單,那麼接下來的規則基本上都用不著了。保持頁面簡潔、減少資源的使用時最直接的。如果不是這樣,你的頁面需要華麗的皮膚,則繼續閱讀下面的內容。
(2). 合理設置 HTTP緩存
緩存的力量是強大的,恰當的緩存設置可以大大的減少 HTTP請求。以有啊首頁為例,當瀏覽器沒有緩存的時候訪問一共會發出 78個請求,共 600多 K數據 (如圖 1.1),而當第二次訪問即瀏覽器已緩存之後訪問則僅有 10個請求,共 20多 K數據 (如圖 1.2)。 (這里需要說明的是,如果直接 F5刷新頁面的話效果是不一樣的,這種情況下請求數還是一樣,不過被緩存資源的請求伺服器是 304響應,只有 Header沒有Body ,可以節省帶寬 )
怎樣才算合理設置 ?原則很簡單,能緩存越多越好,能緩存越久越好。例如,很少變化的圖片資源可以直接通過 HTTP Header中的Expires設置一個很長的過期頭 ;變化不頻繁而又可能會變的資源可以使用 Last-Modifed來做請求驗證。盡可能的讓資源能夠在緩存中待得更久。關於 HTTP緩存的具體設置和原理此處就不再詳述了,有興趣的可以參考下列文章:
HTTP1.1協議中關於緩存策略的描述
Fiddler HTTP Performance中關於緩存的介紹
(3). 資源合並與壓縮
如果可以的話,盡可能的將外部的腳本、樣式進行合並,多個合為一個。另外, CSS、 Javascript、Image 都可以用相應的工具進行壓縮,壓縮後往往能省下不少空間。
(4). CSS Sprites
合並 CSS圖片,減少請求數的又一個好辦法。
(5). Inline Images
使用 data: URL scheme的方式將圖片嵌入到頁面或 CSS中,如果不考慮資源管理上的問題的話,不失為一個好辦法。如果是嵌入頁面的話換來的是增大了頁面的體積,而且無法利用瀏覽器緩存。使用在 CSS中的圖片則更為理想一些。
(6). Lazy Load Images(自己對這一塊的內容還是不了解)
這條策略實際上並不一定能減少 HTTP請求數,但是卻能在某些條件下或者頁面剛載入時減少 HTTP請求數。對於圖片而言,在頁面剛載入的時候可以只載入第一屏,當用戶繼續往後滾屏的時候才載入後續的圖片。這樣一來,假如用戶只對第一屏的內容感興趣時,那剩餘的圖片請求就都節省了。 有啊首頁 曾經的做法是在載入的時候把第一屏之後的圖片地址緩存在 Textarea標簽中,待用戶往下滾屏的時候才 「惰性」 載入。

2. 將外部腳本置底(將腳本內容在頁面信息內容載入後再載入)
前文有談到,瀏覽器是可以並發請求的,這一特點使得其能夠更快的載入資源,然而外鏈腳本在載入時卻會阻塞其他資源,例如在腳本載入完成之前,它後面的圖片、樣式以及其他腳本都處於阻塞狀態,直到腳本載入完成後才會開始載入。如果將腳本放在比較靠前的位置,則會影響整個頁面的載入速度從而影響用戶體驗。解決這一問題的方法有很多,在 這里有比較詳細的介紹 (這里是譯文和 更詳細的例子 ),而最簡單可依賴的方法就是將腳本盡可能的往後挪,減少對並發下載的影響。
3. 非同步執行 inline腳本(其實原理和上面是一樣,保證腳本在頁面內容後面載入。)
inline腳本對性能的影響與外部腳本相比,是有過之而無不及。首頁,與外部腳本一樣, inline腳本在執行的時候一樣會阻塞並發請求,除此之外,由於瀏覽器在頁面處理方面是單線程的,當 inline腳本在頁面渲染之前執行時,頁面的渲染工作則會被推遲。簡而言之, inline腳本在執行的時候,頁面處於空白狀態。鑒於以上兩點原因,建議將執行時間較長的 inline腳本非同步執行,非同步的方式有很多種,例如使用 script元素的defer 屬性(存在兼容性問題和其他一些問題,例如不能使用 document.write)、使用setTimeout ,此外,在HTML5中引入了 Web Workers的機制,恰恰可以解決此類問題。

4. Lazy Load Javascript(只有在需要載入的時候載入,在一般情況下並不載入信息內容。)
隨著 Javascript框架的流行,越來越多的站點也使用起了框架。不過,一個框架往往包括了很多的功能實現,這些功能並不是每一個頁面都需要的,如果下載了不需要的腳本則算得上是一種資源浪費 -既浪費了帶寬又浪費了執行花費的時間。目前的做法大概有兩種,一種是為那些流量特別大的頁面專門定製一個專用的 mini版框架,另一種則是 Lazy Load。YUI 則使用了第二種方式,在 YUI的實現中,最初只載入核心模塊,其他模塊可以等到需要使用的時候才載入。

5. 將 CSS放在 HEAD中
如果將 CSS放在其他地方比如 BODY中,則瀏覽器有可能還未下載和解析到 CSS就已經開始渲染頁面了,這就導致頁面由無 CSS狀態跳轉到 CSS狀態,用戶體驗比較糟糕。除此之外,有些瀏覽器會在 CSS下載完成後才開始渲染頁面,如果 CSS放在靠下的位置則會導致瀏覽器將渲染時間推遲。
6. 非同步請求 Callback(就是將一些行為樣式提取出來,慢慢的載入信息的內容)
在某些頁面中可能存在這樣一種需求,需要使用 script標簽來非同步的請求數據。類似:
Javascript:

function myCallback(info){
//do something here
}
HTML:

cb返回的內容 :
myCallback('Hello world!');
像以上這種方式直接在頁面上寫 <script>對頁面的性能也是有影響的,即增加了頁面首次載入的負擔,推遲了 DOMLoaded和window.onload 事件的觸發時機。如果時效性允許的話,可以考慮在 DOMLoaded事件觸發的時候載入,或者使用 setTimeout方式來靈活的控制載入的時機。
7. 減少不必要的 HTTP跳轉
對於以目錄形式訪問的 HTTP鏈接,很多人都會忽略鏈接最後是否帶 』/',假如你的伺服器對此是區別對待的話,那麼你也需要注意,這其中很可能隱藏了 301跳轉,增加了多餘請求。具體參見下圖,其中第一個鏈接是以無 』/'結尾的方式訪問的,於是伺服器有了一次跳轉。
8. 避免重復的資源請求
這種情況主要是由於疏忽或頁面由多個模塊拼接而成,然後每個模塊中請求了同樣的資源時,會導致資源的重復請求

二、代碼級優化
1. Javascript
(1). DOM
DOM操作應該是腳本中最耗性能的一類操作,例如增加、修改、刪除 DOM元素或者對 DOM集合進行操作。如果腳本中包含了大量的 DOM操作則需要注意以下幾點:
a. HTML Collection(HTML收集器,返回的是一個數組內容信息)
在腳本中 document.images、document.forms 、getElementsByTagName()返回的都是 HTMLCollection類型的集合,在平時使用的時候大多將它作為數組來使用,因為它有 length屬性,也可以使用索引訪問每一個元素。不過在訪問性能上則比數組要差很多,原因是這個集合並不是一個靜態的結果,它表示的僅僅是一個特定的查詢,每次訪問該集合時都會重新執行這個查詢從而更新查詢結果。所謂的 「訪問集合」 包括讀取集合的 length屬性、訪問集合中的元素。
因此,當你需要遍歷 HTML Collection的時候,盡量將它轉為數組後再訪問,以提高性能。即使不轉換為數組,也請盡可能少的訪問它,例如在遍歷的時候可以將 length屬性、成員保存到局部變數後再使用局部變數。
b. Reflow & Repaint
除了上面一點之外, DOM操作還需要考慮瀏覽器的 Reflow和Repaint ,因為這些都是需要消耗資源的,具體的可以參加以下文章:
如何減少瀏覽器的repaint和reflow?
Understanding Internet Explorer Rendering Behaviour
Notes on HTML Reflow

(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). 減少作用域鏈查找(這方面設計到一些內容的相關問題)
前文談到了作用域鏈查找問題,這一點在循環中是尤其需要注意的問題。如果在循環中需要訪問非本作用域下的變數時請在遍歷之前用局部變數緩存該變數,並在遍歷結束後再重寫那個變數,這一點對全局變數尤其重要,因為全局變數處於作用域鏈的最頂端,訪問時的查找次數是最多的。
低效率的寫法:
// 全局變數
var globalVar = 1;
function myCallback(info){
for( var i = 100000; i--;){
//每次訪問 globalVar 都需要查找到作用域鏈最頂端,本例中需要訪問 100000 次
globalVar += i;
}
}
更高效的寫法:
// 全局變數
var globalVar = 1;
function myCallback(info){
//局部變數緩存全局變數
var localVar = globalVar;
for( var i = 100000; i--;){
//訪問局部變數是最快的
localVar += i;
}
//本例中只需要訪問 2次全局變數
在函數中只需要將 globalVar中內容的值賦給localVar 中區
globalVar = localVar;
}
此外,要減少作用域鏈查找還應該減少閉包的使用。
(5). 數據訪問
Javascript中的數據訪問包括直接量 (字元串、正則表達式 )、變數、對象屬性以及數組,其中對直接量和局部變數的訪問是最快的,對對象屬性以及數組的訪問需要更大的開銷。當出現以下情況時,建議將數據放入局部變數:
a. 對任何對象屬性的訪問超過 1次
b. 對任何數組成員的訪問次數超過 1次
另外,還應當盡可能的減少對對象以及數組深度查找。
(6). 字元串拼接
在 Javascript中使用"+" 號來拼接字元串效率是比較低的,因為每次運行都會開辟新的內存並生成新的字元串變數,然後將拼接結果賦值給新變數。與之相比更為高效的做法是使用數組的 join方法,即將需要拼接的字元串放在數組中最後調用其 join方法得到結果。不過由於使用數組也有一定的開銷,因此當需要拼接的字元串較多的時候可以考慮用此方法。

關於 Javascript優化的更詳細介紹請參考:
Write Efficient Javascript(PPT)
Efficient JavaScript
2. CSS選擇符
在大多數人的觀念中,都覺得瀏覽器對 CSS選擇符的解析式從左往右進行的,例如
#toc A { color: #444; }
這樣一個選擇符,如果是從右往左解析則效率會很高,因為第一個 ID選擇基本上就把查找的范圍限定了,但實際上瀏覽器對選擇符的解析是從右往左進行的。如上面的選擇符,瀏覽器必須遍歷查找每一個 A標簽的祖先節點,效率並不像之前想像的那樣高。根據瀏覽器的這一行為特點,在寫選擇符的時候需要注意很多事項,有人已經一一列舉了, 詳情參考此處。

3. HTML
對 HTML本身的優化現如今也越來越多的受人關注了,詳情可以參見這篇 總結性文章 。

4. Image壓縮
圖片壓縮是個技術活,不過現如今這方面的工具也非常多,壓縮之後往往能帶來不錯的效果,具體的壓縮原理以及方法在《 Even Faster Web Sites》第10 章有很詳細的介紹,有興趣的可以去看看。
總結
本文從頁面級以及代碼級兩個粒度對前端優化的各種方式做了一個總結,這些方法基本上都是前端開發人員在開發的過程中可以借鑒和實踐的,除此之外,完整的前端優化還應該包括很多其他的途徑,例如 CDN、 Gzip、多域名、無 Cookie伺服器等等,由於對於開發人員的可操作性並不強大,在此也就不多敘述了,詳細的可以參考 Yahoo和Google 的這些「金科玉律。