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）字體設定

~

、、等語意化標籤都有預設字體，但實際當中所需要的字體大小或粗細都跟預設不同，所以一般專案中都會對他們進行重置。

（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及以下，大部分瀏覽器都支援它。

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

以上就是本文的全部內容，希望對大家的學習有所幫助，更多相關內容請關注PHP中文網！

相關推薦：

提升css效能的方法

以上是CSS編寫程式碼時的高效能總結的詳細內容。更多資訊請關注PHP中文網其他相關文章！