【讀書報(bào)告】高性能網(wǎng)站建設(shè)指南
Start：關(guān)注本公眾號(hào)后，可直接聯(lián)系后臺(tái)獲取排版美化的詳細(xì)文檔！
Hints：本篇文章所編纂的資料均來自網(wǎng)絡(luò)，特此感謝參與奉獻(xiàn)的有關(guān)人員。
序言A：前端性能的重要性
后端優(yōu)化內(nèi)容：
編譯器選項(xiàng)、數(shù)據(jù)庫索引、內(nèi)存管理
關(guān)注前端性能優(yōu)化的重要性：
1 關(guān)注前端可以很好地提高整體性能。如果我們可以將后端響應(yīng)時(shí)間縮短一半，整體響應(yīng)時(shí)間只能減少5%~10%，而如果關(guān)注前端性能，同樣是將其響應(yīng)時(shí)間減少一般，則整體響應(yīng)時(shí)間可以減少40%~45%
2 改進(jìn)前端通常只需要較少的時(shí)間和資源。減少后端延遲會(huì)帶來很大的改動(dòng)，例如重新設(shè)計(jì)應(yīng)用程序的架構(gòu)和代碼，查找和優(yōu)化臨界代碼路徑，添加或改動(dòng)硬件，對(duì)數(shù)據(jù)庫進(jìn)行分布化等。這些改動(dòng)需要花費(fèi)數(shù)周或數(shù)月。
3前端性能調(diào)整已被證明是可行的。
性能的黃金準(zhǔn)則：
只有10%~20%的最終用戶響應(yīng)時(shí)間花在了下載HTML文檔上。其余的80%~90%時(shí)間花在了下載頁面中的所有組件上。
序言B:HTTP概述
HTTP的主要概念：
HTTP是一種客戶端-服務(wù)器協(xié)議，由請(qǐng)求和響應(yīng)構(gòu)成。
B/S架構(gòu)下，網(wǎng)站訪問的完整過程：
用戶：首次輸入網(wǎng)站網(wǎng)址URL
瀏覽器：向特定URL發(fā)送HTTP請(qǐng)求
DNS服務(wù)器：域名解析，將特定的URL解析成匹配的IP地址
服務(wù)器：發(fā)回HTTP響應(yīng)，Http響應(yīng)包含狀態(tài)碼、頭和響應(yīng)體，同時(shí)響應(yīng)文本中expires頭明確指出瀏覽器是否可以使用組件的緩存副本來消除瀏覽器和服務(wù)器之間進(jìn)行對(duì)頁面是否更新檢查的需要。
瀏覽器和服務(wù)器之間通過TCP建立持久連接.
瀏覽器：瀏覽器會(huì)解析HTML請(qǐng)求并開始下載頁面中的組件。如果瀏覽器的緩存是空的，需要下載所有的組件HTML文檔只占總響應(yīng)時(shí)間的5%。用戶需要花費(fèi)其余95%的時(shí)間中的大部分時(shí)間來等待組件的下載，小部分時(shí)間在解析HTML、腳本和樣式表。當(dāng)瀏覽器看到響應(yīng)中有一個(gè)expire頭時(shí)，就會(huì)和相應(yīng)的過期時(shí)間組件一起保存到緩存中。只要組件沒有過期，瀏覽器就會(huì)使用緩存版本而不會(huì)進(jìn)行http請(qǐng)求。
用戶：在網(wǎng)站上跳轉(zhuǎn)
瀏覽器：檢查瀏覽器的緩存，查看是否已經(jīng)存在緩存，如果緩存中的組件沒有明確說明是否有效，瀏覽器就會(huì)向特定URL發(fā)送條件get請(qǐng)求
服務(wù)器：根據(jù)條件get請(qǐng)求，查看組件，返回組件的last-modified。
瀏覽器向服務(wù)器發(fā)送的請(qǐng)求類型：
GET、POST、HEAD、PUT、delete、options、trace
Http響應(yīng)內(nèi)容：狀態(tài)碼、頭、響應(yīng)體
壓縮：
如果瀏覽器和服務(wù)器都支持的話，可以使用壓縮來減少響應(yīng)的大小。瀏覽器可以使用Accept-Encoding來聲明它支持壓縮。服務(wù)器使用Content-Encoding頭來確認(rèn)響應(yīng)已被壓縮。
條件GET請(qǐng)求：
如果瀏覽器在其緩存中保留了組件的一個(gè)副本，但不確定它是否仍然有效，就會(huì)生成一個(gè)條件GET請(qǐng)求。如果確認(rèn)緩存的副本仍然有效，瀏覽器就可以使用緩存中的副本，這會(huì)得到更小的響應(yīng)和更快的體驗(yàn)。基于響應(yīng)中的Last-Modified頭，瀏覽器可以知道組件最后的修改時(shí)間，它會(huì)使用If-Modified-since頭將最后修改時(shí)間發(fā)送給服務(wù)器。如果組件自生成日期以來沒有改變過，服務(wù)器會(huì)返回一個(gè)“304 Not Modified”狀態(tài)碼并不再發(fā)送響應(yīng)體，從而得到一個(gè)更小且更快的響應(yīng)。
Expires：
條件Get請(qǐng)求和304響應(yīng)有助于讓頁面加載的更快，但仍需要在客戶端和服務(wù)器之間進(jìn)行一次往返確認(rèn)，以執(zhí)行有效檢查。Expires頭通過明確指出瀏覽器是否可以使用組件的緩存副本來消除這個(gè)需要。
Keep-Alive:
持久連接的引入解決了多對(duì)一請(qǐng)求服務(wù)器導(dǎo)致的socket連接低效性的問題，它使瀏覽器可以在一個(gè)單獨(dú)的連接上進(jìn)行多個(gè)請(qǐng)求。瀏覽器和服務(wù)器使用connection頭來指出對(duì)Keep-Alive的支持。
第一章規(guī)則1-減少HTTP請(qǐng)求
只有10~20%的最終用戶響應(yīng)時(shí)間花在接收請(qǐng)求的html文檔上。剩下的80~90%的時(shí)間花在html文檔所引用的所有組件（圖片、腳本、樣式表、flash等）進(jìn)行的http請(qǐng)求上。因此，改善響應(yīng)時(shí)間的最簡(jiǎn)單途徑就是減少組件的數(shù)量，并由此減少HTTP請(qǐng)求的數(shù)量。
方法1:使用圖片地圖既能減少HTTP請(qǐng)求，又無需改變頁面外觀感受
實(shí)現(xiàn)效果：
未使用圖片地圖：
使用圖片地圖：
使用圖片地圖的缺陷：在定義圖片地圖上的區(qū)域坐標(biāo)復(fù)雜
方法2：使用css sprites ，將多個(gè)圖片合并到一個(gè)單獨(dú)的圖片中
方法3：內(nèi)聯(lián)圖片
1內(nèi)聯(lián)為立即數(shù)
data:URL 模式，允許將小塊數(shù)據(jù)內(nèi)聯(lián)為‘立即數(shù)’，數(shù)據(jù)就在其URL自身之中。但由于data：url是內(nèi)聯(lián)在頁面中的，在跨越不同頁面是不會(huì)被緩存。
2 內(nèi)聯(lián)在樣式表
將內(nèi)聯(lián)圖片放置在外部樣式表增加了一個(gè)額外的HTTP請(qǐng)求，但被緩存后可以得到額外的收獲。
內(nèi)聯(lián)在樣式表的優(yōu)點(diǎn)：
方法4：合并腳本和樣式表
將單獨(dú)的文件合并到一個(gè)文件中，可以減少http請(qǐng)求的數(shù)量并縮短最終用戶響應(yīng)時(shí)間。將多個(gè)腳本合并為一個(gè)腳本，多個(gè)樣式表合并為一個(gè)樣式表。理想情況下，一個(gè)頁面應(yīng)該使用不多于一個(gè)的腳本和樣式表。
頁面大小和響應(yīng)時(shí)間有著很強(qiáng)的正比關(guān)系。
減少組件的數(shù)量是最重要的一部，用文本替換圖片會(huì)給該頁面帶來性能的最大改進(jìn)。
第二章規(guī)則2：使用內(nèi)容發(fā)布網(wǎng)絡(luò)
使用內(nèi)容發(fā)布網(wǎng)絡(luò)，在多個(gè)地理位置不同的服務(wù)器上部署內(nèi)容。如果應(yīng)用程序web服務(wù)器離用戶更近，則一個(gè)http請(qǐng)求的響應(yīng)時(shí)間將縮短。如果組件web服務(wù)器離用戶更近，則多個(gè)http請(qǐng)求的響應(yīng)時(shí)間將縮短。
內(nèi)容發(fā)布網(wǎng)絡(luò)CDN是一組分布在多個(gè)不同地理位置的web服務(wù)器，用于更加有效地向用戶發(fā)布內(nèi)容。在優(yōu)化性能時(shí)，向特定用戶發(fā)布內(nèi)容的服務(wù)器的選擇基于對(duì)網(wǎng)絡(luò)可用度的測(cè)量。推薦使用CDN服務(wù)提供商。
有些需要最終用戶使用一個(gè)代理來配置他們的瀏覽器，有的需要開發(fā)者使用不同的域名；修改他們組件的url。無論如何也不要使用http重定向來將用戶指向本地服務(wù)器，這會(huì)使得web頁面響應(yīng)速度慢。 cdn 不僅縮短用戶響應(yīng)時(shí)間，還提供備份，擴(kuò)展存儲(chǔ)能力和進(jìn)行緩存。
使用CDN注意問題：
1響應(yīng)時(shí)間會(huì)受到其他網(wǎng)站影響，無法直接控制組件服務(wù)器，需要服務(wù)器提供商協(xié)助。
2 建議使用多家CDN服務(wù)器提供商。
3 CDN用于發(fā)布靜態(tài)內(nèi)容，如圖片、腳本、樣式表和flash。提供動(dòng)態(tài)html頁面會(huì)引入特殊的存儲(chǔ)需求---數(shù)據(jù)庫連接，狀態(tài)管理、驗(yàn)證、硬件和os優(yōu)化，超出CDN的能力范圍。
4 使用內(nèi)容發(fā)布網(wǎng)絡(luò)，CDN服務(wù)器的地理位置與用戶的地理位置影響性能很大。
第三章規(guī)則3：添加Expires頭
-為組件添加長(zhǎng)久的expires 頭，通過使用一個(gè)長(zhǎng)久的expires頭，使得圖片、腳本和樣式表可以被緩存，這會(huì)在后續(xù)的頁面瀏覽中避免不必要的HTTP請(qǐng)求。
-expires 頭可以用于圖片、腳本、樣式表和flash等組件。
-web服務(wù)器使用expires 頭來告訴web客戶端它可以使用一個(gè)組件的當(dāng)前副本，直到指定的時(shí)間為止。
瀏覽器利用緩存的方式：
1expires頭使用一個(gè)特定的時(shí)間，它要求服務(wù)器和客戶端的時(shí)鐘嚴(yán)格同步，而且時(shí)間一旦落后，就需要立馬更新。
2 cache-control使用max-age 指令指定組件被緩存多久
使用瀏覽器緩存注意的問題：
組件在瀏覽器中緩存，會(huì)減少響應(yīng)時(shí)間，但已經(jīng)訪問過網(wǎng)站的用戶也不大可能獲取最新的組件，因?yàn)榍耙粋€(gè)版本已經(jīng)在瀏覽器中緩存了。為了確保用戶能獲取用戶的最新版本，最有效的解決方案是修改其所有鏈接。這樣，全新的請(qǐng)求可以將從原始服務(wù)器下載最新的內(nèi)容，修改文件名即可更新。
第四章規(guī)則4:壓縮組件
-通過減少HTTP響應(yīng)的大小來減少響應(yīng)時(shí)間。如果HTTP請(qǐng)求產(chǎn)生的響應(yīng)包很小，傳輸時(shí)間就會(huì)減少。使用gzip編碼來壓縮HTTP響應(yīng)包，并由此減少網(wǎng)絡(luò)響應(yīng)時(shí)間。還可以刪除注釋和縮短URL。
-可以壓縮HTML文檔，腳本和樣式表，也可以壓縮xml和json。圖片和pdf不應(yīng)該壓縮，因?yàn)樗麄儽緛砭鸵呀?jīng)被壓縮了。
-配置gzip時(shí)使用的模塊取決于apache的版本。
gzip在apache上的配置詳見：http://www.schroepl.net/projekte/mod_gzip
-在web服務(wù)器的響應(yīng)中添加vary頭，web服務(wù)器可以告訴代理根據(jù)一個(gè)或多個(gè)請(qǐng)求頭來改變緩存的響應(yīng)。由于壓縮的決定是基于accept-encoding請(qǐng)求頭的，因此需要在服務(wù)器的-vary響應(yīng)頭包含accept-encoding。當(dāng)瀏覽器帶著accept-encoding gzip訪問代理時(shí)，接收到的死壓縮過的內(nèi)容，否則就不是壓縮過的內(nèi)容。
-代理的邊緣情形：默認(rèn)情況下，ETag不能反映出內(nèi)容是否被壓縮，因此代理可能會(huì)想瀏覽器提供錯(cuò)誤的內(nèi)容。
-對(duì)web服務(wù)器配置進(jìn)行簡(jiǎn)單的修改，壓縮盡可能多的組件，就能顯著改善頁面的反應(yīng)速度。
第五章 規(guī)則5：將樣式表放在頂部
HTML頁面就是進(jìn)度指示器，當(dāng)瀏覽器逐步加載頁面時(shí)，頁頭、導(dǎo)航欄，頂端logo等，所有這些都會(huì)等待頁面的用戶提供視覺反饋，有助于改善用戶體驗(yàn)。
進(jìn)度指示條的三個(gè)主要優(yōu)勢(shì)： 為用戶提供可視化回饋很重要。
1讓用戶知道系統(tǒng)沒有奔潰
2指出用戶大概需要多久，以便用戶能夠在漫長(zhǎng)的等待中做些其他事情
3能夠?yàn)橛脩籼峁┮恍┛梢钥吹臇|西，使得等待不再那么無聊
樣式表存放位置分析：
1 如果將樣式表放在文檔底部會(huì)導(dǎo)致瀏覽器阻止內(nèi)容逐步呈現(xiàn)，這是因?yàn)闉g覽器在繪制頁面元素時(shí)，會(huì)因?yàn)橹鸩阶x取底部的樣式表而重新繪制頁面，在頁面沒有固定時(shí)，瀏覽器會(huì)阻塞內(nèi)容逐步呈現(xiàn)，直至頁面樣式穩(wěn)定。
2 如果將樣式表放在文檔頂部，瀏覽器會(huì)逐步呈現(xiàn)頁面內(nèi)容，對(duì)于實(shí)際繪制內(nèi)容的時(shí)間沒有影響，但會(huì)給用戶較好的體驗(yàn)。
會(huì)導(dǎo)致白屏的情形：
1 在新窗口中打開
2 重新加載
3作為主頁
將樣式表放在文檔頂部的方式：
注意：一個(gè)style塊可以包含多個(gè)@import規(guī)則，但@import規(guī)則必須放在其他規(guī)則之前。使用@import規(guī)則會(huì)導(dǎo)致組件下載時(shí)的無序性，會(huì)阻塞頁面逐漸呈現(xiàn)。樣式表在頁面中的位置并不影響下載時(shí)間，但會(huì)影響頁面的呈現(xiàn)。
第六章 規(guī)則6：將腳本放在底部
使用腳本時(shí)，對(duì)于所有位于腳本以下的內(nèi)容，逐步呈現(xiàn)都被阻塞了。將腳本放在頁面越靠下的地方，意味著越多的內(nèi)容能夠逐步地呈現(xiàn)。
Http1.1規(guī)范建議瀏覽器從每個(gè)主機(jī)名并行地下載兩個(gè)組件。默認(rèn)情況下，IR和Firefox都遵守這一建議。如果一個(gè)web頁面平均地將其組件分別放在兩個(gè)主機(jī)名下，整體響應(yīng)時(shí)間可以減少大約一半。簡(jiǎn)單地使用DNS別名可以將組件分別放到多個(gè)主機(jī)名中。但增加并行下載數(shù)量并不是開銷的，過多地下載反而會(huì)降低性能。
在下載腳本時(shí)并行下載實(shí)際上是被禁用的：
原因之一：腳本document.write 會(huì)修改頁面內(nèi)容，瀏覽器會(huì)等待，以確保頁面能夠恰當(dāng)?shù)夭季?/span>
原因之二：如果并行下載多個(gè)腳本，無法保證響應(yīng)應(yīng)是按照特定順序到達(dá)瀏覽器的。
腳本對(duì)頁面的影響：
1腳本會(huì)阻塞對(duì)其后面內(nèi)容的呈現(xiàn)
2腳本會(huì)阻塞對(duì)其后面組件的下載
如果腳本使用document.write 向頁面中插入了內(nèi)容，就不能將其移動(dòng)到頁面中靠后的位置。
使用延遲腳本，defer屬性表明腳本不包含document.wirte,這樣的腳本可以移到頁面底部，不會(huì)影響頁面呈現(xiàn)。
第七章規(guī)則7：避免CSS表達(dá)式
對(duì)css表達(dá)式頻繁的求值使其得以工作，也導(dǎo)致CSS的表達(dá)式低下性能。
CSS表達(dá)式不僅僅會(huì)在頁面呈現(xiàn)和大小改變時(shí)求值，當(dāng)頁面滾動(dòng)，甚至用戶鼠標(biāo)在頁面上移過時(shí)都會(huì)進(jìn)行求值。
避免CSS表達(dá)式的方法：
1創(chuàng)建一次性表達(dá)式
2 使用事件處理器取代CSS表達(dá)式
使用事件處理器來為特定的事件提供所期望的動(dòng)態(tài)行為，避免了瀏覽器在無關(guān)事件發(fā)生時(shí)對(duì)表達(dá)式多次求值。
第八章 規(guī)則8 使用外部JavaScript和CSS
有時(shí)候，內(nèi)聯(lián)會(huì)比外部快，因?yàn)橥獠啃枰袚?dān)多個(gè)HTTP請(qǐng)求帶來的開銷。但是更多情況下，因?yàn)?/span>JavaScript和CSS文件有機(jī)會(huì)就會(huì)被瀏覽器緩存起來，包含動(dòng)態(tài)內(nèi)容的HTML文檔，通常不會(huì)被配置為可以進(jìn)行緩存的，每次請(qǐng)求這樣的HTML文檔都要下載內(nèi)聯(lián)的JavaScript和CSS，會(huì)導(dǎo)致頁面呈現(xiàn)較慢。使用外部文件提供JavaScript和CSS帶來的收益會(huì)隨著每用戶每月的頁面查看次數(shù)或每用戶每會(huì)話產(chǎn)生的頁面查看次數(shù)的增長(zhǎng)而增加。
主頁傾向于使用內(nèi)聯(lián)，內(nèi)聯(lián)JavaScript和CSS文件，頁面加載速度更快，同時(shí)，一般網(wǎng)站主頁在瀏覽器每次啟動(dòng)都會(huì)緩存，在瀏覽器結(jié)束時(shí)都會(huì)自動(dòng)清空緩存。
對(duì)于多次頁面查看中的第一次的主頁，主頁內(nèi)聯(lián)JavaScript和CSS，但又能為所有后續(xù)頁面查看提供外部文件。這可以通過主頁加載完成后動(dòng)態(tài)下載外部組件來實(shí)現(xiàn)。這能夠?qū)⑼獠课募诺綖g覽器的緩存中以便用戶接下來訪問其他頁面。
JavaScript和CSS被加載到頁面中兩次，先是內(nèi)聯(lián)，然后是外部，由于下載兩次，會(huì)出現(xiàn)雙重定義，解決方法是將組件放到IFram中。
當(dāng)用戶第一次訪問頁面時(shí)，服務(wù)器發(fā)現(xiàn)沒有cookie，于是生成一個(gè)內(nèi)聯(lián)組件的頁面。然后服務(wù)器添加javascript來在頁面加載后動(dòng)態(tài)下載外部文件—javascript、css，并設(shè)置cookie，下一次訪問頁面時(shí)，服務(wù)器看到cookie，就生成一個(gè)使用外部文件的頁面。
如果用戶重新打開瀏覽器，基于會(huì)話的cookie會(huì)消失，但組件依然會(huì)存在緩存中。這會(huì)使得頁面加載javascript和css 時(shí)出現(xiàn)，可以將cookie從基于會(huì)話的改為短期的（數(shù)小時(shí)或數(shù)天）。
第九章 規(guī)則9：減少DNS查找
使用keep-alive和較少的域名來減少DNS查找
輸入URL，DNS服務(wù)器根據(jù)域名尋找指定的IP地址。在DNS查找匹配的IP地址完成之前，瀏覽器不能從主機(jī)名那里下載到任何東西。響應(yīng)時(shí)間依賴于DNS解析器所承擔(dān)的請(qǐng)求壓力，用戶與DNS解析器之間的距離和用戶的帶寬速度。
DNS查找可以被緩存起來以提高性能，用戶請(qǐng)求了一個(gè)主機(jī)名之后，DNS信息會(huì)留在操作系統(tǒng)的DNS緩存中，以后對(duì)于該主機(jī)名的請(qǐng)求將無需進(jìn)行過多的DNS查找。
查找返回的DNS記錄包含了一個(gè)存活時(shí)間TTL，告訴客戶端可以對(duì)記錄緩存多久。
過短的TTL會(huì)使得DNS記錄很快失效，過長(zhǎng)的TTL值會(huì)使得服務(wù)器故障轉(zhuǎn)移速度降低。
微軟操作系統(tǒng)的DNS緩存由DNS client服務(wù)進(jìn)行管理。
IE瀏覽器和firefox瀏覽器都會(huì)進(jìn)行dns 緩存。
IE瀏覽器的DNS緩存由三個(gè)注冊(cè)表設(shè)置控制—DnsCacheTimeout、KeepAliveTimeout和ServerInfoTimeOut。
一個(gè)持久的TCP連接（Keep-alive）會(huì)一直使用，直到其空閑1分鐘為止。由于連接是持久的，因此無需DNS查找，另外Keep-Alive通過重用現(xiàn)有連接避免了重復(fù)的DNS查找。
確保服務(wù)器支持keep-alive，以減少用戶導(dǎo)航到網(wǎng)站時(shí)所需的DNS查找。
主機(jī)名數(shù)量包括頁面URL、圖片、腳本文件、樣式表、flash對(duì)象等的主機(jī)名。減少唯一主機(jī)名的數(shù)量可以減少DNS查找的數(shù)量，但會(huì)潛在減少頁面中并行下載的數(shù)量。由于每個(gè)主機(jī)名可以并行下載兩個(gè)組件，使用一個(gè)主機(jī)名既減少DNS查找的數(shù)量，有最大化了并行下載。
第十章規(guī)則10：精簡(jiǎn)JavaScript
對(duì)JavaScript源代碼進(jìn)行精簡(jiǎn)
JavaScript是一門解釋型語言，是構(gòu)建web頁面的首選。當(dāng)以快速原型為基準(zhǔn)開發(fā)用戶界面時(shí)，解釋語言要優(yōu)于其他語言。
從javascript代碼中移除不必要的字符以減少其大小，進(jìn)而改善加載時(shí)間。在代碼被精簡(jiǎn)之后，所有的注釋以及不必要的空白字符（空格、換行、制表符）都將被移除。
混淆也會(huì)移除注釋和空白，同時(shí)也會(huì)改寫代碼。作為改寫的一部分，函數(shù)和變量的名字將被裝換為更短的字符串，這時(shí)代碼更加精煉，也難閱讀。混淆是為了增加對(duì)代碼進(jìn)行反向工程的難度，但也提高了性能。
混淆的缺陷：
1 混淆過程本身很有可能引入錯(cuò)誤
2 混淆會(huì)改變javascript符號(hào)，因此需要對(duì)任何不能改變的符號(hào)進(jìn)行標(biāo)記，防止混淆器修改它們。
3經(jīng)過混淆的代碼很難閱讀，使得在產(chǎn)品環(huán)境中調(diào)試更加困難。
javascript的精簡(jiǎn)工具：
JSMin 和DoJoCompressor
精簡(jiǎn)css也能帶來加載性能的優(yōu)化，CSS的精簡(jiǎn)在于移除注釋和空白，合并相同的類，移除不使用的類，使用縮寫（用#606 代替‘#660066’，移除不必要的字符串（用‘0’代替‘0px’）
第十一章 規(guī)則11：避免重定向
重定向用于將用戶從一個(gè)URL重新路由到另一個(gè)URL。
進(jìn)行重定向的原因：網(wǎng)站重新設(shè)計(jì)、跟蹤流量、記錄廣告點(diǎn)擊、簡(jiǎn)歷易于記憶的URL
當(dāng)web服務(wù)器向?yàn)g覽器發(fā)送HTTP響應(yīng)頭時(shí)，瀏覽器會(huì)自動(dòng)將用戶帶到Location 字段所給出的URL。
HTML文檔中的頭包含的metarefresh標(biāo)簽可以在其content屬性所自定的秒數(shù)之后重定向用戶。
javascript也可以用于重定向，將document.location設(shè)置為期望的URL即可。
重定向會(huì)延遲整個(gè)HTML文檔的傳輸，在HTML文檔到達(dá)之前，頁面中不會(huì)呈現(xiàn)出任何東西，也沒有任何組件會(huì)被下載。
重定向最為浪費(fèi)、發(fā)生得很頻繁的是，URL的結(jié)尾必須出現(xiàn)斜線（/）而沒有出現(xiàn)時(shí)。
例如：訪問http：//astrology.yahoo.com/astrology,允許自動(dòng)索引，并且能夠獲得與當(dāng)前目錄相關(guān)的URL。這是因?yàn)闉g覽器在進(jìn)行GET請(qǐng)求時(shí)必須指定一些路徑，如果沒有路徑，就會(huì)簡(jiǎn)單地使用文檔根（/）,發(fā)生重定向。
與其讓用戶受額外HTTP請(qǐng)求，最好還是使用Alias, mod_rewrite,DirectorySlash和直接連接代碼來避免重定向
第十二章規(guī)則12：移除重復(fù)腳本
確保腳本只被包含1次
重復(fù)腳本損傷性能的方式：1 不必要的HTTP請(qǐng)求 2執(zhí)行javascript所浪費(fèi)的時(shí)間
在頁面中多次包含相同的腳本會(huì)使頁面變慢
在IE中，如果腳本沒有被緩存，或在重新加載頁面時(shí)，會(huì)產(chǎn)生額外的HTTP請(qǐng)求
在Firefox和IE中，腳本會(huì)被多次求值。
避免重復(fù)腳本的方法：
1在HTML 頁面中使用SCRIPT 標(biāo)簽
2在PHP創(chuàng)建insertScript函數(shù)
第十三章規(guī)則13：配置ETag
配置或移除Etag，從Etag中移除changenumber或完全移除ETag可以避免當(dāng)數(shù)據(jù)已經(jīng)位于瀏覽器緩存中時(shí)進(jìn)行不必要的和低效的下載
通過最大化瀏覽器緩存組件的能力，減少呈現(xiàn)頁面時(shí)所必需的HTTP請(qǐng)求的數(shù)量能加速用戶體驗(yàn)。可以通過最大化瀏覽器緩存組件的能力來實(shí)現(xiàn)這一目標(biāo)。
Etag實(shí)體標(biāo)簽是web服務(wù)器和瀏覽器用于確認(rèn)緩存組件的有效性的一種機(jī)制。
瀏覽器： ----URL HTTP 請(qǐng)求 --DNS域名解析 ---服務(wù)器
瀏覽器 首次下載組件，存儲(chǔ)到緩存中
瀏覽器再次訪問組件，發(fā)送一個(gè)條件GET請(qǐng)求，服務(wù)器發(fā)來組件的Expires 頭，瀏覽器檢查組件是否過期，沒有過期，不產(chǎn)生HTTP請(qǐng)求，已經(jīng)過期，產(chǎn)生HTTP請(qǐng)求
服務(wù)器在檢測(cè)緩存的組件是否和原始服務(wù)器的組件匹配時(shí)，有兩種方式
1 比較最新修改日期
2 比較實(shí)體標(biāo)簽
ETAG 的加入為驗(yàn)證實(shí)體提供了比最新修改日期更為靈活的機(jī)制。例如，如果實(shí)體依據(jù)user-agent 或accept-language 頭而改變，實(shí)體的狀態(tài)可以反映在Etag中。
Etag的缺陷：
當(dāng)瀏覽器從一臺(tái)服務(wù)器上獲取了原始組件，之后，又向另外一臺(tái)不同服務(wù)器發(fā)起條件GET請(qǐng)求時(shí)，ETAG是不會(huì)匹配的、對(duì)于擁有多臺(tái)服務(wù)器的網(wǎng)站，Apache和IIS向ETAG中嵌入的數(shù)據(jù)都會(huì)大大地降低有效性驗(yàn)證的成功率。如果在多臺(tái)服務(wù)器上寄宿網(wǎng)站，而且使用的是具有默認(rèn)Etag配置的Apache或IIS，用戶將面對(duì)緩慢的頁面，服務(wù)器會(huì)有很高的負(fù)載，消耗大量的帶寬，代理不能有效地緩存緩存內(nèi)容。Apache 可以從Etag中移除inode值，只留下大小和時(shí)間戳作為組件的Etag。IIS中可以為所有服務(wù)器設(shè)置相同的ChangeNumber，保留文件的時(shí)間戳作為ETag。這樣會(huì)提高多臺(tái)服務(wù)器同一個(gè)組件匹配Etag的成功率。從Etag中移除changeNumber或完全移除Etag可以避免當(dāng)數(shù)據(jù)已經(jīng)位于瀏覽器緩存中進(jìn)行不必要的和低效的下載。
第十四章規(guī)則14：使Ajax可緩存
確保Ajax請(qǐng)求遵守性能知道，尤其應(yīng)具有長(zhǎng)的expires頭
ajax 是DHTML中使用的一項(xiàng)技術(shù)，客戶端可以獲取和顯示用戶請(qǐng)求的新信息而無需重新加載頁面。
Ajax 層位于客戶端，與web服務(wù)器進(jìn)行交互以獲取請(qǐng)求的信息，并與表現(xiàn)層交互，僅更新那些必要的組件。
盡管ajax請(qǐng)求不是可緩存的，其他性能指導(dǎo)原則都可以運(yùn)用，如壓縮響應(yīng)，縮短域名查找時(shí)間，精簡(jiǎn)腳本，不使用重定向，移除ETag。
第十五章析構(gòu)十大網(wǎng)站
響應(yīng)時(shí)間的測(cè)量使用的是Gomez的Web監(jiān)視服務(wù)(http://www.gomez.com).這里的響應(yīng)時(shí)間被定義為從請(qǐng)求初始化完畢到頁面的onload事件被觸發(fā)所經(jīng)過的事件。
使用Firebug(http://www.getfirebug.com)分析各個(gè)頁面中的JavaScript和CSS。它最強(qiáng)大的功能是能夠調(diào)試JavaScript代碼，不過這只是其中的一小部分功能。Firebug還提供了檢查DOM，調(diào)整CSS、執(zhí)行JavaScript和瀏覽頁面HTML等功能。
用于分析頁面性能的主要工具是YSlow(http://developer.yahoo.com/yslow).YSlow通過遍歷頁面的DOM找到頁面中的所有組件，使用XMLHttpRequest找到每個(gè)組件的響應(yīng)時(shí)間及HTTP響應(yīng)頭。這些信息，以及通過解析頁面的HTML手機(jī)的其他信息一起用于針對(duì)每個(gè)規(guī)則進(jìn)行評(píng)分。YSlow還提供了其他工具，包括頁面組件的匯總和使用JSLint(http://jslint.com)對(duì)頁面中所有JavaScript進(jìn)行的分析。
總結(jié)
根據(jù)黃金性能準(zhǔn)則，終端用戶等響應(yīng)時(shí)間更多花費(fèi)在組件的解析以及下載上，如何減少組件的下載就成為優(yōu)化網(wǎng)站性能的關(guān)鍵。
1減少HTTP請(qǐng)求數(shù)量：
1.1是減少組件的HTTP請(qǐng)求，可以同多個(gè)組件綁定一個(gè)URL
1. 2避免多次重定向，其本質(zhì)也是下降HTTP請(qǐng)求
2縮短HTTP的傳輸距離
利用CDN優(yōu)化
3精簡(jiǎn)HTTP的傳輸內(nèi)容
3.1壓縮組件
3.2壓縮javascript
3.3壓縮CSS
3.4避免重復(fù)使用腳本
4延長(zhǎng)HTTP的有效期（即使得組件有效期延長(zhǎng)）
4.1 expires 頭延長(zhǎng)組件有效期
4.2配置或移除ETag 使得組件有效識(shí)別成功率提高
5改善用戶體驗(yàn)
5.1樣式表放置在頂部
5.2腳本放置在底部
6減少網(wǎng)站內(nèi)容的運(yùn)算時(shí)間
6.1 減少CSS運(yùn)算
6.2 減少javascript進(jìn)行復(fù)雜操作
7使得B與S之間的連接更快
7.1使用較少域名，減少DNS查找
7.2使用keep-alive，使得DNS有效期延長(zhǎng)，減少DNS
公眾號(hào)二維碼
End：如果有興趣了解金融量化交易和其他數(shù)據(jù)分析的實(shí)用技術(shù)，歡迎關(guān)注本公眾號(hào)