用YSlow分析和優化頁面的方法第1/2頁

2019-11-02 17:01:30

字體：大中小

來源：轉載

供稿：網友

仔細研究了下YSlow跌評分規則。

主要有12條：

1. Make fewer HTTP requests 盡可能少的http請求。。我們有141個請求（其中15個JS請求，3個CSS請求，47個CSS background images請求），多的可怕。思考了下，為什么把這個三種請求過多列為對頁面加載的重要不利因素呢，而過多的IMG請求并沒有列為不利因素呢？

發現原來這些請求都是可以避免的。

15個JS和3個CSS完全可以通過特殊的辦法進行合并（這個技術部已經幫我們解決了，實在是太感謝了，嘿嘿。），這樣合并以后，一般情況下頁面上只會出現一個JS和一個CSS（對JS的封裝得有一定的要求）。

但是47個CSS background images請求改怎么解決呢？為什么頁面上的純IMG請求時合理的，而CSS background images請求過多就是不利因素了呢。這個我想了很久，總算明白，原來是這樣的：

一般頁面上的ICON，欄目背景啊，圖片按鈕啊，我們都會用圖片CSS背景來實現，而一般這個圖片CSS背景用到的圖片都是比較小的，所以完全可以把這些圖片合并成一個相對比較大的圖片，這樣頁面上只會出現一個CSS background images請求，最多也就2-3個。后來仔細看了下雅虎美國的頁面，他們的確也是這樣做的，雖然這樣做需要花一定的時間來有規則的合并這些ICON，欄目背景，圖片按鈕，以方便CSS調用，但是這樣做絕對是合算的，而且是有必要的，YSlow也是極力推薦的。

2.Use a CDN 這項我們的評分是F級，最低。說實在的，我剛開始什么是CDN都不知道。后來查了GOODLE才知道。CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是通過在現有的Internet中增加一層新的網絡架構，將網站的內容發布到最接近用戶的網絡”邊緣”，使用戶可以就近取得所需的內容，解決Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。從技術上全面解決由于網絡帶寬小、用戶訪問量大、網點分布不均等原因所造成的用戶訪問網站響應速度慢的問題。

看來上述的解釋后，基本上明白了CDN是怎么回事，后來咨詢了下中文站點SA，得知我們網站目前的確還沒有做CDN的優化，但是據說我們有更加先進的技術來解決類似的問題（具體什么技術那就保密了），但是畢竟CDN也是個相當不錯的技術，所以在我們先進技術的基礎上在做CDN優化，肯定比現在更好，嘿嘿。據說SA明年會做幾個點的CND。

3. Add an Expires header 設置過期的HTTP Header.設置Expires Header可以將腳本, 樣式表, 圖片, Flash等緩存在瀏覽器的Cache中.

其實我們網站也做了這個優化，至少圖片在這個上做過優化，但是沒有做完全。我們的CSS和JS都還沒有做過優化，倒是外部引入的一個廣告JS做了，呵呵。其實設置過期的HTTP Header 更應該做在腳本, 樣式表, Flash上.不過據說這個SA也是沒有做的，但是有一定的風險，因為JS和CSS是有一定的邏輯，如果服務器端和客戶端都存在緩存的話，萬一出了什么問題，對我們以后查找問題的所在和增加難度，不過我想兩者中是可以權衡和并存的。

4. Gzip components 對我們的頁面內容進行Gzip格式的壓縮，Gzip格式是一種很普遍的壓縮技術，幾乎所有的瀏覽器都有解壓Gzip格式的能力，而且它可以壓縮的比例非常大，一般壓縮率為85%，就是說服務器端100K的頁面可以壓縮到25K左右的Gzip格式的數據發給客戶端，客戶端收到Gzip格式的數據后自動解壓縮后顯示頁面。

這點我們網站基本上是100%做到了，但是我們這項的評分并沒有達到想象中的A級，原因是出在我們的外部鏈接，比如我們首頁，有外部的廣告投放JS，這個JS說擁有的網站是沒有做過GZIP優化，連累了我們網站，所以我們也只有B，或者C級。

5. Put CSS at the top 把CSS外部鏈接放到頁面的頂部。

其實這個原則我們一般都遵守的，如果把CSS外部鏈接作為邏輯的一部分出現在頁面頭部以下，我個人覺得這個本身就是個錯誤。還好，我們的頁面基本上都做到了，可是有些頁面比如LIST頁面，還是出現了和邏輯掛鉤的CSS鏈接，原因是為了解決一些本來就不合理的產品邏輯。所以，我們WEB前端工程師有義務杜絕這些不合理的產品邏輯破壞我們的頁面結果及頁面加載速度，不能為了實現而實現。

上一篇：告訴什么是網站主機提供商

下一篇：做網站非常重要的一點主機性能