🎯 什麼情境該想到我

當網站/頁面「載入很慢、首屏遲遲不出來」,你想知道從哪裡下手優化時。

⚙️ 怎麼用

黃金法則:多數載入時間在前端 → 先優化前端(比調後端 CP 值高)。核心是減少往返次數。

  1. 減少 HTTP 請求:合併 JS/CSS、用 CSS sprites、行內小圖(越少往返越快)。
  2. JS 放底部、CSS 放頂部:避免腳本阻塞頁面渲染。
  3. 壓縮傳輸:開 Gzip/Brotli,縮小 JS/CSS/圖片。
  4. 用 CDN:靜態資源就近提供,降低延遲。
  5. 先量測再優化:用瀏覽器開發者工具/效能瀑布圖找真正的瓶頸資源。

★ 書中的 14 條規則,今天還剩多少

《高性能網站建設指南》(Steve Souders,2007)的 14 條規則,在 HTTP/2、HTTP/3 與現代瀏覽器之下重新評估:

#規則今天理由
1減少 HTTP 請求數⚠️ 部分過時HTTP/1.1 下瀏覽器對同一主機只開少數幾條連線,請求多就排隊。HTTP/2 在一條連線上多工,合併檔案、CSS sprites 的收益大幅降低;但往返次數仍然重要
2使用 CDN✅ 仍然有效物理距離決定延遲
3加上 Expires/快取標頭✅ 仍然有效改用 Cache-Control(見 工具-快取與資源優化)
4Gzip 壓縮✅ 仍然有效現在多用 Brotli,壓縮率更好
5CSS 放頂部✅ 仍然有效避免無樣式內容閃爍
6JS 放底部✅ 概念有效,做法改變改用 <script defer> 或 type="module"(預設延遲執行),不必真的放在底部
7避免 CSS 運算式❌ 已消失那是舊版 IE 的功能
8JS 與 CSS 放外部檔案✅ 大致有效例外:首屏的關鍵 CSS 常內嵌,省一個往返
9減少 DNS 查詢✅ 仍然有效也可用 <link rel="preconnect"> 提前連線
10最小化 JS✅ 仍然有效建置工具預設就會做
11避免重新導向✅ 仍然有效每次重導向多一個完整往返
12移除重複的腳本✅ 仍然有效現代打包工具大多會處理
13設定 ETag✅ 有效,但要設對多台伺服器的 ETag 若包含伺服器特有的資訊,會導致驗證永遠失敗
14讓 Ajax 可被快取✅ 仍然有效現在是 fetch 回應的快取標頭

不變的核心:書的黃金法則「大部分的載入時間花在前端」和「減少往返」仍然成立。變的是達成手段。

★ 今天的量尺:Core Web Vitals

Google 定義的三個核心指標與「良好」門檻(依 web.dev,2026-09-25 查證):

指標量什麼良好門檻
LCP(Largest Contentful Paint)載入:最大的內容元素多久出現≤ 2.5 秒
INP(Interaction to Next Paint)互動:使用者操作到畫面更新多久≤ 200 毫秒
CLS(Cumulative Layout Shift)視覺穩定:版面跳動的程度≤ 0.1
  • 評估方式是看第 75 百分位的頁面載入,分行動裝置與桌機——不是平均,也不是你自己的高速電腦。
  • INP 取代了早期的 FID(First Input Delay)。

對應到這張卡的規則:LCP 主要受規則 1–6、9、11 影響(資源下載與阻塞);INP 受 JavaScript 執行量影響(書出版時還不是主要問題);CLS 則是新的關注點——圖片與廣告要預留空間(設 width/height 或 aspect-ratio)。

★ 量測的工具鏈

工具量什麼什麼時候用
瀏覽器開發者工具的 Network 瀑布圖每個資源的時間、阻塞、順序找出是哪個資源拖慢
Lighthouse實驗室環境的模擬分數開發時快速檢查
真實使用者監測(RUM),例如 web-vitals 函式庫真實使用者的 LCP/INP/CLS上線後——實驗室分數好不代表真實使用者體驗好

🧪 我實際套用的紀錄

  • 2026-07-15:(待填)

⚠️ 注意

  • 書中細節(如某些 HTTP/1 技巧)在 HTTP/2 後有變;但「減少往返、量測導向」的原則不變。

  • SPA 的陷阱:單頁應用把大部分工作搬到 JavaScript,首屏要下載、解析、執行一大包 JS 才能顯示內容。書的規則管不到這個——需要伺服器端渲染、程式碼分割、減少 JS 體積。

🔗 相關工具