TTFB 1334ms 到低於 100ms：行銷官網的正解是 SSG

先給數字：一個牙醫集團的 WordPress 官網，首次回應時間（TTFB）1334ms。搬到 Next.js 靜態生成（SSG）之後，低於 100ms，並以 LCP 低於 1 秒為目標。這不是調了什麼神祕參數，而是架構選擇的直接結果。

這篇講清楚背後的判斷：為什麼行銷官網幾乎都該純靜態、內容更新怎麼處理才對，以及——同樣重要——為什麼我們刻意不用框架最新的快取典範。

TTFB 1334ms 是怎麼來的

TTFB（Time to First Byte）是瀏覽器發出請求後，收到第一個 byte 的時間。傳統 WordPress 的每一次頁面請求，大致要走完：PHP 啟動、載入外掛、查資料庫、組模板、吐 HTML。每一步都要花時間，而且每個訪客每次都重走一遍。

問題是：行銷官網的內容，這個小時和上個小時有什麼不同嗎？絕大多數時候，沒有。你讓伺服器每次都即時重算一份根本沒變的頁面——1334ms 就是這樣累積出來的。

行銷官網的本質：讀多寫少，人人看到的都一樣

判斷一個網站該不該純靜態，看三個特徵：

1. 內容變動頻率低——官網頁面改版以「週」甚至「月」為單位。
2. 讀寫比極度懸殊——訪客成千上萬次讀，內容編輯一週寫幾次。
3. 不需要登入個人化——每個訪客看到的頁面一模一樣。

三條全中，就是 SSG 的教科書場景：build 的時候把所有頁面算好變成靜態檔案，請求進來直接回檔案。沒有資料庫查詢、沒有模板運算，TTFB 自然掉到兩位數毫秒。

行銷官網的效能問題，九成不是要你「優化」，是要你「別動態」。

內容更新呢？事件驅動 revalidation，不要時間輪詢

「純靜態」最常見的反對意見：內容更新怎麼辦？

常見做法是時間輪詢式的重新驗證——每 60 秒讓頁面過期重算一次。能用，但兩頭不討好：更新最多還是要等一個輪詢週期才上線，而內容根本沒變的那幾千個週期，全是白算。

正解是事件驅動：內容「發布」這個動作本身觸發 revalidation——發布了才重算，沒發布就永遠用靜態快取。更新即時、平常零浪費。我們幫這個官網後續疊的 AI 內容引擎（AI 草稿、禁用語自動檢查、人工審核、一鍵發布）就是走這條路：發布動作觸發、對應頁面重生，其餘時間整個站就是純靜態檔案。

什麼時候不要追新典範：cacheComponents 與 7 頁靜態站的現實

講一個反方向的決策。這次遷移用的 Next.js 16 引入了新的快取典範 cacheComponents，是框架未來的方向。我們評估之後決定不開。

理由很簡單：這是一個 7 頁的靜態行銷站。新典範解決的是複雜應用裡動靜混合的快取難題——而一個純靜態站沒有這個問題。開了它，得到的不是效能，是新範式的學習成本、和一條還在演進的 API 帶來的改版風險。

技術選型的紀律：新東西要解決你「實際有」的問題，才值得引入它「一定有」的風險。

尤其這個站還有一個不能出事的前提：Google 廣告持續投放中，整個搬遷的底線是排名一名都不掉、落地頁零中斷。在這種案子裡，穩定可用永遠排在技術嚐鮮前面。

速度不是虛榮指標：它直接連到廣告費

最後講商業面，因為「TTFB 低於 100ms」不是工程師的自我滿足：

• 廣告品質分數：Google Ads 的品質分數包含落地頁體驗，載入速度是其中一環——同樣的出價，頁面快的人拿到更便宜的點擊。
• Core Web Vitals：LCP 這類指標是 Google 排名訊號的一部分，而 TTFB 是 LCP 的地板——第一個 byte 都還沒到，什麼都畫不出來。
• 轉換率：訪客等越久流失越多，這在行動裝置上尤其殘酷。

換句話說：架構選對，省下的不只是伺服器費用，是每一塊廣告費的效率。

如果你的官網也是「後台很重、頁面很慢」的動態架構，而內容其實一個月改不了幾次——這可能是投資報酬率最高的一次改造。我們做過含搬家不掉排名的完整遷移，歡迎聊聊你的狀況。

預約 30 分鐘免費流程診斷 →