CSS 文件體積大了會影響頁面速度嗎，壓縮能省多少？

很多人優化網頁性能，第一反應是壓縮圖片。圖片確實大，但有一種文件比圖片更影響頁面的「第一屏出現速度」——CSS。

不是因爲 CSS 文件有多大，而是瀏覽器處理 CSS 的方式有點特殊。

CSS 爲什麼比圖片更影響首屏速度？

瀏覽器加載頁面時，遇到 <head> 裏的 CSS 文件，會完全停下來，等 CSS 下載並解析完，纔開始渲染頁面。這個行爲叫「渲染阻塞」（render-blocking）。

圖片不一樣。圖片是在頁面結構渲染出來之後才加載的，圖片沒加載出來，用戶至少能看到頁面框架。但 CSS 沒加載完，整個頁面對用戶來說就是一片空白。

所以 100KB 的 CSS 和 100KB 的圖片，對用戶體驗的影響完全不在一個量級。CSS 的每一個字節都直接延遲「First Contentful Paint」（FCP，首次內容繪製）。

壓縮 CSS 能省多少？

壓縮 CSS 主要做兩件事：刪掉空格、換行、縮進，以及刪掉註釋。這些內容對瀏覽器來說完全沒用，只是給開發者看的。

實際能省多少，取決於原始代碼的風格：

手寫 CSS，格式規範：大約能減少 35-45%
Sass/Less 編譯出來的 CSS：減少 45-50%（嵌套語法生成了很多空白）
Bootstrap 這類框架的 CSS：減少 35-40%

一個具體例子，450 字節的格式化代碼：

/* 壓縮前：450 字節 */
.hero-section {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  padding: 2rem;
  background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
  min-height: 100vh;
}

.hero-title {
  font-size: 3rem;
  font-weight: 700;
  color: white;
  margin-bottom: 1rem;
  text-align: center;
}

壓縮後：

/* 壓縮後：約 280 字節，節省 38% */
.hero-section{display:flex;flex-direction:column;align-items:center;justify-content:center;padding:2rem;background:linear-gradient(135deg,#667eea 0%,#764ba2 100%);min-height:100vh}.hero-title{font-size:3rem;font-weight:700;color:white;margin-bottom:1rem;text-align:center}

光壓縮還不夠，gzip 纔是大頭

服務器傳輸文件給瀏覽器之前，現代服務器會先用 gzip 或 Brotli 壓縮。這一步比手動壓縮 CSS 省的多得多。

gzip 的工作原理是找重複的字符串打包，而 CSS 裏有大量重複的屬性名（display、margin、padding……），gzip 特別擅長處理這種內容。

數據對比：

處理方式	文件大小減少比例
只壓縮 CSS（去掉空格註釋）	35-50%
只用 gzip（不壓縮 CSS）	60-70%
先壓縮 CSS，再 gzip	80-90%

所以兩步都做纔是正確姿勢——先把 CSS 壓縮，再讓服務器開 gzip，疊加效果最好。

確認服務器有沒有開 gzip，打開瀏覽器 DevTools → Network → 找到 CSS 文件 → 看 Response Headers 裏有沒有 Content-Encoding: gzip。有就是開了，沒有就需要在服務器配置裏手動開啓。

壓縮之外：刪掉沒用的 CSS 纔是真正的大招

壓縮只是把現有代碼變緊湊，但如果你的 CSS 裏有大量根本沒用到的規則，壓縮也幫不了多少。

這在用了 Bootstrap、Tailwind 這類框架之後特別明顯。Bootstrap 完整的 CSS 文件有 200KB 左右，但一個普通項目實際用到的可能不到 10%。

Tailwind 更極端——源文件有 3-4MB，但經過 PurgeCSS（自動掃描 HTML 找出實際用到的 class，刪掉沒用的）之後，生產環境的 CSS 通常只有 10-20KB，縮減超過 99%。

Chrome DevTools 裏有一個 Coverage 面板，可以直接看當前頁面哪些 CSS 規則被用到了、哪些是死代碼：DevTools → 右上角三個點 → More tools → Coverage → 刷新頁面，紅色標記的就是沒有用到的代碼。

什麼時候應該手動壓縮 CSS？

如果你用 Webpack、Vite、Parcel 這類構建工具，壓縮這步通常是自動的，生產構建時會自動處理，不需要手動操作。

手動壓縮工具適合的場景：

項目沒有構建工具，直接寫 HTML+CSS 上傳服務器
接手了別人的老項目，CSS 沒有經過任何優化
臨時想看看某段 CSS 壓縮後的效果
調試時想把壓縮後的 CSS 恢復成可讀格式（反向操作，格式化）

toolshu.com 的 CSS 在線格式化與壓縮工具兩個方向都支持——粘進去一鍵壓縮，或者把壓縮過的生產代碼粘進去格式化成可讀版本，方便排查問題。

一個容易忽略的點：Critical CSS

即使做了所有優化，如果你的 CSS 文件很大，首屏還是會慢——因爲瀏覽器要等整個 CSS 文件加載完才渲染。

進階做法是「Critical CSS」：把首屏需要的那部分 CSS 直接內聯進 HTML 的 <style> 標籤，讓首屏不依賴外部 CSS 文件；其餘的 CSS 異步加載。

<head>
  <!-- 首屏必須的 CSS 直接內聯，不會阻塞渲染 -->
  <style>
    body { margin: 0; font-family: sans-serif; }
    .hero { ... }
  </style>

  <!-- 其餘 CSS 異步加載 -->
  <link rel="preload" href="styles.min.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
</head>

這個方法對首屏速度的提升效果，往往比單純壓縮文件大得多。