Best Practices for Speeding Up Your Web Site(2)

4、

Gzip Components

tag: server

壓縮組件

標籤：服務器

        前端工程師所做出的決定，可以顯著的將穿越網絡傳送HTTP請求和響應所花費的時間縮短。事實上用戶終端的帶寬，互聯網服務提供商等等已超出開發團隊的控制範圍。可是仍有其餘的變量因子來影響響應時間。經過壓縮方式減小HTTP響應的大小，能夠縮短響應時間。

    從HTTP/1.1開始，web客戶端就經過在HTTP請求的Accept-Encoding頭顯示的支持了壓縮。

         Accept-Encoding: gzip, deflate

        若是web服務器遇到包含該字段（ Accept-Encoding: gzip, deflate）的請求，它可能會使用客戶端列出的方法之一來對響應進行壓縮。web服務器經過在響應頭中的 Content-Encoding 字段來告訴客戶端已經對響應內容進行了壓縮操做。

        Content-Encoding: gzip

        Gzip是當前最流行的和最有效的壓縮方法。它是由GNU項目開發並被RFC1952標準化的。惟一其它你可能用到的壓縮方式是deflate，可是它可能相對於Gzip，效率要低，知名度要低。

        Gzip壓縮一般會減小響應的大小的大約70%。今天近乎90%的經過瀏覽器傳輸的網絡流量都宣稱支持gzip。若是你是使用Apache，配置gzip的模塊取決於你的Apache版本，Apache1.3使用mod_gzip,Apache 2.x使用mod_deflate。

        瀏覽器和代理中有一些被熟知的問題，可能在瀏覽器指望的東西和它實際收到的壓縮內容之間引發一些錯誤。幸運的是，這些較爲邊緣的例子隨着舊式瀏覽器的棄用而漸漸的被解決掉。Apache的模塊經過自動添合適的不一樣的響應頭信息來起做用。

        服務器會根據文件類型來選擇壓縮的內容，可是可能在它所決定要壓縮的內容上會受到限制。大多數的瀏覽器站點壓縮他們的HTML文檔。壓縮你的腳本和樣式表文件一樣是值得，可是多數的站點會忽視這些。事實上，壓縮任何的文本形式的響應都是值得的，包括XML和JSON。圖像和PDF文件不該該再被壓縮了，由於它們都已是壓縮形式的了。試圖來壓縮它們（圖像和PDF）不但會浪費CPU，並且可能潛在的增長了文件的大小。

    

        儘量多的壓縮文件，是一種減輕網頁重量和加速用戶體驗的較爲簡單的方式。

5、

Put Stylesheets at the Top

tag: css

將樣式文件放在頂部

標籤：css

        當研究雅虎的性能時，咱們發現將樣式文件放在文檔HEAD標籤中會使網頁的下載速度加快。這是由於將樣式表擋在HEAD標籤中會是網頁逐漸的渲染。

        關注性能的前端工程師想要一個網頁來逐漸的加載；即，咱們想要瀏覽器來儘量快的展示它所已經包含的一切內容。這對於包含許多內容的頁面或者對於處在一個低速網絡環境中的用戶來講顯得尤其重要。向用戶展示諸如進度條的可視化反饋的重要性，已經被很好的研究和文檔化了。在咱們的場景中，HTML頁面就是進度的顯示器。當瀏覽器逐漸的加載頁面時，頭部，導航條，頂部的logo，等等，全部的內容都會做爲正在等待該頁面的用戶的可視化反饋。這提升了

內在的用戶體驗。

        將樣式文件放在近乎文檔的底部位置的問題是，這阻止了多數瀏覽器的逐步渲染過程，包括IE。這些瀏覽器會阻止渲染過程來避免當其中的樣式改變時而不得不進行的頁面元素的重塑。用戶會被卡住，看到一個空白頁面。

        

        HTML的 詳細說明文檔中很清楚的說明了樣式應該被包含在頁面HEAD標籤中。不像A標籤，LINK標籤只能出如今文檔的HEAD標籤區域中。儘管他可能出現屢次。不管是哪一種備選方案，空白的屏幕，或者是無修飾內容的法拉盛，都不值得去冒險嘗試！最佳的解決方案是聽從HTML詳細說明書，把樣式放在HEAD標籤中。

6、

Put Scripts at the Bottom

tag: javascript

將腳本放在底部

