CSS編寫代碼時的高效能總結

這篇文章主要介紹了CSS編寫時的效能最佳化以及高維護性最佳化建議總結,包括雪碧圖和尺寸設定等熱門的討論點,需要的朋友可以參考下

效能，這個詞如今被炒的很熱，也是每個開發人員，由“知道”、“會做”之後必經的一個“怎樣做好”的階段。效能關乎使用者在不同裝置和不同網路狀態下的體驗。也被多方面因素所影響。此文說說css方面怎樣做到高效能。

高效能css

Html和css本身的效能問題並不突出，在提高可讀性和可維護性的前提下，如果能讓代碼運行和解析的速度更快，則是錦上添花了。

一、使用高效css選取器

簡單來說，能被瀏覽器快速解析和匹配的css選取器，就是高效的選取器。

首先要知道瀏覽器如何解析css

舉個例子：

.nav ul.list li p{}

我們常見的思維是，先去找到nav這個類，再找類包含的ul，再找ul中類為list的後代所有li中所有的p，簡而言之，就是從左至右。可事實是這樣嗎？嗎？嗎？~

事實是相反的！意味著什麼呢？就是說它不是從第一個開始去慢慢的縮小範圍，而是從p這個“裸奔”的盒子開始，相當於遍曆，然後再找到li，以此類推，好吧不用我形容你應該知道這當中的消耗。理解這一原理非常重要，高效的選取器意味著匹配更快，尋找次數更少。所以我們定義選取器時，應該讓第一次匹配時的數量達到最少，並且讓整體的匹配尋找次數最少。

以上這些解釋恰恰遵循了這樣一些原則

（1）避免使用萬用字元

（2）避免使用標籤選取器和單個屬性選取器作為關鍵選取器

（3）不要在id選取器前加標籤名

（4）盡量不要在選擇符定義過多層級，層級越少，同時也降低了css和dom結構的耦合程度，提高樣式的可維護性

（ps：老實說上面的這些“禁忌”你是不是都有犯過？~）

做個小結，以上所說，有兩點需要知道，第一點在開頭就已經提到，css的效能問題表現的並不突出，特別是在小項目中，所以，可維護性為先；第二點是雖然定義id選取器，有唯一性的優勢，但是一個頁面只能定義唯一id，定義過多id會使重用性降低，維護更困難，所以不建議多用id。

二、css相關的圖片處理

現在的網頁當中，圖片所佔的比重以及它的重要性大家都知道。那麼如何處理好圖片以及如何為圖片設定樣式，才能讓使用者開啟網頁時體驗更好呢？下面給出一些意見：

（1）不給圖片設定尺寸

在我個人的從業經曆當中，有過這樣的情況，我按照設計稿做好了頁面，交給後台去測試，他就突然跑過來跟我說：hi，你看，這兒出狀況了，我一看，壞菜，圖片出格了，我才想起沒有給圖片定義寬高（直接從設計稿裡切的也不需要），然後就犯錯了似的在css樣式裡定義了寬高。以至於後來我把這個作為下次再做頁面時候的注意事項。當我看到這一條意見的時候，才更知一二。

來看解釋，第一、設計人員為了畫面的精美，會製作一些超出需求尺寸的圖片；第二、同一張圖片可能會在頁面不同地方多次使用，比如縮圖、正常圖、大圖。問題來了，如果圖片原始大小和實際需求不同，在使用過程中就會存在效能問題，利用樣式縮放會帶來cpu的額外計算過程，增加了圖片在瀏覽器的渲染時間，網路傳輸過程也會佔更多頻寬，增加下載時間。因此，最佳做法是，為需要的部分單獨做一套圖片，初始頁面載入時就能更快展示。

（2）使用css“雪碧圖“

是將零散的圖片合并成一張大圖，在利用css進行背景定位。好處是減少請求數，提高了圖片整體的載入速度。

但它也存在一些缺點：

比如，多張圖片合并成大圖，需要精確計算，仔細的調整位置，單純手工製作是一件很複雜的事情。（所幸現在有一些工具可以幫我們做）

另外，維護過程複雜，要盡量讓已有的圖片保持原來的位置不變，如果是背景圖的尺寸發生變化導致原有地區無法放置，那就只好放棄，如果非要在原有位置修改，則剩餘的圖片樣式都需要修改，是很繁瑣的過程。新加的圖片最好放在最後面。

