網站一慢，很多人第一個反應就是：「是不是主機不夠快？」
於是開始升級 CPU、記憶體、VPS 規格，甚至直接搬主機。
有時候這確實有用。
但也有不少網站換了更貴的主機，首頁還是慢。
原因很簡單：主機只是整條速度鏈的一段。
從使用者輸入網址，到畫面可以看、可以點，中間還有很多步驟。
《High Performance Browser Networking》最值得帶走的觀念，就是網站效能不能只看伺服器，而要看「整條網路與瀏覽器路徑」。
一個網頁打開之前，到底發生了什麼？
簡化來看，瀏覽器至少會經過以下幾段。
一、先找到網域對應的 IP，也就是 DNS 查詢。
二、和伺服器建立連線。
三、如果是 HTTPS，還要完成 TLS 加密協商。
四、送出 HTTP 請求。
五、等待伺服器回傳 HTML。
六、瀏覽器解析 HTML，接著發現 CSS、JavaScript、字型、圖片等資源。
七、繼續下載這些資源。
八、建立頁面結構、樣式與版面，最後才畫到螢幕上。
所以「主機回應很快」和「使用者覺得網站很快」不是同一件事。
第一個瓶頸：網域查詢太慢，主機再快也還沒輪到它
瀏覽器在連到主機之前，必須先知道這個網域在哪裡。
這就是網域名稱系統（Domain Name System，DNS）的工作。
如果 DNS 查詢很慢，使用者會先在這裡等。
而且頁面如果用了很多不同網域，例如：
主站一個。
字型一個。
分析工具一個。
廣告或第三方腳本又一個。
每一個新網域都可能產生額外查詢與連線成本。
所以優化網站速度時，不只是看主機在哪裡，也要看頁面到底連了多少外部來源。
第二個瓶頸：網路延遲，比頻寬更容易被忽略
頻寬可以想成道路有多寬。
延遲則像「從 A 地到 B 地要多久」。
道路再寬，距離還是存在。
對很多網頁請求來說，最浪費時間的是反覆來回等待；檔案大小只是其中一個因素。
這也是為什麼 CDN 有時候能明顯改善速度。
它除了提供傳輸能力，也會把內容放到更接近使用者的位置，減少網路來回距離。
第三個瓶頸：建立連線與加密協商都需要時間
網站使用 HTTPS 時，資料開始正式傳送以前，還需要建立連線與安全協商。
這些動作都要經過網路往返。
現代協定已經比早期有效率很多，例如 TLS 1.3 可以減少連線建立的往返次數。
但基本原則沒有改變：
連線越多、來源越分散、延遲越高，前置成本就越明顯。
因此現代網站通常會盡量重複使用既有連線，而不是為每個小檔案重新建立一套連線。
不同 HTTP 版本解決的，是連線與傳輸方式的效率
HTTP/1.1 時代，瀏覽器為了同時下載多個資源，常常需要開多條連線。
HTTP/2 可以在同一條連線上同時傳送多個資料流，降低大量小資源互相等待的問題。
HTTP/3 則建立在 QUIC 之上，進一步改善連線與封包遺失時的阻塞情況。
這也是為什麼有些早期網站效能技巧，到了 HTTP/2、HTTP/3 時代反而不一定適合。
例如過度把資源拆到很多子網域，可能讓瀏覽器重新付出 DNS、連線與 TLS 成本。
第四個瓶頸：伺服器第一個位元組來得太慢
收到第一個位元組的時間（Time to First Byte，TTFB）比較接近大家直覺認為的「主機速度」。
它會受到很多因素影響：
主機資源。
PHP 或應用程式執行時間。
資料庫查詢。
快取是否命中。
外部 API。
伺服器和使用者距離。
CDN 與反向代理設定。
所以 TTFB 很慢時，主機或後端確實值得檢查。
但 TTFB 很快，也不代表頁面後面一定快。
第五個瓶頸：瀏覽器拿到網頁內容後，才開始發現更多工作
HTML 回來後，瀏覽器才知道還需要下載哪些 CSS、JavaScript、圖片、字型和其他資源。
如果最重要的圖片藏在很深的 CSS 或 JavaScript 裡，瀏覽器會晚一點才發現。
如果 CSS 很大，而且全部阻塞畫面，使用者也要等。
如果同步 JavaScript 卡住 HTML 解析，畫面同樣會延後。
所以網站速度不能只用「首頁檔案總共幾 MB」判斷。
第三方腳本也可能把前台拖慢
分析工具、聊天工具、廣告追蹤、社群嵌入、A/B 測試與各種外部小工具，都可能額外增加 DNS、連線、下載與 JavaScript 執行成本。
這類資源最麻煩的地方，是你通常無法控制對方伺服器速度，也不能保證每次回應都一樣快。
所以第三方腳本要定期盤點。
真的需要的保留。
非首屏必要的延後載入。
已經不用的直接移除。
如果某個外部來源是首屏一定會用到，也可以用預連線（preconnect）提早建立連線，減少需要抓資源時才開始等待。
預載入只給關鍵資源
預載入（preload）可以讓瀏覽器提早抓重要資源，例如首屏字型或 LCP 圖片。
但它不是「開越多越快」。
每一個被提到高優先權的資源，都會和其他下載競爭。
所以只應該把首屏確實需要、而且瀏覽器可能太晚發現的資源提前。
資源被瀏覽器發現的順序，也很重要。
主要內容顯示太慢，不一定只是圖片檔案太大
最大內容繪製（Largest Contentful Paint，LCP）衡量主要內容何時實際顯示。
Google 目前建議至少 75% 的實際瀏覽中，LCP 維持在 2.5 秒內。這個門檻截至目前仍然是 Core Web Vitals 的「良好」標準。
LCP 常見元素可能是 Hero 圖片、大標題或大型內容區塊。
但一張圖片就算壓縮得很好，如果瀏覽器很晚才發現它、優先權太低，或者 JavaScript 要等很久才把它顯示出來，LCP 還是會差。
所以 LCP 要拆開看：
伺服器是不是太晚回 HTML？
瀏覽器是不是太晚發現 LCP 資源？
資源本身是不是下載太久？
下載完之後是不是又被腳本或樣式延後顯示？
這比只說「圖片太大」更接近問題核心。
第六個瓶頸：腳本太多，使用者點了卻沒有反應
網站看起來已經出現，不代表它已經好用。
如果瀏覽器主執行緒被大量 JavaScript 占住，使用者點按鈕、打字或開選單時，可能要等一段時間才有反應。
互動至下一個顯示的時間（Interaction to Next Paint，INP）就是在看這件事。
Google 目前把 200 毫秒以下視為良好，並以實際使用者第 75 百分位作為判斷基準。
改善 INP 常見方向包括：
減少不必要 JavaScript。
延後非關鍵腳本。
把很長的工作拆成較短工作。
避免第三方工具長時間占用主執行緒。
精簡過大的 DOM 與複雜前端操作。
所以有些網站「載入很快，但點起來很頓」，主機升級幫助就有限。
第七個瓶頸：畫面一直跳，速度分數也會受影響
累計版面配置位移（Cumulative Layout Shift，CLS）衡量畫面穩定程度。
目前良好標準仍是 0.1 以下。
常見問題包括：
圖片沒有預留寬高。
嵌入影片載入後突然撐開。
廣告或動態區塊插進內容上方。
字型載入後文字尺寸大幅改變。
CLS 和主機 CPU 幾乎不是同一類問題。
它更接近前端排版與資源載入策略。
快取的核心：最快的請求，是不用再發一次
快取（Cache）是網站效能裡非常重要的一層。
瀏覽器可以快取。
CDN 可以快取。
伺服器可以做頁面快取。
應用程式也可以做物件快取。
這些快取解決的問題不同。
例如靜態 CSS、JavaScript、圖片如果檔名帶版本雜湊，就可以設定很長的快取時間。
檔案更新時換檔名，瀏覽器自然會抓新版本。
這比每次重新下載同一份檔案有效率得多。
WordPress 網站的多層快取要注意什麼？
WordPress 常同時有：
頁面快取。
物件快取。
瀏覽器快取。
CDN 快取。
主機端快取。
這些東西並不是越多越快。
設定不一致時，反而可能出現舊內容、登入狀態錯亂、購物車被快取、更新後前台沒變等問題。
所以網站速度優化需要知道每一層在快取什麼，不是一直加外掛。
壓縮也有兩種：檔案本身和傳輸內容
圖片壓縮大家比較熟悉。
但 HTML、CSS、JavaScript、JSON 等文字內容，也可以透過 Brotli 或 Gzip 壓縮後再傳送。
圖片則更適合從尺寸、格式與品質下手，例如 WebP、AVIF、響應式圖片和正確顯示尺寸。
兩者不要混在一起理解。
把 3000 像素照片塞進 400 像素卡片，再開 Brotli，不會解決圖片本身浪費的流量。
延遲載入不是所有圖片都適合
Lazy Load 很有用，但用錯位置也會讓網站變慢。
首屏以外的圖片適合延遲載入。
但如果 Hero 圖片就是 LCP 元素，卻把它也設成 Lazy Load，瀏覽器可能反而更晚才開始下載。
重要資源要提早。
次要資源才延後。
這比「全部都 Lazy Load」更合理。
效能優化要看真實使用者，不要只看自己電腦
辦公室用高速網路和新款電腦測起來很快，不代表所有人都一樣。
實際使用者可能用：
中階手機。
行動網路。
較遠地區。
較慢 CPU。
背景同時執行很多 App。
因此 Core Web Vitals 很重視實際環境資料，而不是只看單次實驗室分數。
Lighthouse 很適合找問題。
但如果要判斷真實體驗，還要看 Chrome UX Report、PageSpeed Insights 的實際資料，或自己的 Real User Monitoring。
網站慢時，建議照這個順序檢查
第一步：先看 TTFB。
如果 HTML 本身就很晚回來，再檢查主機、後端、資料庫、頁面快取與 CDN。
第二步：看 LCP。
確認首屏最大元素是什麼，以及瀏覽器何時開始下載它。
第三步：看 INP。
如果頁面出現後互動很鈍，檢查 JavaScript、第三方腳本與主執行緒工作。
第四步：看 CLS。
找出圖片、嵌入內容、字型或動態區塊造成的位移。
第五步：看資源瀑布圖。
檢查 DNS、連線、等待、下載、第三方來源，以及哪些請求互相卡住。
第六步：檢查快取與壓縮。
確認靜態資源能不能長期快取、文字內容有沒有 Brotli 或 Gzip。
第七步：才決定要不要升級主機。
如果瓶頸明確在後端或資源不足，升級才有意義。
換主機有用的情況，通常長什麼樣？
以下狀況比較值得懷疑主機或後端。
未快取頁面的 TTFB 長期偏高。
PHP 執行與資料庫查詢明顯很慢。
高峰期 CPU、記憶體或 I/O 常常滿載。
同一套網站搬到效能更好的環境後，後端時間明顯縮短。
伺服器距離使用者過遠，而且沒有 CDN 協助。
這些情況升級主機可能有效。
但如果問題是 Hero 圖片載入太晚、JavaScript 阻塞、第三方追蹤碼很多或版面位移，那就要從前端與資源策略處理。
速度優化最後還是要回到使用者和事業結果
速度不是只為了拿高分。
頁面太慢，訪客可能還沒看到主張就離開。
按鈕反應慢，會降低操作信心。
結帳頁一直跳動，甚至可能造成誤按。
這些最後都會影響名單、成交與信任。
如果網站已經有流量，可以搭配 網站有流量卻沒有名單與成交？網站成長應該優化什麼 一起檢查，不要把效能和轉換完全分開。
網站速度慢，不要先問「哪一家主機最快」
更有效的問題是：
慢在哪一段？
DNS？
連線？
TLS？
伺服器回應？
圖片？
CSS？
JavaScript？
快取？
還是瀏覽器渲染？
只要把問題定位清楚，很多速度問題其實不用換主機就能改善。
反過來，如果數據真的指向後端資源不足，那時候再升級主機，才是在解主要瓶頸。
常見問題
網站速度慢，第一步是不是先升級主機？
不一定。先看 TTFB、LCP、INP、CLS 和瀏覽器 Network 瀑布圖。只有當瓶頸明確出現在後端處理、資源不足或伺服器距離時，升級主機才比較可能直接有效。
網站體驗核心指標現在看哪些項目？
目前三個核心指標是 LCP、INP 與 CLS。良好門檻分別是 LCP 2.5 秒以下、INP 200 毫秒以下、CLS 0.1 以下，並建議用第 75 百分位的實際使用者資料判斷。
用了內容傳遞網路，網站就一定會變快嗎？
不一定。CDN 很適合縮短靜態資源距離、快取內容與改善網路傳輸，但如果瓶頸在後端運算、JavaScript、資料庫、第三方腳本或渲染，仍然需要處理原本的問題。
延遲載入開越多越好嗎？
不是。首屏以下圖片很適合延遲載入，但如果 LCP 的 Hero 圖片也被延遲，反而可能讓重要畫面更晚出現。關鍵資源應提早載入，次要資源再延後。
網站測速分數高，就代表所有使用者都很快嗎？
不一定。實驗室測試適合找問題，但不同裝置、網路、地區和使用情境差異很大。要了解真實體驗，還要看 CrUX 或自己的實際使用者監測資料。
參考資料
Ilya Grigorik. High Performance Browser Networking: What Every Web Developer Should Know About Networking and Web Performance.
Ilya Grigorik. High Performance Browser Networking. hpbn.co.
web.dev. “Optimize Largest Contentful Paint.” Last updated March 31, 2025.
web.dev. “Optimize Interaction to Next Paint.” Last updated September 2, 2025.
web.dev. “Optimize Cumulative Layout Shift.” Last updated February 7, 2025.
MDN Web Docs. “HTTP.”