高性能網站建設

 

壓縮

瀏覽器使用Accept-Encoding頭來生命它支持壓縮。

服務器使用content-Encoding頭確認響應已被壓縮。

持久鏈接

request:      Connection:keep-alive

response:    Connection:keep-alive

 

圖片優化

1.使用圖片地圖，將多個圖片整合到一張圖片上   <map>

2.CSS Sprites   多張圖片合併爲一張，使用時，經過位置制定

合併後大小比單個圖片總和還小，而且減小http請求

3.內聯圖片 data：URL

 

添加 Expires頭

瀏覽器使用緩存來減小HTTP請求的數量，並減小HTTP響應的大小，使Wweb頁面加載的更快。

Web服務器使用Expires頭來告訴Web客戶端它可使用一個組件的當前副本，直到指定的時間爲止。

HTTP規範中簡要地稱該頭爲「在這一日期/時間以後，響應將被認爲是無效的」。

Expires：Thu, 15 Apr 2010 20:00:00 GMT

弱點：

Expires頭使用一個特定的時間，它要求服務器和客戶端的時鐘嚴格同步。

另外，過時日期須要常常檢查，而且一旦將來這一天到來了，還須要在服務器配置中提供一個新的日期。

 

帶有max-age的Cache-Control

使用帶有max-age的Cache-Control 能夠消除Expires的限制

mod_expires Apache模塊使你在使用Expires頭時能像max-age那樣以相對的方式設置日期。

這經過Expires-Default指令來完成

 

Last-Modified   /    If-Modified-Since

若是一個組件沒有一個長久的Expires頭，瀏覽器仍會緩存住，在後續請求中，瀏覽器會檢查緩存並發現組件已過時。

爲了提升效率，瀏覽器會像原始服務器發送一個GET請求。

若是組件沒有改變，原始服務器能夠免於發送整個數據，而是發送一個很小的頭(304),告訴瀏覽器可使用其緩存的組件。

Last-Modified      : 服務器發送給客戶端最後的修改時間

If-Modified-Since : 客戶端記錄的服務器最後修改時間

 

注意：

經過修訂文件名的方式，排除在從新發布項目時，瀏覽器使用緩存中的數據，再也不獲取最新文件，一般將項目版本號追加到文件名上。

 

壓縮組件

經過減少HTTP響應的大小來減小響應時間。

若是HTTP請求產生的響應包很小，傳輸時間就會減少，由於只需將很小的包從服務器傳遞到客戶端。

使用gzip編碼來壓縮HTTP響應包，並由此減少網絡響應時間。

這是減少頁面大小的最簡單的技術。

 

從HTTP 1.1 開始，Web客戶端能夠經過HTTP請求中的 Accept-Encoding 頭來標識對壓縮的支持。

Accept-Encoding : gzip, deflate

若是Web服務器看到請求中有這個頭，就會使用客戶端列出的方法中的一種來壓縮響應。

Web服務器經過響應中的Content-Encoding頭來同志客戶端。

Conten-Encoding : gzip

壓縮什麼：

html，script，css，XML，JSON....

image 和 pdf 不該該被壓縮，由於他們已經被壓縮了，再壓縮只會浪費CPU資源。

根據經驗一般對大於1KB或2KB的文件進行壓縮。

mod_gzip_minimum_file_size指令控制但願壓縮的文件的最小值，默認是500B。

 

 

將樣式標放在頂部

爲避免白屏，請將樣式表放在文檔頂部的HEAD中。

通過這樣修改後的示例網站稱做 " CSS at tht Top ",解決了全部錯誤的狀況。

 

樣式表在頁面中的位置並不影響下載時間，可是會影響頁面的呈現。

若是樣式表仍在加載，構建呈現樹就是一種浪費，由於在全部樣式表加載並解析完畢以前無需繪製任何東西。不然，在其準備好以前顯示內容會遇到 「無樣式內容的閃爍」 問題。

 

將腳本放在底部

最好將腳本從頁面的頂部移至底部。

這樣頁面便可以逐步呈現，也能夠提升下載的並行度。

對於位與腳本如下的文檔內容，逐步呈現都被堵塞了。

將腳本放在頁面越靠下的地方，覺得着越多的內容可以逐步呈現。

 

並行下載：

HTTP 1.1 規範建議瀏覽器從每一個主機名並行地下載兩個組件。

不少Web頁面須要從一個主機名下載全部的組件。

使用DNS別名將組件分放到多個主機中。

建議使用連個主機名，效率最佳。

 

腳本阻塞下載：