標籤：Javascript

        腳本引發的問題是他們阻塞了併發下載。 HTTP/1.1詳細說明中建議瀏覽器在一個主機名中不要併發的下載超過兩個組件。若是多個主機名下提供圖片，可能出現超過多於兩個的併發下載。可是當腳本被下載時，瀏覽器不會開啓其它的下載，甚至是在不一樣的主機名下。

        有些狀況下將腳本移動到底部會不太容易。例如，加入你使用document.write來插入部分頁面內容，這時便不能將其移到頁面較低的部分。這可能會引發做用域問題。在多數狀況下有許多辦法來繞過這些問題。

        常常被說起的一個可選的建議是使用延遲腳本。DEFER 屬性標明瞭腳本中不包含document.write，而且指示瀏覽器能夠繼續渲染。不幸的是，Firefox不支持DEFER 屬性。在IE中，腳本能夠被延遲，可是不全是按預期的那樣。若是一個腳本能夠被延遲，它就能被移動到頁面的底端。這會使你的頁面加載更快。

7、

Avoid CSS Expressions

tag: css

避免CSS表達式

標籤：css

        CSS表達式多是一個強大的（危險的）方式來動態的設置CSS的屬性。它們在IE5中開始被支持，但IE8不同意其使用。舉例，經過CSS表達式，能夠每小時都輪流設置背景色：

 

        background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

         就像所展現的那樣，expression方法接受一個Javascript表達式。CSS的屬性值被設置爲Javascript的表達式計算結果。expression方法在多數在其它瀏覽器中會被忽略，因此這對於在IE中設置建立跨瀏覽器的一致性體驗的屬性來講會有用。

    

        表達式的問題是它們的計算頻率會超乎多數人的預期的樣子。不只僅是當頁面從新渲染和重設大小時它們會被計算，並且是當頁面滾動甚至是用戶在頁面上移動鼠標時它們都會被計算。在CSS表達式上預設一個計數器容許咱們追蹤什麼時候CSS表達式計算的時間和頻率。在頁面上移動鼠標可能很輕易產生超過10000次的計算。

         一個減小CSS表達式計算次數的方法是使用one-time expressions，當表達式第一次執行時，where the first time the expression is evaluated it sets the style property to an explicit value, which replaces the CSS expression，若是樣式屬性在頁面的整個生命週期中都要動態的設置，使用事件處理來代替css表達式是一個可選的方法。若是你必需要使用CSS表達式，記住它們可能被計算成千上百次而且會影響你頁面的性能。

8、

Make JavaScript and CSS External

tag: javascript, css

使Javascript和Css外部化

標籤：Javascript，css

        許多這些性能法則都是解決外部組件的管理方法問題。然而，在這些考慮出現前你應該問本身一個更加基礎性的問題：Javascript和CSS是應該被包含在外部的文件中，仍是應該嵌在頁面自己中。

        現實世界中使用外部文件總的來講都會產生更快的頁面響應，由於Javascript和css文件在瀏覽器中是可緩存的。內聯在HTML文檔中的Javascript和CSS在HTML文檔的每次請求中都被會下載。這減小了必要的HTTP請求的次數，可是卻增大了HTML文檔的大小。相反的，若是Javascript和CSS被包含在瀏覽器緩存的外部文件中，HTML文檔的大小會被減少，HTTP的請求次數也沒有增長。

        以後，關鍵的因素是外部Javascript和CSS組件被緩存的頻率，相對於請求的HTML文檔的數量。這個因素，儘管很難定量，仍然能夠經過多種度量方式來測量。若是你的站點用戶在一次會話中有多個頁面視圖，而且你的許多頁面都重用了相同的腳本和樣式，這對於緩存的外部文件來講有很大的潛在益處。

         Many web sites fall in the middle of these metrics. 對於這些站點來講，最好的解決方式是將Javascript和CSS做爲外部文件進行部署。惟一例外的是，對於主頁來講，內聯方式是可選的最佳方式，例如 Yahoo!'s front page和My Yahoo!。在一次會話中有較少頁面視圖的主頁可能會發現內聯方式的Javascript和css會產生更快的終端用戶響應時間。

        對因而許多頁面視圖的第一前端頁面來講，有許多折中技術來利用內聯方式減小HTTP請求，同時兼得使用外部文件的緩存益處。其中的一個技術是在前端頁面中內聯Javascript和css，可是在頁面文件加載完畢後動態的下載外部文件。以後的頁面將引用瀏覽器中緩存的已存在的外部文件。