還有就是使用不當會導致效能問題，最大的問題就是記憶體消耗。如果製作過程不做任何的規劃，隨意擺放，則可能會使圖片變得相當大，從而很占記憶體。

下面是一些最佳實務：

1、在項目後期應用css sprite技術

因為一般在開發過程中，會比較頻繁的修改或者更換圖片，如果這個時候使用sprite技術，就會增加很多開發成本。

2、合理組織“雪碧”圖

如果要把所有的圖片放在一張圖上面，也會有不妥，維護方面也不會很方便。組織背景圖主要按照模組和背景圖的風格來劃分。比如，作為展示的縮圖放在一起，評論、點贊、上下箭頭等表徵圖放在一起等。

3、控制“雪碧”圖的尺寸和大小

因為大尺寸的圖片會佔用大量的記憶體，所以要控制在合理尺寸，推薦長寬相乘不超過2500，大小在200kb內

4、合理控制背景圖單元間的距離及背景圖位置

這個原則是為了防止在背景圖比元素大小更小的時候，地區出現別的無關背景圖

5、藉助相關工具處理sprite

三、減少css的代碼量

提高網站整體載入速度的一個重要手段，就是提高代碼檔案的網路傳輸速度。除了代碼壓縮，精簡代碼也是一種手段。

（1）定義簡潔的css規則

合并相關規則，定義簡潔的屬性值

合并規則是指比如font-family、font-size、font-weight等等，可以合并為font。 簡潔屬性值，比如顏色值：color，#33AAFF可以簡化為#3AF等。

（2）合并相同定義

網頁中總會有一些模組有較高相似性，則可把同樣的部分共用一次定義，不同的部分再單獨定義。而且在css中，很多屬性是可以繼承的，則只需要在合適的地方定義一次即可。

（3）刪除無效的定義

無效的定義，並不會影響頁面功能顯示，但會影響頁面展示的效能，增加代碼量的同時，也增加了瀏覽器解析代碼的時間。無效的定義包括無效的規則及無效的樣式屬性，一般是開發過程中引入的，而從直觀上無法判斷，這情況，可以用工具，chrome內建的工具就可以尋找css中的無效樣式。。

其他css高效能實踐

（1）避免使用@import

@import匯入的新樣式檔案會阻止頁面的並行下載，這樣增加了檔案的整體載入時間。

（2）避免使用IE瀏覽器專屬樣式：圖片濾鏡和css運算式

圖片濾鏡的使用會在圖片載入時阻塞瀏覽器的載入和渲染，並會增加額外的記憶體開銷。 Css運算式的作用是動態設定css屬性，運算式不只是有相容性問題，還有效能問題，例如瀏覽器大小改動、視窗改動時，會使得瀏覽器頻繁計算，效能消耗極大。同樣的效果可以用javascript來實現。

css3最佳實務

查看瀏覽器支援情況

在我們使用css3的過程中，問的最多的一個問題可能就是：相容性如何？沒辦法，隨著css的發展，它可以為我們之前遇到的很多不好解決的問題提供一個更好的方案，讓我們忍不住去想能不能那樣去做。PC端有飽受詬病的IE系列，到了移動端會好很多，但有些還是不太好。所以，查看瀏覽器支援情況幾乎成了必備動作。 如果使用的特性僅僅是裝飾點綴性的效果，不影響大局，則不需要考慮太多相容問題，如果是出於設計要求，必須支援所有瀏覽器，則要特別的關注一下了。 開發人員可以選擇比如：caniuse.com、css3 Click Chart、css contents and browser compatibility這些線上工具來查看相容性。

添加必要的瀏覽器首碼

對於剛使用css不久的朋友來說，如果偶爾在某網站源碼當中看到諸如：“-webkit-、-moz-”等，可能會覺得很奇怪，這是什嗎？它們是對應不同的瀏覽器廠商所加上的首碼。

因為瀏覽器在支援css3時，可能僅僅實現了標準定義的一個早期版本，所以，尚不支援標準寫法，給代碼添加瀏覽器首碼也是無奈之舉，會使得代碼更多，更難維護。

