今日大致閱讀了一下《High Performance Web Sites》。本書的中文版是《高性能網(wǎng)站建立指南》。

本書另有對其中個別問題深化探求的進(jìn)階篇《Even Faster Web Sites》，中譯《高性能網(wǎng)站建立進(jìn)階指南》。

作者引見上面的豆瓣鏈接中有，就不再照搬過來了。

這本書中給出了14條網(wǎng)站性能提升的準(zhǔn)繩，每個準(zhǔn)繩獨(dú)立成章，配有示例。這些準(zhǔn)繩大多數(shù)都十分適用，合適站點(diǎn)架構(gòu)師、前端工程師。其中關(guān)于前端工程師的意義更大一些。

這次看的是原版。我關(guān)于Web開發(fā)較缺乏理論經(jīng)歷，加之看得匆忙，因而可能存在遺漏、表述不當(dāng)之處，希望廣闊網(wǎng)友不吝指正。

準(zhǔn)繩1 減少HTTP懇求數(shù)

結(jié)構(gòu)懇求、等候響應(yīng)需求時間，因而懇求數(shù)量越少越好。減少懇求的總體思緒就是兼并資源，減少顯現(xiàn)一個頁面需求的文件數(shù)。

1. Image Map

經(jīng)過設(shè)置標(biāo)簽的usemap屬性與運(yùn)用

2. CSS Sprite（CSS貼圖整合/貼圖拼合/貼圖定位）

經(jīng)過設(shè)置元素的background-position款式做到。普通用于界面圖標(biāo)。典型的能夠參考TinyMCE編輯器上方的那些小按鈕。多個小圖本質(zhì)是從一個統(tǒng)一的大圖經(jīng)過不同的偏移量裁剪而來，這樣加載界面上的眾多按鈕實踐上只需懇求一次（懇求大圖一次），從而減少HTTP懇求數(shù)。

3. Inline Image（內(nèi)聯(lián)圖片）

在的src中不指定外部圖片文件的URL，而是直接將圖片信息放入。例如src=\"data:image/gif;base64,R0lGODlhDAAMAL...\"某些特殊狀況下有用（例如一個不大的圖片僅在當(dāng)前頁面用到）。

準(zhǔn)繩2 應(yīng)用多線路CDN

為你的站點(diǎn)提供多種線路（例如國內(nèi)電信、聯(lián)通、挪動）、多個天文位置（北方、南方、西部）的訪問，使得一切用戶都可以快速訪問。

準(zhǔn)繩3 應(yīng)用HTTP Cache

給不頻繁更新的資源（例如靜態(tài)圖）加較長的Expires頭信息，這些資源一經(jīng)緩存，將來很長時間都能夠不再反復(fù)傳輸了。

準(zhǔn)繩4 運(yùn)用Gzip緊縮

運(yùn)用Gzip緊縮HTTP報文，減小體積，減少傳輸時間。

準(zhǔn)繩5 將款式表置于頁面前部

先加載款式表，這樣頁面渲染得以較早開端，給用戶頁面加載較快的覺得。

準(zhǔn)繩6 將腳本置于頁面尾部

緣由同5，先處置頁面顯現(xiàn)，頁面渲染較早完成，而腳本邏輯稍后執(zhí)行，這樣給用戶頁面加載較快的覺得。

準(zhǔn)繩7 防止運(yùn)用CSS表達(dá)式

過于復(fù)雜的JavaScript腳本邏輯、DOM查找、選擇操作將會降低頁面處置效率。

準(zhǔn)繩8 將JavaScript與CSS作為外聯(lián)資源

這似乎與準(zhǔn)繩1中的兼并思想相悖，但其實不然：思索每個頁面都引入了一個公共的JavaScript資源（例如jQuery或是ExtJS這樣的JavaScript庫），單就一個頁面的表現(xiàn)來看，內(nèi)聯(lián)（行將JavaScript嵌入HTML）頁面將比外聯(lián)（運(yùn)用 標(biāo)簽引入）頁面加載更快（由于其較少的HTTP懇求數(shù)）。但假如有很多頁面都引入了這個公共JavaScript資源，那么內(nèi)聯(lián)計劃會形成反復(fù)傳輸（由于這個資源內(nèi)嵌在每個頁面中了，所以每次翻開一個頁面都要將這局部資源傳輸一遍，從而形成網(wǎng)絡(luò)傳輸資源的糜費(fèi)）。而將這種資源獨(dú)立出來外聯(lián)援用能夠處理這個問題。

