今日大致瀏覽了一下《High Performance Web Sites》。本書(shū)的中文版是《高性能網(wǎng)站建設指南》。
本書(shū)另有對其中個(gè)別問(wèn)題深入探究的進(jìn)階篇《Even Faster Web Sites》，中譯《高性能網(wǎng)站建設進(jìn)階指南》。
作者介紹上面的豆瓣鏈接中有，就不再照搬過(guò)來(lái)了。
這本書(shū)中給出了14條網(wǎng)站性能提升的原則，每個(gè)原則獨立成章，配有示例。這些原則大多數都非常實(shí)用，適合站點(diǎn)架構師、前端工程師。其中對于前端工程師的意義更大一些。
這次看的是原版。我對于Web開(kāi)發(fā)較缺乏實(shí)踐經(jīng)驗，加之看得匆忙，因此可能存在遺漏、表述不當之處，希望廣大網(wǎng)友不吝指正。
原則1 減少HTTP請求數
構造請求、等待響應需要時(shí)間，因此請求數量越少越好。減少請求的總體思路就是合并資源，減少顯示一個(gè)頁(yè)面需要的文件數。
1. Image Map
通過(guò)設置<img>標簽的usemap屬性與使用<map>標簽可以在一幅圖片上切分出多個(gè)區域，指向不同的鏈接。比起使用多幅圖片分別構造鏈接減少了請求數。
2. CSS Sprite（CSS貼圖整合/貼圖拼合/貼圖定位）
通過(guò)設置元素的background-position樣式做到。一般用于界面圖標。典型的可以參考TinyMCE編輯器上方的那些小按鈕。多個(gè)小圖實(shí)質(zhì)是從一個(gè)統一的大圖通過(guò)不同的偏移量裁剪而來(lái)，這樣加載界面上的眾多按鈕實(shí)際上只要請求一次（請求大圖一次），從而減少HTTP請求數。
3. Inline Image（內聯(lián)圖片）
在<img>的src中不指定外部圖片文件的URL，而是直接將圖片信息放入。例如src="data:image/gif;base64,R0lGODlhDAAMAL..."某些特殊情況下有用（例如一個(gè)不大的圖片僅在當前頁(yè)面用到）。
原則2 利用多線(xiàn)路CDN
為你的站點(diǎn)提供多種線(xiàn)路（例如國內電信、聯(lián)通、移動(dòng)）、多個(gè)地理位置（北方、南方、西部）的訪(fǎng)問(wèn)，使得所有用戶(hù)都能夠快速訪(fǎng)問(wèn)。
原則3 利用HTTP Cache
給不頻繁更新的資源（例如靜態(tài)圖）加較長(cháng)的Expires頭信息，這些資源一經(jīng)緩存，未來(lái)很長(cháng)時(shí)間都可以不再重復傳輸了。
原則4 使用Gzip壓縮
使用Gzip壓縮HTTP報文，減小體積，減少傳輸時(shí)間。
原則5 將樣式表置于頁(yè)面前部
先加載樣式表，這樣頁(yè)面渲染得以較早開(kāi)始，給用戶(hù)頁(yè)面加載較快的感覺(jué)。
原則6 將腳本置于頁(yè)面尾部
原因同5，先處理頁(yè)面顯示，頁(yè)面渲染較早完成，而腳本邏輯稍后執行，這樣給用戶(hù)頁(yè)面加載較快的感覺(jué)。
原則7 避免使用CSS表達式
過(guò)于復雜的JavaScript腳本邏輯、DOM查找、選擇操作將會(huì )降低頁(yè)面處理效率。
原則8 將JavaScript與CSS作為外聯(lián)資源
這似乎與原則1中的合并思想相悖，但其實(shí)不然：考慮每個(gè)頁(yè)面都引入了一個(gè)公共的JavaScript資源（例如jQuery或是ExtJS這樣的JavaScript庫），單就一個(gè)頁(yè)面的表現來(lái)看，內聯(lián)（即將JavaScript嵌入HTML）頁(yè)面將比外聯(lián)（使用<script>標簽引入）頁(yè)面加載更快（因為其較少的HTTP請求數）。但如果有很多頁(yè)面都引入了這個(gè)公共JavaScript資源，那么內聯(lián)方案會(huì )造成重復傳輸（因為這個(gè)資源內嵌在每個(gè)頁(yè)面中了，所以每次打開(kāi)一個(gè)頁(yè)面都要將這部分資源傳輸一遍，從而造成網(wǎng)絡(luò )傳輸資源的浪費）。而將這種資源獨立出來(lái)外聯(lián)引用可以解決這個(gè)問(wèn)題。
由于JavaScript和CSS相對穩定，我們可以對其對應的資源設置較長(cháng)的失效期（參考原則3）。
原則9 減少DNS查找
作者給出的建議是：
1. 使用Keep-Alive保持連接
如果連接斷開(kāi)，那么下次連接又要執行DNS查找，即使對應的域名-IP映射已被緩存，查找也是要消耗一些時(shí)間的
2. 減少域名
每次請求新域名都需要進(jìn)行通過(guò)DNS查找不同的域名，且DNS緩存無(wú)法發(fā)揮作用。因此應該盡量將站點(diǎn)組織在一個(gè)統一域名下，避免使用過(guò)多子域名
原則10 壓縮你的JavaScript
使用JS壓縮工具壓縮你的JavaScript吧，很有效哦?？纯磈Query的兩個(gè)不同的發(fā)行版本就知道區別了：
http://code.jquery.com/jquery-1.6.2.js 閱讀版jQuery代碼，230KB
http://code.jquery.com/jquery-1.6.2.min.js 壓縮版jQuery代碼（用于實(shí)際部署），89.4KB
原則11 盡量避免重定向
一次重定向意味著(zhù)在你真正訪(fǎng)問(wèn)到想要看到的頁(yè)面前加入了一輪額外的HTTP請求（客戶(hù)端發(fā)起HTTP請求→HTTP服務(wù)器返回重定向響應→客戶(hù)端對新URL發(fā)起請求→HTTP服務(wù)器返回內容，下劃線(xiàn)部分為額外的請求），因此消耗更多的時(shí)間（也就給人反應更慢的感覺(jué)）。因此除非必要，不要隨意使用重定向。幾個(gè)“必要”的情況：
1. 避免URL失效
舊站點(diǎn)遷移后，為了避免舊的URL失效，通常將對舊URL的請求重定向至新系統的對應地址。
2. URL美化
在可讀性好的URL與實(shí)際資源URL之間轉換，例如對于Google Toolbar，用戶(hù)記得住http://toolbar.google.com這個(gè)對人類(lèi)富有語(yǔ)義的地址，卻很難記住http://www.google.com/tools/firefox/toolbar/FT3/intl/en/index.html這個(gè)真正的資源地址。因此有必要保留前者，并且將對前者的請求重定向至后者。
原則12 移除重復的腳本
不要在一個(gè)頁(yè)面中重復引入相同的腳本。例如腳本B和C都依賴(lài)于A(yíng)，那么在使用了B和C的頁(yè)面中就有可能存在對A的重復引用。解決方法，對于簡(jiǎn)單的站點(diǎn)手動(dòng)檢查依賴(lài)性，消去重復引入；對于復雜的站點(diǎn)則需要構建自己的依賴(lài)管理/版本控制機制。
原則13 小心處理ETag
ETag是除Last-Modified之外的另一種HTTP Cache手段。通過(guò)hash的辦法辨識資源是否被修改。但ETag存在一些問(wèn)題，例如：
1. 不一致：不同Web服務(wù)器（Apache， IIS等）定義的ETag格式不同
2. ETag的計算是不穩定的（由于考慮過(guò)多因素），例如：
1） 相同資源在不同服務(wù)器上計算出來(lái)的ETag不一樣，而大型Web應用通常由不止一臺服務(wù)器提供服務(wù)，這就導致客戶(hù)端在服務(wù)器A緩存好的資源明明仍然有效，而在下次請求B時(shí)由于ETag不同而被認定為失效，導致相同資源的重復傳輸。
2） 資源不變，而由于一些其他因素的變化，例如配置文件更改，導致ETag變化。直接后果是系統更新后客戶(hù)端大規模發(fā)生Cache失效，導致傳輸量大增，站點(diǎn)性能下降。
作者給出的建議是：要么根據你的應用特點(diǎn)改進(jìn)已有的ETag計算方法，要么干脆就不用ETag，而改用最簡(jiǎn)單的Last-Modified。
原則14 在A(yíng)jax中利用HTTP Cache
Ajax是異步請求，異步請求不會(huì )阻塞你現在的操作，而且當請求完成時(shí)，你馬上就可以看到結果。但異步不代表能夠瞬時(shí)完成，也不代表能夠容忍它花無(wú)限多的時(shí)間完成。因此對于A(yíng)jax請求的性能也需要重視。有很多Ajax請求訪(fǎng)問(wèn)的是一些相對穩定的資源，因此別忘了對Ajax請求利用好HTTP Cache機制，具體參見(jiàn)原則3、13。
鄭州網(wǎng)站建設 | 鄭州網(wǎng)絡(luò )公司 | 鄭州網(wǎng)站制作 | 鄭州做網(wǎng)站 開(kāi)拓者科技 www.cnmcafee.cn
技術(shù)創(chuàng )造價(jià)值 服務(wù)締造品牌
Copyright ? 2011-2024 鄭州開(kāi)拓者電子科技有限公司 All Rights Reserved