但也不是為了“完美”而一定要去相容所有的瀏覽器，一般可以按照瀏覽器或者系統的版本的市場佔有率和目標使用者使用瀏覽器的比例，來決定加不加首碼以及加幾種首碼。而且相信隨著逐步的發展，系統、瀏覽器的不斷升級、更新，需要使用首碼的情況會減少。

問題又來了，既然需要添加必要的首碼，說明有些時候還是很有必要，那不得不加的情況下，那不是挺麻煩的？同樣的一條規則要寫三四遍，可能很多地方都要用，如何是好？別急，下面是幾個對策：

1、使用工具來添加css屬性的瀏覽器首碼

Prefixr，可以在開發的後期對代碼進行處理。它會自動的添加需要的首碼和刪去不必要的首碼。

Autoprefixer，如果想要在開發過程中更多的自主性，可以使用這個工具，開發人員可以自訂瀏覽器支援範圍，它也有多種使用方式，可以整合到多個開發環境中。 此外還有幾種工具可供使用：cssFx、*css Agent*和-prefix-free。

2、藉助css預先處理技術

目前流行的有sass、less，具體方法是，針對css3樣式特性定義一份模板樣式。 優點是：避免大量重複代碼，只需要維護一份定義。

3、不要過度添加瀏覽器首碼

有些開發人員為了相容所有瀏覽器，不管什麼情況都為css代碼加上了所有瀏覽器的首碼，這是一種消極的編碼方式，增加了太多的重複代碼，降低了瀏覽器的解析效能，增加了複雜度，同時某些首碼的屬性可能沒有被瀏覽器支援過。

4、添加css3標準屬性定義

何為標準屬性定義呢？就是不需要任何瀏覽器首碼，大家可能都會注意到，很多使用css3的地方都會在最後的地方寫標準屬性定義，為什麼呢？因為當瀏覽器支援標準屬性時，它可以覆蓋前面添加了首碼的定義，css3中的屬性標準定義才是符合規範的定義，添加了瀏覽器首碼的定義會隨著瀏覽器的更新逐漸被淘汰。

當然，還有一點需要注意的是，某些屬性，目前是屬於Only webkit或者Only firefox的，那麼就沒有必要再寫上標準定義及其他瀏覽器首碼了。

做好css3中新特性的相容處理

說到相容，就會提到低版本IE，比如很常見的圓角、透明圖片等，有時候我們會給它們降級的處理，比如filter或者javascript，使用box-sizing、transform，推薦使用Modernizr,這個架構中包含了很多css3新特性的相容方案。

無論是哪種方案，都會帶來效能上的損耗，不能毫無章法的濫用，仍然是需要大家去權衡和選擇。推薦一個如何更有效率的使用HTML5的建議的網站：html5please。網站按照使用的方式把css3中的新特性分成了三類：

（1）直接使用

包含了大部分新特性，有些特性本身不會影響相容性，如border-radius、media queries等，有些需要添加降級處理，如多背景圖，要設定一個單背景圖或者背景色作為備選。

（2）謹慎使用

這部分主要是效能問題，例如框陰影應用於佔用很大地區的元素，頁面滾動或滑鼠移至上方時，會引起不小效能問題。

（3）避免使用

這部分因為它們可能僅支援某個瀏覽器，比如倒影，則需要避免使用。

綜上所述，css能夠用來提高效能的方法還是蠻多的，但我們很容易忽略它們，因為它們所帶來的影響似乎沒有那麼明顯，而且，很多人可能為了圖方便，任意揮灑著自己的才華，想怎麼寫就怎麼寫，能達到效果就行，這也有點小消極哈，忘了你的優秀工程師目標了麻？！~~css規則雖不不難，真正寫好也不易，還是要有些追求極致的精神滴。諸君且寫且珍惜吧！~

高維護性css

Css有些什麼特點？

簡單來說，使用方式：內聯、內嵌、外聯、import。為元素設定樣式的方式：元素標籤名、類名、id、各種選取器，以及它們的組合。所以，它是很靈活的，如果不做任何的規範的限制，就肯定會導致css代碼的混亂和難以維護。

如何高效組織css代碼？

結構清晰、模組分明，合理的程式碼群組織結構可提高代碼的重用性和可維護性，降低開發複雜度。那怎樣組織呢？

