Sass與Compress實戰:第八章

概要:幫助你實現樣式表的最佳性能css

本章內容前端

  ● 樣式表拼接web

  ● 樣式表和資源壓縮算法

  ● 減小和並行圖片請求的策略瀏覽器

  ● 選擇器性能和優化策略緩存

1. 測量客戶端性能安全

性能優化的起點和終點都是測量。在第一次改變性能位置以前,你須要知道本身究竟在什麼位置。性能優化

下面是一些工具:服務器

  ● YSlow:http://developer.yahoo.com/yslow/。cookie

  ● Google PageSpeed:http://developers.google.com/pagespeed/。

  ● WebPagetest:http://www.webpagetest.org/

1.1 迴避帶有服務器端@import的HTTP請求

正如你在第3章中看到的,@import指令是一個很是有用的工具,它可以將大型的樣式表組織爲較小的部分,以便輕鬆地查找樣式。在CSS的一個樣式表中導入許多其餘的樣式表並不鮮見:

@import url("blog.css") ;
@import url("forum.css") ;
@import url("article.css") ;
@import url("header.css") ;
@import url("footer.css") ;

這樣的寫法下降了第一個頁面的速度,由於它須要數個HTTP請求如下載所須要的多個樣式表。CSS的最佳實踐之處,要講你的樣式錶鏈接成少數幾個樣式表。這就是Sass提供服務器端導入的緣由:

@import「blog」,「forum」,「article」,「header」,「footer」;

這將提升第一個頁面的載入速度,由於全部的樣式表只須要一次請求就能下載完成。許多網站採起的策略是將CSS文件組織爲三個層級:

● 核心樣式表:幾乎每一個頁面都須要的普通樣式。

● 部分樣式表:應用或者網站的某個大型部分須要的普通樣式。

● 單頁樣式表:只有某個單獨頁面須要的樣式,常常用於銷售頁面這樣設計複雜而獨特的頁面。

2.用壓縮減小傳輸時間

有個簡單的方法能讓你的網站變得更快:縮小在互聯網中傳送內容的大小。

2.1 gzip壓縮

大多數現代瀏覽器會連同請求發送一個請求首部Accept-Encoding:gzip,只要響應中含有一個包含Content-Encoding:gzip的首部,就能被壓縮。一般,優化前端性能的最佳方式是儘量縮小資源的網絡複寫。對於全部關注客戶端性能的網站來講,使用gzip壓縮文本資源並優化網絡圖片都是必行之事。

預壓縮樣式表並根據請求首部提供不一樣的文件也是一種可行辦法。設置方法應該依據服務器來具體分析。可是若是你須要進行這樣的設置,Compass提供了一種簡單的方式來自動生成壓縮樣式表。你能夠在Compass中註冊一個回調函數,每當保存一個新的樣式表,它都會運行。將下面的代碼添加到你的Compass配置文件中便可:

on_stylesheet_save do |filename| # run the gzip tool on the file # generates a file of the same name # plus a .gz at the end. 'gzip -f #{file}' end

2.2 圖片壓縮

關於圖片,你首先須要瞭解的是,大多數圖片格式擁有內建的壓縮方式。基本的法則就是,針對不一樣的圖片,你應該使用可以達到最大壓縮程度的不一樣圖片格式。也就是說,你通常應該使用下面幾種格式:

  ● GIF格式用於顏色數量少的小文件;

  ● JPG格式用於在圖片質量設置爲最低值時不會引發圖片質量明顯降低的攝影圖片;

   ● PNG格式用於其餘圖片。

PNG是一種可以處理多種圖片類型的複雜格式。確保移除其中的alpha層,不然會獲得透明效果。

3. 用資源託管提升頁面加載速度

HTTP/1.1標準中指出,Web瀏覽器應該限制每次頁面請求中單個域的同步下載數量,從而達到最佳效果。可是在許多服務器上運行的負載均衡網站能夠很好地處理這種突發流量,所以你須要對瀏覽器耍一點小把戲來解決這一問題。一種廣泛的策略是註冊多個域(或者子域),並將它們解析到同一個地方。

除了具備並行的好處,設置資源託管來使用一個無cookie域也很重要,即一個不會和站點分享cookie的域。它每次可使用更少的字節向服務器發送圖片請求。

  而後,將指向圖片、樣式表和JavaScript的連接均勻分發至有效的資源託管。很重要的一點是,老是經過同一個資源託管來獲取相同的資源,不然該資源就會被屢次下載。很明顯,只有在你擁有一個可支配的框架去處理這些繁重的工做,並排除人爲引起的錯誤時,上述的解決辦法纔是可行的。Compass使資源託管變得很是容易!

3.1 使用資源託管生成URL

在默認狀況下,資源託管在Compass項目中是關閉的,可是你能夠告訴Compass如何在資源託管上分發資源,從而開啓資源託管。例如,爲了在四個子域中分發資源,你須要在Compass配

置中添加如下Ruby代碼:

asset_host do |asset| host_number = (asset.hash % 4) + 1 "http://img-#{host_number}.example.com" end

下面進行解釋。正如你在前一章中學到的,你應該使用Compass的資源URL輔助器來編寫全部的資源引用。若是你已經遵循了這條最佳方式,其實就已經對資源託管有了一些不錯的實踐。這裏,你仍然能夠編寫下面的CSS代碼:

#logo {   background-image : image-url(「logo-small.png」) }

你在配置中定義的asset_host函數接收一個叫作asset的參數,它將被徹底解析爲指向資源的HTTP絕對路徑。根據你的其餘配置,解析後的路徑格式應該相似/images/logo-small.png。asset_host函數的任務是返回資源生成URL的協議和主機地址。儘管你能夠自由地運用任何知足需求的邏輯,可是前面的例子在一般狀況下已經足夠了。首先,asset.hash會給你一個數字來惟一地表示asset字符串。其次,取模運算符(%)會返回其除4之後的餘數,該餘數是一個0到3之間的整數。最後,它經過每次增長1來進行基於1的計數。在第二行代碼中,將host_name插入一個字符串來生成合適的返回值。函數中的最後一個值是實際的返回值,這裏不須要顯式地指明return。接着,Compass會將該資源託管值與被傳入的地址和任何緩存相鏈接,來生成完整的URL:

#logo {   background-image:   url('http://img-3.example.com/images/logo-small.png?1298578273');
}

使用資源託管能夠顯著地減小客戶端渲染時間。

3.2 避免內容警告和基於域的資源相混合

若是你的站點支持SSL訪問,同時你想要使用資源託管,很是重要的一點是確保你的用戶不會從瀏覽器中接收到不安全資源的警告。處理這個問題的最佳方式是使用相對於協議的URL:

#logo {   background-image :   url(‘//assets3.example.com/images/logo-small.png?1298578273’) ;
}

 

當瀏覽器遇到一個相對於協議的URL,它會使用進行最初請求時的協議(對樣式表的請求)。爲了配置Compass在資源託管時使用一個相對於協議的URL,你須要在配置中添加如下代碼:

asset_host do |asset|
host_number = (asset.hash %4)+1
"//img-#{host_number}.example.com"
end

若是你決定在HTML標記中使用相對於協議的URL,有一點須要注意。IE6和IE7中的一個bug會致使一個指向相對於協議URL的樣式表<link>標籤被下載兩次。

4. 內聯dataURI

在CSS中使用data URI時,你可能會使用一個Web服務來上傳圖片並輸出相應的data URI,而後對須要內嵌的每一個圖片重複這一過程,可是這一的作法耗時耗力並且難以維持。經過使用Compass,處理內嵌圖片和其餘資源簡直是小菜一碟:

.icon { background : inline-image(「black-dot.png」) ; }

Compass能夠基於圖片的擴展名找出大多數圖片格式的MIME類型。可是若是Compass沒有識別出圖片的擴展名,而且擴展名和MIME類型的第二部分不相同,你能夠顯示地提供MIME類型:

.icon {   background : inline-image(「black-dot.bitmap」,「image/bmp」) ;
}

既然Compass能夠如此簡單地處理內嵌圖片,而且可以經過避免額外的數據往返帶來諸多好處,爲何咱們不一直時用這種方法呢?緣由有如下幾點:

● 體積膨脹——base-64編碼算法的效率並不如普通的二進制編碼。

● 緩存——即便這樣的作法加快了速度,可是內聯圖片會增長你的CSS文件體積。

● 瀏覽器支持——IE6和IE7並不支持data URI,IE8支持的data URI上限爲32KB。

5. 選擇器性能

5.1 聚沙成塔的問題

選擇器的性能之戰主要集中在兩個方面:修剪和匹配。在修剪方面,瀏覽器迅速肯定並排除全部不會匹配某一個特定元素的選擇器。在最低限度上,瀏覽器會查看關鍵選擇器,來決定這個選擇器可否被修剪。最近,瀏覽器已經開始引入新的修剪啓發式方法,好比ID做用域法。

5.2 過度嵌套的危險

緊湊易讀的Sass文件有時可能變成巨大的CSS文件,所以很是重要的一點是,在編寫Sass時要時刻記住最終生成CSS文件的尺寸和複雜性。特別是Sass新手傾向於使用嵌套選擇器來複制HTML結構。這種方法有其肯定性。最終,你將會陷入一個比內聯樣式更難維護的情形中,即便最小的標記修改都會破壞你的設計。並且,因爲嵌套時的默認鏈接符是後代鏈接符,並且關鍵選擇器一般是一個元素選擇器,這意味着你編寫的樣式正在生成最無效的選擇器。爲了幫助你識別異常膨脹的樣式表,Compass提供了一個stats命令。要實用stats命令,必須首先安裝一個叫作css_parser的Ruby gem:

$gem install css_parser

而後運行Compass的stats命令:

$ compass stats
相關文章
相關標籤/搜索