如何提高網站的負載性能？網站建設公司根據自己的親身經歷總結了以下幾個方面，希望能給新手站長一些幫助。

1.減少HTTP請求的數量

構造請求和等待響應需要時間，所以請求越少越好。請求縮減的總體思路是組合資源，減少顯示一個頁面所需的文件數量。

1).圖像映射

通過設置標簽的usemap屬性并使用標簽，可以剪切圖片中的多個區域并指向不同的鏈接。與使用多個圖像分別建立鏈接相比，減少了請求的數量。

2).CSS Sprite(CSS貼圖集成/貼圖展平/貼圖定位)

這是通過設置元素的背景位置樣式實現的。對于一般界面圖標。通常，您可以參考TinyMCE編輯器頂部的那些小按鈕。本質上是多個縮略圖被一個統一的縮略圖切割成不同的偏移量，這樣加載界面上的很多按鈕實際上只需要請求一次(請求縮略圖一次)，從而減少了HTTP請求的次數。

3).嵌入圖像(嵌入圖像)

您沒有在src中指定外部圖像文件的URL，而是將圖像信息直接放入。比如src=' data:image/gif；Base64，R0lGODlhDAAMAL .在一些特殊情況下是有用的(比如一個小圖片只在當前頁面使用)。

2.使用多線CDN

為您的站點提供多條線路(如國內電信、聯通、移動)和多個地理位置(北、南、西)的接入，讓所有用戶都能快速訪問。

3.使用HTTP緩存

向不經常更新的資源(如靜態圖)添加較長的過期標題信息。這些資源一旦緩存，在未來很長一段時間內都不會重復傳輸。

4.使用Gzip壓縮

使用Gzip壓縮HTTP消息可以減少大小和傳輸時間。

　5.將樣式表放在頁面的前面

先加載樣式表，這樣頁面渲染可以更早開始，給用戶一種頁面加載更快的感覺。

6.將腳本放在頁面的末尾

同樣，頁面顯示要先處理，頁面渲染要早完成，腳本邏輯要晚執行，給用戶頁面加載更快的感覺。

7.避免CSS表達式

過于復雜的JavaScript腳本邏輯、DOM搜索和選擇操作會降低頁面處理的效率。

8.使用JavaScript和CSS作為拓展資源

這似乎違背了原則1中的合并思想，其實不然：考慮到每個頁面都引入了一個通用的JavaScript資源(比如jQuery或ExtJS之類的JavaScript庫)。單就頁面性能而言，內聯(即將JavaScript嵌入HTML)頁面比外部(用標簽導入)頁面加載更快(因為它的HTTP請求更少)。但是如果很多頁面都引入了這種常見的JavaScript資源，內聯方案就會造成重復傳輸(由于這種資源是嵌入在每個頁面中的，所以每打開一個頁面就要傳輸一次，造成網絡傳輸資源的浪費)。這個問題可以通過獨立利用這些資源來解決。

因為JavaScript和CSS相對穩定，所以我們可以為它們對應的資源設置更長的有效期(參考原則3)。

9.減少DNS查找

作者的建議是：

1).使用Keep-Alive保持聯系。

如果連接斷開，下一次將執行DNS查找，即使相應的域名-IP映射已被緩存，查找也需要一些時間。

2).減少域名

每次請求新域名，都需要通過DNS搜索不同的域名，DNS緩存無法工作。所以盡量在一個統一的域名下組織站點，避免使用過多的子域。

10.壓縮你的JavaScript

使用JS壓縮工具來壓縮您的JavaScript。非常有效。看看jQuery的兩個不同發行版，看看它們的區別：

jQuery代碼的Http://code.jquery.com/jquery-1.6.2.js版本，230KB。

Http://code.jquery.com/jquery-1.6.2.min.js壓縮jQuery代碼(用于實際部署)，89.4KB

11.盡量避免重定向

重定向是指在你實際訪問你想看的頁面之前，增加一輪額外的HTTP請求(客戶端發起HTTP請求HTTP服務器返回重定向響應客戶端發起請求新的URLHTTP服務器返回內容，下劃線部分是額外的請求)，所以需要更多的時間(給人的感覺是響應很慢)。所以除非必要，否則不要使用重定向。幾種“必要”情況：

1).避免無效的URL。

舊站點遷移后，為了避免舊URL失效，通常會將對舊URL的請求重定向到新系統的相應地址。

2) URL美化

在可讀URL和實際資源URL之間轉換。比如Google Toolbar，用戶記住了http://www.google.com這個對人類有意義的地址，卻很難記住http://www . Google . com/tools/Firefox/Toolbar/FT3/intl/en/index . html這個真實的資源地址。所以保留前者，把對前者的請求重定向到后者。

12.刪除重復的腳本

不要在一個頁面中重復介紹同一個腳本。例如，如果腳本B和C都依賴于A，那么在使用B和C的頁面中可能會出現對A的重復引用，解決方案：對于簡單的站點，手動檢查依賴關系，消除重復介紹；對于復雜的站點，需要建立自己的依賴管理/版本控制機制。

13.小心處理電子標簽　

ETag是除Last-Modified之外的另一種HTTP緩存方法。確定資源是否已經過哈希處理。但是ETag也有一些問題，比如：

1).不一致：不同的Web服務器(Apache、IIS等。)定義不同的ETag格式。

2).etag的計算是不穩定的(由于太多因素)，例如：

1)同一資源在不同服務器上計算的etag不同。大型Web應用通常由多臺服務器提供服務，這樣客戶端在服務器A緩存的資源顯然仍然有效，但在下一次請求B時會因為etag的不同而被視為無效，導致同一資源的重復傳輸。

2)資源保持不變，但是ETag由于一些其他因素而改變，例如配置文件改變。直接結果就是系統更新后，客戶端緩存大規模失效，導致傳輸量大增，站點性能下降。

筆者的建議是：要么根據你的應用特點改進現有的ETag的計算方法，要么干脆用最簡單的Last-Modified代替ETag。

14.在Ajax中使用HTTP緩存　

Ajax是一種異步請求。不會阻礙你現在的操作。當請求完成時，您可以立即看到結果。但是，異步并不意味著可以立即完成，也不意味著需要無限的時間才能完成。所以要注意Ajax請求的性能。很多Ajax請求訪問的都是相對穩定的資源，所以不要忘了利用好Ajax請求的HTTP緩存機制。詳見原則3和原則13。

我們專注高端建站，小程序開發、軟件系統定制開發、BUG修復、物聯網開發、各類API接口對接開發等。十余年開發經驗，每一個項目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！