網站卡頓元兇抓到了？資深工程師揭秘 WordPress Transients API，一招榨乾資料庫潛在效能！

嗨，我是浪花科技的 Eric。身為一個天天跟 WordPress 程式碼打交道的工程師，最常被問到的問題之一就是：「我的網站裝了快取外掛，為什麼後台還是卡卡的？為什麼某些頁面載入特別慢？」這問題問得好，就像你幫電腦換了顆 SSD，結果開機還是要一分鐘，那種無力感我懂。

很多時候，網站效能的瓶頸不在於那層最外層的頁面快取（Page Cache），而在於心臟地帶——資料庫。每當一個頁面被請求，WordPress 可能需要執行數十甚至上百次的資料庫查詢，去抓取文章、設定、使用者資料等等。如果其中有幾個查詢特別複雜、特別耗時，那它就會成為整個網站的拖油瓶，無論你的頁面快取做得多好，第一次載入或動態內容的生成速度依然會慢得讓人抓狂。

今天，我就要來揭秘一個 WordPress 內建的效能神器，它低調、強大，卻常常被開發者忽略，那就是——Transients API。它不是什麼新潮的黑科技，而是 WordPress 核心中一個優雅的解決方案，專門用來暫時儲存那些耗時操作的結果。搞懂它，你就能像個外科醫生一樣，精準地為你的網站效能進行手術，把那些不必要的資料庫重複查詢通通幹掉。準備好了嗎？讓我們一起來看看這把效能瑞士刀該怎麼用吧！

什麼是 WordPress Transients API？它不是餅乾屑，也不是瀏覽器快取！

在我們動手寫 Code 之前，得先把觀念搞清楚。一聽到「暫存」、「快取」，很多人腦中可能會浮現各種名詞：Page Cache、Object Cache、Browser Cache… 那 Transients 到底算哪一種？

簡單來說，Transients API 是一種用來在 WordPress 資料庫中（或記憶體中）暫時儲存特定資料的機制，而且你可以為這些資料設定一個「保鮮期」（Expiration Date）。 時間一到，資料就會自動失效。

讓我們來把它跟其他快取機制做個區隔，免得大家觀念混亂：

• 頁面快取 (Page Cache): 這是像 WP Rocket 或 W3 Total Cache 這類外掛最主要的功能。它會把整個網頁渲染後的最終 HTML 結果存成一個靜態檔案。當下一個訪客來訪時，伺服器直接丟這個檔案給他，完全不用再跑一次 PHP 和資料庫查詢。速度最快，但只適用於非登入狀態下的靜態內容。
• 瀏覽器快取 (Browser Cache): 這是把網站的靜態資源（如 CSS、JS、圖片）儲存在使用者自己的電腦裡。下次再訪問同一個網站時，就不用重新下載，直接從本機讀取。這是前端優化的範疇。
• 物件快取 (Object Cache): 這是一個更底層的機制。WordPress 有一個內建的物件快取系統 (`WP_Object_Cache`)，它可以在單次頁面載入的生命週期內，快取資料庫查詢的結果，避免同一個查詢在同一次請求中重複執行。Transients API 正是建立在這個系統之上。

這裡就是關鍵了！Transients API 利用了物件快取系統，但又更進一步：它可以把資料「持久化」儲存，跨越不同的頁面請求。它的運作模式是這樣的：

1. 當你設定一個 Transient 時，WordPress 會先檢查你的主機環境有沒有安裝外部的持久化物件快取系統，例如 Redis 或 Memcached。
2. 如果有的話，太棒了！Transient 會被直接存入這些高效能的記憶體快取中。讀寫速度極快，對資料庫完全沒負擔。
3. 如果沒有的話，沒關係，WordPress 還有備案。它會把 Transient 的資料序列化後，存進資料庫的 `wp_options` 資料表中。雖然速度不如記憶體快取，但依然遠比每次都重新執行複雜的運算或查詢來得快。

所以，你可以把 Transients API 想像成一個聰明的資料置物櫃。當你需要一個很花時間才拿得到的東西（例如一個複雜的報表數據），你第一次拿到後，就把它連同一個到期時間標籤一起放進這個置物櫃。在到期之前，你每次都直接從置物櫃拿，而不是再跑一次那個耗時的流程。

Transients API 的三大核心函式：設定、取得、刪除

Transients API 的精髓就在於它極簡的設計，基本上你只需要學會三個函式，就能解決 80% 的問題。身為工程師，最喜歡這種簡單直接的工具了。