並行下載組件的優勢是很明顯的，但在下載腳本時並行下載其實是禁用的，即便使用了不一樣的主機名，瀏覽器也不會啓動其餘下載的。（不只僅阻塞script，其餘下載也會阻塞）

腳本阻塞下載的緣由主要是爲了保證腳本的加載順序。

• 腳本會阻塞對其後面內容的呈現
• 簡本會阻塞對其後面組件的下載

 

動態內聯 javascript / css

使用cookies作指示器，若是cookies不存在，就內聯javascript和css，頁面加載完成後，在load事件中動態加載外部javascript和css文件（加載到隱藏的iframe中，實現緩存外部文件，且不影響當前頁面）。

當用戶第一次訪問頁面時，服務器發現沒有cookie，因而生成了一個內聯組件的頁面。

而後服務器添加javascript來在頁面加載後動態下載外部文件(並設置cookie).

 

減小DNS查找

精簡javascript

精簡

混淆

 

避免重定向

 

301 重定向，重定向地址在response頭信息的Location中，表明永久轉移。

302 重定向，重定向地址在response頭信息的Location中，表明暫時轉移（已過期）。

303 重定向，對於302的補充，必須使用GET請求獲取新位置的資源。

307 重定向，對於302的補充，後續請求資源的方法是使用與當前交互相同的方法而不是所有使用GET。

304 Not Modified，通知瀏覽器能夠直接使用緩存中的副本。

 

ETag

集羣環境下有問題

配置或移除

 

使ajax可緩存

 

 

 

 

對於圖片的處理

1.圖片地圖，css sprites，內聯圖片

2.使用緩存

3.制定圖片的原始大小，不要放大圖片，縮小圖片

4.照片使用JPEG，動畫使用GIF，其餘使用PNG，並儘可能使用PNG8

5.圖片lazzy 加載

 

 

建立快速響應的Web應用

腳本的耗時開銷很低，而處理CSS是最大的開銷。理解DOM的奧祕並減小它的影響比試圖給腳本提速效果更好。

用戶操做時，瀏覽器使用單線程從隊列中取出事件，而後對事件自己進行處理或執行javascript。

 

怎樣纔算夠快

用戶直接操做UI中對象的感受極限爲 0.1秒。

若是沒法在0.1秒內完成，那麼必須在1秒內完成，在0.2到1秒的處理時間內，用戶會感到計算機正在處理中。

超過1秒的延時要提示用戶計算機正在解決這個個問題，如光標的形狀改變。

超過10秒的任何操做都須要一個百分比完成指示器，以及一個方便用戶中斷操做且有清晰標識的方法。

使用Firebug插件，分析javascript代碼性能。

 

定時器

使用定時器模擬多線程應用，簡單的將運行時間很長的計算拆成獨立的區塊。

 

內存優化

使用delete關鍵字從內存中移除再也不須要的javascript對象。

從網頁的DOM樹上移除再也不是必須的節點。

 

Comet

低延時數據傳輸技術，它們是comet的基礎：輪詢、長輪詢、永久幀、XHR流、WebSocket。

1.輪詢

簡單輪詢，即網站或應用每x毫秒發出一個請求來檢查是否有更新要呈現到用戶界面上。

eg：settimeout

在服務器按已知間隔時間生成信息的狀況下，輪詢是可行的

簡單輪詢是效率最低但最簡單的comet技術。

 

2.長輪詢

瀏覽器發送一個請求到服務端，而服務端只在有可用的新數據的狀況下才響應。

在支持長輪詢，服務端要徹底保持一個全部未響應請求和它們對應鏈接的大集合。

服務端經過返回 Transfer-Encoding: chunked 或 Connection:close 響應來保持這些請求鏈接。

即經過XHR創建與服務器的鏈接，在服務端數據發生改變的時候，經過XHR通知瀏覽器，此時再發送請求數據的鏈接。

客戶端會與服務器創建一個持久的鏈接，直到服務器端有數據發送過來，服務器端斷開，客戶端處理完推送的數據，會再次發起一個持久的鏈接，循環往復。

3.永久幀

4.XHR流

IE7如下瀏覽器不支持

http://www.cnblogs.com/hoojo/p/longPolling_comet_jquery_iframe_ajax.html

 

 

簡化CSS選擇符

 CSS選擇符是從右到左進行匹配。

 儘可能避免使用通配規則

不要限定ID選擇符

不要用具體的標籤限定類選擇符，而是根據實際狀況對類名進行擴展

對於子選擇符和後代選擇符儘量用具體的類來表示

瀏覽器的重排必須再次匹配全部的css選擇符