首先是組織代碼檔案，可分為兩大類：通用類和業務類。 然後，有一個檔案用來重設，常見命名是reset或者default、normalize等。

有一個檔案用來存放通用模組和一些基礎樣式，常命名為mod、common等，如頁面對話方塊，提示框，頭部，底部，側邊欄等，會在多個頁面用到，這樣方面各頁面引用，提高代碼複用度。

另外需要一個檔案存在相容舊版IE瀏覽器的樣式，這樣做的好處有二：

一、減少非IE瀏覽器載入樣式檔案的負擔

二、如果未來決定不再支援舊版的IE瀏覽器，則只需要去修改一個檔案，不需要多個檔案到處找去修改。當然，在處理瀏覽器安全色問題上，有個原則是，是否有其他不存在相容問題的方案，如果沒有，則把要做相容的部分單獨放在一個檔案中。

其餘的css樣式檔案則用於業務模組，不同模組的樣式檔案放置於不同的檔案夾中，原則上每個模組的樣式檔案不宜太大。

這樣可能會造成一個問題，一個頁面不是要引入很多檔案了？頁面載入的時候http請求不是多很多？其實並不矛盾，檔案的劃分只是為了方便開發和維護，發布的時候會使用工具把多個檔案壓縮合并成一個檔案，所以不用擔心引入多個檔案的問題。

上面說的是檔案的組織，那麼在檔案中也要按照一定規則來組織樣式的聲明。 比如，按照模組中元素的層級，如果是同級，則按照元素在頁面中的位置，從上到下，或者從左至右，若存在多個元素共用相同聲明，則應先聲明共通樣式。 如果覺得這樣還不夠，則可以使用一些更進階的方式，如less、sass，它們將css賦予了動態語言的特性，如變數、繼承、運算、函數等。

以上是從幾個大的方向去說的，下面涉及某幾個點談一談

使用css reset 統一瀏覽器顯示效果

首先，html的標籤是有原始樣式的，但問題是在不同瀏覽器中，標籤的預設樣式不盡相同，其中的某些差異給開發造成了麻煩，早在2004年，就有人開發了第一個重設樣式檔案，叫undohtml.Css,後續又有了多種重設方案，其中有個方案“火爆一時”，此方案總共就一行代碼*{margin：0；padding：0；}。重設了所有標籤預設的margin、padding樣式，但有一個弊端是增加了後續開發的複雜度，並不能很有效提高整體開發的效率。另外，此方案效能也不佳，當頁面元素很多時就會影響頁面渲染的效能。所以，人們還在逐漸的探索更好的重設方式，目前有多個流行的重設方案，有Eric Meyer開發的Reset CSS和雅虎公司前端技術團隊開發的YUI Reset CSS。其實並不存在一種方案適合所有項目，所以最好還是選擇參考別人的方案然後設計一套適合自己項目的方案。

需要考慮如下幾點：

（1）HTML5新標籤 需要重設它們的display樣式，因為在低版本IE中沒有定義它們的預設display樣式。

（2）padding、margin、border 標籤在瀏覽器中的差異主要是與這三個樣式有關的預設樣式產生的，但也不是需要重設全部元素的margin、padding、border，應根據實際情況。

（3）字型設定 <h1>~<h6>、<strong>、<em>等語義化標籤都有預設字型，但實際當中所需要的字型大小或者粗細都跟預設不同，所以一般項目中都會對他們進行重設。

（4）其他元素的樣式重設 典型的有li預設的清單項目樣式，table的儲存格之間預設空間，a連結的底線等。

給css定義排序

Css的邏輯性不強，隨意的書寫也不影響其作用，如果不藉助工具對其排序也會很繁瑣，所以，很少有人會在意，但是排序還是有好處的。

比如：

1、更整潔

2、防止重複定義

3、能夠清晰查看定義

4、後續維護能快速定位

排序方式：

1、按類型 如，顯示和浮動、定位、尺寸、字型等

2、按字母 按字母順序排列，優點是規則簡單

3、按定義長度 按照樣式定義的字元長度排列

各有優劣，實際應用中，推薦使用第一種。 但是如果單靠前端工程師在編寫過程中這麼做的話也是很難的，可以在寫的過程中按照效率最高的方式寫，提交代碼時使用工具為css排序。既提高效率，又方便後續代碼閱讀和維護。有一款免費工具是 CSScomb。