1. 設定 Transient：`set_transient()`

這個函式用來儲存你的資料。它有三個參數：

• $transient (string): Transient 的唯一名稱（Key）。把它想像成置物櫃的鑰匙，必須是獨一無二的。
• $value (mixed): 你想要儲存的資料。可以是字串、數字、陣列，甚至是物件。WordPress 會自動幫你處理序列化。
• $expiration (int): 過期時間，單位是秒。你可以直接寫秒數，但更專業的做法是使用 WordPress 提供的時間常數，可讀性更高。

程式碼範例： 假設我們要快取一個包含熱門文章 ID 的陣列，快取時間為 12 小時。

<?php
$popular_posts_ids = [101, 25, 33, 8, 92];

// 設定一個名為 'my_popular_posts' 的 transient，並設定 12 小時後過期
// HOUR_IN_SECONDS 是 WordPress 內建的常數，等於 3600
set_transient( 'my_popular_posts', $popular_posts_ids, 12 * HOUR_IN_SECONDS );
?>

2. 取得 Transient：`get_transient()`

這個函式用來讀取你之前儲存的資料。它只有一個參數：

• $transient (string): 你要讀取的 Transient 的名稱（Key）。

如果資料存在且尚未過期，它會回傳你儲存的資料。如果資料不存在或已過期，它會回傳 `false`。

這個 `false` 的回傳值就是整個模式的核心。我們的標準作業流程（SOP）通常是：

1. 先試著用 `get_transient()` 拿資料。
2. 檢查回傳值。如果不是 `false`，代表快取命中，直接使用這個資料。
3. 如果是 `false`，代表快取未命中或已過期。這時候才去執行那個耗時的操作（例如查詢資料庫或 call API）。
4. 拿到新的資料後，立刻用 `set_transient()` 把它存起來，供下次使用。

程式碼範例： 經典的「先檢查快取，沒有才生成」模式。

<?php
// 嘗試從 transient 取得熱門文章資料
$popular_posts = get_transient( 'my_popular_posts' );

// 檢查 transient 是否存在
if ( false === $popular_posts ) {
    // 如果不存在，就執行耗時的資料庫查詢
    $popular_posts = new WP_Query( [
        'posts_per_page' => 5,
        'meta_key'       => 'post_views_count',
        'orderby'        => 'meta_value_num',
        'order'          => 'DESC'
    ] );

    // 將查詢結果存入 transient，設定 12 小時後過期
    set_transient( 'my_popular_posts', $popular_posts, 12 * HOUR_IN_SECONDS );
}

// 現在 $popular_posts 變數中肯定有資料了，可以開始使用它來渲染你的迴圈
if ( $popular_posts->have_posts() ) {
    // ... 你的迴圈程式碼 ...
}
?>

3. 刪除 Transient：`delete_transient()`

有時候，你需要在資料過期前就主動清除它。例如，當一篇文章更新後，跟它相關的快取就應該馬上失效，才能顯示最新的內容。這時候就需要 `delete_transient()`。

程式碼範例： 當有新文章發布或舊文章更新時，清除我們的熱門文章快取。

<?php
add_action( 'save_post', 'clear_popular_posts_transient' );

function clear_popular_posts_transient() {
    // 刪除名為 'my_popular_posts' 的 transient
    delete_transient( 'my_popular_posts' );
}
?>

Transients API 實戰應用場景：別再讓你的資料庫跑腿跑到過勞！

理論講完了，來點實際的。到底在哪些地方，Transients API 可以發揮奇效呢？

場景一：快取複雜的 `WP_Query` 迴圈

就像上面的例子，網站側邊欄的「熱門文章」、「最新留言」、「相關產品」等區塊，通常都包含複雜的資料庫查詢。這些區塊在每個頁面都會顯示，如果每次都重新查詢，對資料庫的壓力可想而知。用 Transient 把查詢結果快取 10-15 分鐘，就能大幅降低伺服器負載。

場景二：快取遠端 API 的回應

你的網站是否需要顯示來自外部服務的資料？例如：

• 顯示 Instagram 的最新貼文牆。
• 顯示即時的匯率或股價資訊。
• 顯示天氣預報。

每次頁面載入都去 call 外部 API 是非常糟糕的做法。第一，網路延遲會拖慢你的網站速度；第二，很多 API 都有請求頻率限制（Rate Limit），call 太頻繁會被暫時封鎖。這時候，把 API 的回傳結果（通常是 JSON）存到 Transient 裡，設定 5 分鐘或 1 小時的過期時間，是最聰明也最安全的做法。