由于JavaScript和CSS相對穩(wěn)定，我們能夠?qū)ζ鋵?yīng)的資源設(shè)置較長的失效期（參考準(zhǔn)繩3）。

準(zhǔn)繩9 減少DNS查找

作者給出的倡議是：

1. 運(yùn)用Keep-Alive堅持銜接

假如銜接斷開，那么下次銜接又要執(zhí)行DNS查找，即便對應(yīng)的域名-IP映射已被緩存，查找也是要耗費(fèi)一些時間的

2. 減少域名

每次懇求新域名都需求停止經(jīng)過DNS查找不同的域名，且DNS緩存無法發(fā)揮作用。因而應(yīng)該盡量將站點(diǎn)組織在一個統(tǒng)一域名下，防止運(yùn)用過多子域名

準(zhǔn)繩10 緊縮你的JavaScript

運(yùn)用JS緊縮工具緊縮你的JavaScript吧，很有效哦。看看jQuery的兩個不同的發(fā)行版本就曉得區(qū)別了：

http://code.jquery.com/jquery-1.6.2.js 閱讀版jQuery代碼，230KB

http://code.jquery.com/jquery-1.6.2.min.js 緊縮版jQuery代碼（用于實踐部署），89.4KB

準(zhǔn)繩11 盡量防止重定向

一次重定向意味著在你真正訪問到想要看到的頁面前參加了一輪額外的HTTP懇求（客戶端發(fā)起HTTP懇求→HTTP效勞器返回重定向響應(yīng)→客戶端對新URL發(fā)起懇求→HTTP效勞器返回內(nèi)容，下劃線局部為額外的懇求），因而耗費(fèi)更多的時間（也就給人反響更慢的覺得）。因而除非必要，不要隨意運(yùn)用重定向。幾個“必要”的狀況：

1. 防止URL失效

舊站點(diǎn)遷移后，為了防止舊的URL失效，通常將對舊URL的懇求重定向至新系統(tǒng)的對應(yīng)地址。

2. URL美化

在可讀性好的URL與實踐資源URL之間轉(zhuǎn)換，例如關(guān)于Google Toolbar，用戶記得住http://toolbar.google.com這個對人類富有語義的地址，卻很難記住http://www.google.com/tools/firefox/toolbar/FT3/intl/en/index.html這個真正的資源地址。因而有必要保存前者，并且將對前者的懇求重定向至后者。

準(zhǔn)繩12 移除反復(fù)的腳本

不要在一個頁面中反復(fù)引入相同的腳本。例如腳本B和C都依賴于A，那么在運(yùn)用了B和C的頁面中就有可能存在對A的反復(fù)援用。處理辦法，關(guān)于簡單的站點(diǎn)手動檢查依賴性，消去反復(fù)引入；關(guān)于復(fù)雜的站點(diǎn)則需求構(gòu)建本人的依賴管理/版本控制機(jī)制。

準(zhǔn)繩13 當(dāng)心處置ETag

ETag是除Last-Modified之外的另一種HTTP Cache手腕。經(jīng)過hash的方法辨識資源能否被修正。但ETag存在一些問題，例如：

1. 不分歧：不同Web效勞器（Apache， IIS等）定義的ETag格式不同

2. ETag的計算是不穩(wěn)定的（由于思索過多要素），例如：

1） 相同資源在不同效勞器上計算出來的ETag不一樣，而大型Web應(yīng)用通常由不止一臺效勞器提供效勞，這就招致客戶端在效勞器A緩存好的資源明明依然有效，而在下次懇求B時由于ETag不同而被認(rèn)定為失效，招致相同資源的反復(fù)傳輸。

2） 資源不變，而由于一些其他要素的變化，例如配置文件更改，招致ETag變化。直接結(jié)果是系統(tǒng)更新后客戶端大范圍發(fā)作Cache失效，招致傳輸量大增，站點(diǎn)性能降落。

作者給出的倡議是：要么依據(jù)你的應(yīng)用特性改良已有的ETag計算辦法，要么痛快就不用ETag，而改用最簡單的Last-Modified。

準(zhǔn)繩14 在Ajax中應(yīng)用HTTP Cache

Ajax是異步懇求，異步懇求不會阻塞你如今的操作，而且當(dāng)懇求完成時，你馬上就能夠看到結(jié)果。但異步不代表可以瞬時完成，也不代表可以容忍它花無限多的時間完成。因而關(guān)于Ajax懇求的性能也需求注重。有很多Ajax懇求訪問的是一些相對穩(wěn)定的資源，因而別忘了對Ajax懇求應(yīng)用好HTTP Cache機(jī)制，詳細(xì)參見準(zhǔn)繩3、13。