合理利用css的權重，提高代碼重用性

何為權重，即css眾多類型選擇符的優先順序，優先順序高的樣式會覆蓋優先順序低的樣式。權重的更具體規則，大家可以查閱資料，這裡不贅述。

這裡說說如何依照選擇符的權重定義合適的選擇符：

（1）盡量不使用ID選取器

一個頁面中不允許定義兩個同樣的ID，而且ID選取器權重很高，如果要覆蓋使用了ID選取器的元素樣式，就必須在其元素上添加新的選擇符，或使用！important，這樣的結果會使無法重用的樣式代碼變得更多。最佳實務是儘可能使用較低權重的選擇符作為基礎樣式。

（2）減少子選取器的層級

也是降低子選擇符整體權重的過程，同時，層級越少，對html結構的依賴就越低。引起Css層級過多的另外一個原因是sass、less等工具的濫用，這也是我本人在使用之初就有意識到的問題，因為你可以使用嵌套和引用等方式來定義樣式了，這樣以來給自己省了很多功夫，但檔案最終還是要編譯出來，我們不用反覆的敲那麼多代碼了，但產生的程式碼依然還是會很多，所以，方便了自己的同時依然要特別注意減少選取器層級。

（3）使用組合的css類別選取器

使用這種方式，開發人員可以不用考慮css樣式覆蓋的問題，避開了計算選擇符權重的過程，同時提高了代碼的重用性，組合的概念是把一個複雜的父類中的可變部分和穩定部分分割開來，穩定部分作為主體類，可變部分分成幾個簡單的類，類與類之間沒有繼承，同樣可以起到減少對html結構的依賴，提高代碼重用性的作用。

如何相容IE瀏覽器？

IE8及以下版本的IE瀏覽器一直是前端開發人員心中的痛。為了相容它們做額外添加的代碼成為hack代碼，往往人們都不想去寫那些代碼。以下是相容IE瀏覽器的一些實踐方法。

（1）熟悉IE瀏覽器中常見的樣式相容問題

一類是瀏覽器本身的bug，一類是和標準不相容或還不支援標準。

（2）分離樣式相容代碼

按照瀏覽器的不同版主要組織代碼檔案，然後使用判斷語句，按需載入

em、px還是%？

談及這個話題的原因是，如今頁面功能變得越來越多，用來訪問頁面的裝置越來越多，頁面的布局就是一個頗具挑戰的事情，而頁面當中的元素的尺寸和字型、圖片的大小等也跟布局息息相關。鑒於此，前端開發開始重視如何提高頁面配置，核心思想是將頁面元素的尺寸和字型大小設定為相對值。字型相對單位包括：em、ex、ch、rem。更多內容無需贅述，有更多的資料來講解。下面給出幾個最佳實務：

（1）盡量設定相對尺寸

所謂設定相對尺寸，並不是說頁面整體的布局是自適應的，整體的尺寸可以是固定尺寸也可以是自適應的尺寸，這取決於頁面的設計。

（2）只有在可預知元素尺寸的情況下才使用絕對尺寸

比如設計上要求使用絕對寬度，比如整體寬度，側邊欄寬度，頁頭頁尾的高度固定等，在展示圖片、視頻的時候，合適的固定尺寸會讓這些多媒體元素展示獲得最佳的效果。

（3）使用em設定字型大小

使用px設定字型大小的可擴充性不好，使用百分比設定字型大小也不符合習慣，最佳方式是使用em設定字型大小，但隨著字型設定的層級增多，這種方式反而增加了維護的成本，對於此，css3引入了rem單位，是相對於根項目的字型大小計算的，就避免了這個問題，目前除了IE8及以下，大部分瀏覽器都支援它。

此文很多東西都是點到為止，希望對一些新手來說有一定的引導作用，帶來一定的協助。每個人在自己逐步的實踐當中都會有一些這樣那樣的感觸和經驗、教訓等，經常的總結和放入到自己的下一步實踐當中，相信是會很有好處的。大家一起加油！~

以上就是本文的全部內容，希望對大家的學習有所協助，更多相關內容請關注topic.alibabacloud.com！