眾所周之，在不影響整個網(wǎng)頁構(gòu)架與功能的情況下，網(wǎng)頁文件越小越好，因為更小的網(wǎng)頁文件有利于瀏覽器對網(wǎng)頁的解釋時間縮到更短，自然訪客也就不用面臨等待網(wǎng)頁緩慢呈現(xiàn)的煩躁了，這一點(diǎn)對于那些帶寬少網(wǎng)速慢的用戶猶為明顯。盡管對于現(xiàn)如今的帶寬來說，網(wǎng)頁文件那僅以K來算的大小實(shí)在是微不足道，但如何將這以K來計算的網(wǎng)頁文件精簡到最小還是網(wǎng)頁設(shè)計師們所應(yīng)該考慮的問題之一。試想一下，你會是希望打開一個網(wǎng)站的時候整個站點(diǎn)馬上呈現(xiàn)在你面前呢？還是喜歡花上十幾秒甚至是幾分釧來看整個站點(diǎn)一點(diǎn)一點(diǎn)的被瀏覽器解釋出來呢？

  在Table布局的時代，代碼無數(shù)次的隨著表格在頁面里重復(fù)，致使整個網(wǎng)頁文件變得臃腫無比，代碼的可讀性也降到最低，瀏覽器的解釋時間自然也增加了不少。而自從DIV+CSS的布局替代Table布局之后，這一切都得到了極大的改善，讓Table回歸到它原本用于顯示數(shù)據(jù)的位置上去，而布局就交給DIV+CSS來做，這樣代碼的可讀性與復(fù)用性都得到了提高，而DIV+CSS更為重要的一點(diǎn)就是將網(wǎng)頁文件的表現(xiàn)與結(jié)構(gòu)區(qū)分開來，再也不用為了表現(xiàn)而去改動整個網(wǎng)頁文件的結(jié)構(gòu)了。

  即使DIV+CSS的布局方式將以前Table布局時代碼的臃腫降到了最低，但對于網(wǎng)頁設(shè)計師來說，如何將網(wǎng)頁文件的大小控制到最小是永遠(yuǎn)值得探索和追求的一個問題。

看如下一段代碼：
 

  這樣的一段CSS代碼，在條理上很清晰，結(jié)構(gòu)也很明了，可讀性很強(qiáng)，可是這樣的一段代碼卻沒有做精簡，也就是說它是最原始的CSS代碼，下面看精簡后的代碼：
 

  在CSS中有復(fù)合屬性這一說法，也就是說可以將很多屬性參數(shù)整合在一起的，比如說上面的“margin-top; margin-right; margin-bottom; margin-left;”可以整合成一個“margin”屬性，然后為其配上參數(shù)。

  通過這一點(diǎn)，我們就可以在原始CSS代碼的基本上將代碼進(jìn)一步的精簡。而且這樣寫的結(jié)構(gòu)也合理，可讀性也同樣強(qiáng)?？墒菍τ谝喌綇氐讈碚f，這還不夠。為了讓這段CSS代碼的結(jié)構(gòu)明了，我們用上了空格換行等占用空間的東西，如果將這些占用空間的去掉呢？
 

  只這一句就替代了上面的一段代碼，這樣代碼就已經(jīng)精簡到了最大化，當(dāng)然，并不推薦所有人都這樣寫，這樣寫的CSS代碼在可讀性上要遠(yuǎn)遠(yuǎn)差于段落式的寫法，除非你對自己寫的代碼有完全掌握的信心。

  在同一個站點(diǎn)的CSS文件中，不可避免的會出現(xiàn)不同的ID或Class卻有一部分相同的屬性，如果將這些ID或Class逐個分開來寫的話，在CSS文件里無疑會生成重復(fù)代碼，而我們要盡量的精簡CSS文件的大小，那么“消滅”這部分重復(fù)的代碼就變得勢在必行。

  看下面一段CSS代碼：
 

  在上面的三個ID中都有一個相同的屬性“margin:10px 15px;”，如果就這樣分開來寫的話，這三個ID之間將保持各自獨(dú)立的關(guān)系，但卻生成了重復(fù)的代碼，而我們可以將其寫成如下格式：
 

  將上面的ID換成Class也是一樣的。這樣寫我們就成功的將重復(fù)代碼“消滅”掉了。但是如果這里具有相同的屬性的ID或Class過多的話，難免會造成代碼可讀性降到很低很低，所以除此之外當(dāng)具有相同屬性的都是Class時還有另外的一種寫法：
 

  當(dāng)然這種寫法時，調(diào)用時的寫法也與平常不一樣。