場景三：快取耗時的運算結果

有時候，拖慢網站的不是資料庫查詢，而是複雜的 PHP 運算。例如，從大量的訂單資料中，計算出一個複雜的銷售統計報表。這個計算過程可能需要幾秒鐘。如果每次管理者重新整理儀表板都要重新算一次，體驗會非常差。把計算結果存入 Transient，只有在訂單有更新時才刪除並重新計算，就能讓儀表板秒開。

工程師的囉嗦時間：Transients API 的陷阱與最佳實踐

工具雖好，但也要用對方法。這裡有幾個身為資深工程師，不得不囉嗦幾句的重點：

陷阱一：過期時間不是保證！

千萬記住，你設定的 `expiration` 是一個「最長」存活時間，不是「保證」存活時間。如果你的網站使用了 Redis 或 Memcached 這樣的外部物件快取，當記憶體不足時，快取系統可能會根據自己的演算法（例如 LRU, Least Recently Used）提前把一些比較少用的快取清掉。所以，你的程式碼邏輯永遠要假設 `get_transient()` 有可能回傳 `false`，並且要有能力重新生成資料。

陷阱二：小心 `wp_options` 表的「自動載入」(Autoload)

當沒有外部物件快取時，Transients 會存在 `wp_options`。WordPress 在每次載入時，都會把 `wp_options` 裡 `autoload` 欄位為 `yes` 的所有設定一次性撈到記憶體中。好消息是，Transients API 很聰明，它存進去的資料 `autoload` 都是 `no`，所以不會造成這個問題。但這提醒了我們，如果你想自己手動用 `update_option()` 來做快取，千萬記得要用 `update_option(‘my_key’, $value, ‘no’)` 來避免污染自動載入的資料。

陷阱三：Key 的命名藝術

Transient 的 key 是全域性的。如果你寫了一個外掛，key 叫做 `latest_posts`，那很可能會跟其他外掛或佈景主題「撞名」，導致快取互相覆蓋。最佳實踐是加上獨特的前綴，例如 `roamer_plugin_latest_posts`。如果快取的內容跟特定文章有關，也要把文章 ID 加進 key 裡，例如 `roamer_related_posts_{$post_id}`，確保每個頁面的快取都是獨立的。

最佳實踐：搭配 Object Cache 才能發揮十成功力

再強調一次，Transients API 在只用資料庫當後端的狀況下就已經很有幫助了。但它的真正潛力，需要搭配 Redis 或 Memcached 這樣的持久化物件快取才能完全解放。把快取從資料庫 I/O 操作轉為記憶體操作，效能是不同維度的提升。如果你對伺服器有控制權，強烈建議花點時間把物件快取設定起來，你的 WordPress 會感謝你的。

結論：Transients API 是你的效能瑞士刀

Transients API 不是萬靈丹，它無法取代完整的頁面快取策略。但它是一把精準、鋒利的手術刀，讓身為開發者的我們，能夠深入程式碼的內部，找出那些重複且耗時的操作，並用一種優雅、低侵入性的方式將其優化。

從今天起，當你寫下任何一段耗時的程式碼，無論是複雜的 `WP_Query`、呼叫外部 API，還是大量的數據運算，請先停下來問問自己：「這個結果，真的需要每次都重新計算嗎？我能把它放進 Transient 裡嗎？」養成這個習慣，你的程式碼品質和網站效能，都會提升到一個新的層次。

當然，網站效能優化是個無底洞，牽涉到前後端、伺服器、資料庫等多個層面。如果你覺得自己的網站卡頓問題很棘手，或是需要更深度的客製化開發來解決效能瓶頸，別客氣，浪花科技的團隊都在這裡。

覺得你的網站效能還有提升空間嗎？

從複雜的資料庫查詢優化到伺服器架構調整，我們有豐富的實戰經驗。如果你正面臨效能瓶頸，或是有任何 WordPress 客製化開發的需求，歡迎與我們聯繫，讓浪花科技的專業團隊為你打造一個飛快的網站！

---

延伸閱讀：

• 網站慢到捶心肝？別再只會裝快取外掛！資深工程師揭秘 WordPress 效能雙核心：Page Cache vs. Object Cache 終極對決
• 網站慢到想哭？解鎖 WordPress 終極加速密技：Redis 物件快取實戰教學
• WP_Query 不是只會 `post_type`！資深工程師的進階查詢食譜，從 Meta Query 到效能調校的屠龍術