如何為您的 WordPress 網站配置 W3 總緩存設置

已發表: 2020-08-24

W3 Total Cache 擁有超過 100 萬個活動安裝，是 WordPress 存儲庫中最受歡迎的緩存和優化插件之一。與其他提供相對簡單和流線型界面的 WordPress 優化插件不同，W3 Total Cache 可以完全控制您的 WordPress 站點的緩存配置。

W3TC 設置的粒度使其成為希望最終控制其 WordPress 網站的高級用戶和開發人員的理想插件。在本文中，我們將深入了解 W3 Total Cache 的設置，並為您提供我們推薦的配置，以提高您的 WordPress 網站的性能。

如果您是 Kinsta 用戶，則不需要在 W3 Total Cache 中配置某些設置，因為我們的託管堆棧已經內置了許多優化。例如，所有 Kinsta 站點默認啟用通過 NGINX 的服務器級頁面緩存，因此您無需在 W3 Total Cache 中啟用它。如果您在 Kinsta 託管的網站上設置 W3TC，只需特別注意下面的設置說明。如果不需要特定設置或與 Kinsta 兼容，我們一定會通知您。

如何安裝 W3 總緩存

如果您的站點上沒有安裝 W3 Total Cache，您可以直接在您的 WordPress 儀表板中安裝它。只需在“添加插件”頁面搜索“W3 Total Cache”並安裝即可。

還有一個專業版的 W3 Total Cache，可以在 BoldGrid 的網站上購買。專業版帶有一些額外的功能，如 REST API 緩存、谷歌地圖緩存和額外的擴展。在本文中，我們將使用 WordPress 插件存儲庫中的免費版本。

使用本 W3 總緩存設置指南提高您的#WordPress 網站的性能並控制高級功能️ 點擊推文

W3 總緩存設置存儲在哪裡？

安裝 W3 Total Cache 後，您將在 WordPress 管理儀表板的側欄中看到“性能”選項卡。單擊“性能”選項卡將顯示各種子菜單，例如“常規設置”、“頁面緩存”、“縮小”等。

您還可以使用 WordPress 管理工具欄中的“性能”選項卡訪問 W3 Total Cache 設置。

如何清除 W3 總緩存

在我們了解如何配置 W3 Total Cache 之前，讓我們快速了解一下如何清除或清除緩存。如果您將鼠標懸停在管理工具欄中的“性能”選項卡上，您將看到兩個清除選項。

清除所有緩存 -一次清除所有緩存。
清除模塊——清除單個緩存（例如縮小資產、頁面緩存、對象緩存等）。

W3 總緩存常規設置

讓我們深入了解 W3 Total Cache 的“常規設置”菜單來配置一些基本設置。

頁面緩存

默認情況下，對您的 WordPress 網站的每個請求都是實時呈現的。對於某些類型的網站，例如電子商務商店或論壇，動態呈現是理想的選擇。但是，對於博客、新聞站點和其他不需要動態內容的站點，添加頁面緩存層可以提高性能並減少服務器負載。

如果您的網站託管在 Kinsta 上，則不必擔心頁面緩存。我們有一個高性能的服務器級配置，可以自動將您網站的頁面緩存到靜態 HTML 文件中。如果您的主機不提供頁面緩存，您可以在 W3 Total Cache 插件中啟用頁面緩存。

縮小

縮小 HTML、CSS 和 JavaScript 資產可以通過刪除不必要的空白來減小網站頁面的整體大小。對於大多數 WordPress 網站，啟用 W3 Total Cache 的“縮小”功能並為“縮小模式”選擇“自動”選項就可以了。

在某些情況下，縮小資產可能會導致 CSS 或 JavaScript 代碼中斷，這通常會導致前端出現明顯的錯誤。如果您在縮小資產後發現網站上出現異常問題，我們建議您與開發人員一起確定導致問題的資產。之後，您可以在手動模式下使用“縮小”功能，該功能允許您繞過特定 CSS 和 JavaScript 文件的縮小。

操作碼緩存

WordPress 是一個動態的 CMS，這意味著 PHP 工作者在後台不斷地執行代碼。操作碼緩存通過存儲已編譯的 PHP 代碼來幫助加速您的站點，這使得需要相同代碼的後續請求更快。

如果您的站點託管在 Kinsta 上，則不必擔心在 W3 Total Cache 中啟用操作碼緩存層。我們在所有實時環境中啟用 OPcache，一種操作碼緩存。暫存環境中禁用了 OPcache，以確保編譯的 PHP 代碼不會被緩存並且不會干擾站點開發和調試。

如果您的主機不提供操作碼緩存，我們建議在 W3 Total Cache 中啟用它。請記住，操作碼緩存功能僅在 W3TC 的專業版中可用。

數據庫緩存

W3TC 的數據庫存儲 MySQL 數據庫查詢的結果。雖然此功能聽起來很有用，但我們建議將其禁用並改用對象緩存。

我們發現在某些情況下，數據庫緩存功能可能會導致 CPU 使用率過高。這意味著通過存儲數據庫查詢結果節省的 CPU 量最終可能會被此功能所需的 CPU 增加所抵消。

對象緩存

在 WordPress 的上下文中，對象緩存存儲已完成的數據庫查詢的結果。 WordPress 實際上有一個內置的對象緩存，但它只保留單個頁面加載的數據。這允許更有效的頁面呈現，因為它確保頁面加載不需要浪費 CPU 資源來運行相同的數據庫查詢。

雖然 WordPress 的默認對象緩存無疑對性能有好處，但在頁面加載期間保留數據的對象緩存會更好！ W3TC 的“對象緩存”功能在您的/wp-content目錄中添加自定義緩存腳本，並更改 WordPress 對象緩存的行為以持久保留數據（跨多個頁面加載）。

如果您的網站未託管在 Kinsta 上，我們建議在您的 WordPress 網站上啟用 W3TC 的對象緩存功能，以加快利用數據庫查詢的請求。

如果您的站點託管在 Kinsta 上，我們會提供由我們的 Redis 插件提供支持的高性能對象緩存層。 Redis 是一種開源的內存數據結構存儲，通常用於數據庫和消息代理應用程序。

由於 Redis 將數據緩存在 RAM 中，因此它允許 WordPress 從持久對象緩存中訪問緩存數據，這比傳統的對象緩存配置要快得多。

瀏覽器緩存

瀏覽器緩存可以通過在本地存儲 CSS、JavaScript、圖像和字體等靜態資產來顯著加快 WordPress 網站的速度。瀏覽器緩存使用過期時間來確定緩存資產的時間。在現代 Web 上，大多數開發人員指定靜態資產的有效期為 1 年。

對於託管在 Kinsta 上的網站，我們對靜態文件強制執行 1 年的緩存期。這可以通過檢查託管在 Kinsta 上的靜態文件的cache-control標頭來驗證。如果您的 Web 主機沒有為瀏覽器緩存強制執行“遠期到期時間”，您可以啟用 W3 Total Cache 中的“瀏覽器緩存”功能並配置到期期限。

CDN（內容交付網絡）

如果您使用 CDN 或內容交付網絡將靜態文件卸載到世界各地的數據中心，您可以配置 W3 Total Cache 以重寫“主題文件、媒體庫附件、CSS、JS”的 URL 等CDN 主機名。

如果您的網站託管在 Kinsta 上，我們建議使用 Kinsta CDN，這是我們由 KeyCDN 提供支持的高性能內容交付網絡。啟用 Kinsta CDN 後，將自動重寫靜態文件 URL 以從 Kinsta CDN 提供服務。

如果您更喜歡使用其他 CDN 提供商，或者您的網站未託管在 Kinsta 上，您可以在 W3 Total Cache 中啟用“CDN”功能並添加您的 CDN URL。

反向代理

反向代理位於您的 Web 服務器和 WordPress 之間，可用於對傳入請求執行各種基於邏輯的操作。 W3TC 支持 Varnish，這是一種流行的“HTTP 加速器”，用於緩存和提供數據，以減少後端負載。

為了使用 Varnish，您的主機必須首先安裝 Varnish 包。如果您是 Kinsta 客戶，請不要啟用反向代理選項，因為我們的基礎架構並非旨在與 Varnish 一起使用。

用戶體驗

W3TC 的“用戶體驗”優化讓您可以啟用延遲加載、禁用表情符號和禁用wp-embed.js腳本。我們建議在您的 WordPress 網站上啟用延遲加載以加快頁面加載速度。如果您尚未使用瀏覽器原生或基於插件的延遲加載，我們建議使用 W3 Total Cache 進行延遲加載。

在當今世界，大多數操作系統都內置了對錶情符號的支持。因此，如果您不是重度表情符號用戶，您可能希望禁用 WordPress 包含的表情符號腳本。使用 W3TC 刪除wp-emoji-release.min.js將幫助您減少 HTTP 請求並從頁面加載中刪除約 10KB。

同樣，如果您不嵌入 WordPress 帖子，您可以使用 W3 Total Cache 禁用wp-embed.js 。禁用此腳本不會影響嵌入 YouTube 視頻、SoundCloud 流等的 oEmbed 功能。

各種各樣的

W3 Total Cache 有一些您也可以配置的雜項設置。如果您想在 WordPress 中顯示 Google Page Speed 儀表板小部件，您可以輸入您的 Page Speed API 密鑰。還有一個選項可以在 WordPress 網站上的每個頁面的菜單欄中顯示頁面速度評級。

對於其他設置，如“NGINX 服務器配置文件路徑”、“啟用文件鎖定”、“優化磁盤增強頁面和縮小 NFS 磁盤緩存”，我們建議將它們保留在默認設置中，除非您有特定原因要更改它們。

調試

如果您正在對站點上的問題進行故障排除，W3 Total Cache 有一個方便的“調試”菜單，可讓您禁用特定的緩存層和優化設置。例如，如果您發現網站出現視覺故障，您可以為“縮小”選項啟用調試模式，該選項會將 HTML 註釋插入頁面的源代碼以幫助您進行故障排除。

由於調試模式功能會給您的服務器資源帶來額外的負載，我們建議僅在暫存環境或低流量時段使用它。此外，請務必在完成故障排除後禁用調試模式！

導入/導出設置

完成設置配置後，您可以使用 W3TC 的“導入/導出”功能創建配置備份。 W3 Total Cache 有很多設置，因此能夠導出完整備份非常省心。此外，它允許您在多個站點之間輕鬆複製自定義 W3TC 配置，而無需手動配置任何內容。

W3 Total Cache Settings - 頁面緩存

讓我們深入了解 W3 Total Cache 的“頁面緩存”設置。請記住，如果您的網站託管在 Kinsta 上，則無需擔心頁面緩存——因此請隨意跳過本節。

緩存首頁- 對於大多數網站，首頁通常是接收最多流量的頁面。因此，我們建議啟用此設置。
緩存提要– WordPress 生成各種 RSS 提要，允許外部應用程序和服務（如 Feedburner）顯示您網站的內容。雖然 RSS 現在不像以前那麼流行，但我們仍然建議啟用此設置。
緩存 SSL（HTTPS 請求） – 如果您的 Web 服務器未對所有傳入請求強制使用 HTTPS，則啟用此設置可能會對性能產生積極影響。如果您已經在 Web 服務器級別強制使用 HTTPS，則無需啟用此功能。
使用查詢字符串變量緩存 URI – 查詢字符串是添加在 URL 末尾的參數（例如 /?version=123）。查詢字符串通常用於從 WordPress 數據庫請求和顯示特定數據。通常，查詢字符串的目的是請求頁面的唯一版本，因此我們建議禁用此功能，除非您有要緩存的特定查詢字符串。
緩存 404（未找到）頁面– 默認情況下，W3TC 禁用此選項。如果您使用“磁盤增強”頁面緩存方法，原因可能是緩存行為。選擇該選項後，404 頁面將返回 200 響應代碼。理想情況下，404 頁面應返回 404 響應代碼，因此我們建議使用您的緩存配置測試此設置以查看它是否兼容。
不要為登錄用戶緩存頁面——我們建議啟用此選項。登錄用戶通常正在更新頁面。啟用緩存後，用戶需要不斷清除緩存才能查看頁面更新。
不要為某些用戶角色緩存頁面 -此選項允許您繞過某些 WordPress 用戶角色的緩存。 如果“不緩存已登錄用戶的頁面”選項已啟用，則此選項不會影響緩存行為。

別名

W3 Total Cache 的“別名”功能允許您緩存在不同域上可用的相同 WordPress 內容。我們不建議啟用此功能。如果您的 WordPress 站點可以通過不同的域（例如 domain.com 和 www.domain.com）訪問，最好設置一個 301 重定向規則來將請求轉發到您的主域，以避免來自 Google 和其他搜索引擎的重複內容處罰。

緩存預加載

“緩存預加載”功能會爬取您的站點地圖，並向您網站的頁面發出請求以預加載頁面緩存。對於大多數站點，我們建議禁用緩存預加載，因為它可能導致服務器資源峰值抵消潛在的性能優勢。

如果您確實想要啟用緩存預加載，W3TC 允許您指定站點地圖 URL、更新間隔和每個間隔的頁面。確保您沒有將“更新間隔”和“每個內部頁面”設置得太高，以減少 CPU 峰值的機會。

清除政策

W3TC 的“清除策略”允許您指定要在發布或編輯帖子後自動清除的頁面和提要。對於大多數網站，默認設置（首頁、帖子頁面和博客提要）就足夠了。如果您想向清除策略添加其他頁面，您可以配置多種選項。

REST API

WordPress 包含的 REST API 可讓您查詢 JSON 格式的數據。 REST API 被各種插件使用，對於無頭 WordPress 設置至關重要。根據您對 REST API 的確切用例，緩存查詢結果可能是一個好主意。 REST API 緩存屬於“如果你需要它，你就會知道”類別，因此如果您不確定是否啟用 REST API 緩存，我們建議將其保留為“不緩存”。

先進的

在 W3TC 的“高級”頁面緩存選項中，您可以自定義各種設置，包括“接受的查詢字符串”、“拒絕的用戶代理”、粒度緩存繞過設置等。例如，如果您需要將 W3 Total Cache 配置為從不緩存某個類別或標籤下的帖子，您可以在“高級”選項中執行此操作。

由於這些設置可能非常特定於站點，因此我們無法提供“推薦設置”。話雖如此，如果您希望自定義站點頁面緩存行為的特定方面，請務必查看高級選項。

W3 總緩存設置 - 縮小

接下來，讓我們回顧一下 W3 Total Cache 的“Minify”設置。

重寫 URL 結構 -此設置影響縮小資產的 URL 結構。我們建議保持啟用狀態，這樣您的 URL 看起來“漂亮”。
為登錄用戶禁用縮小 –如果您正在進行一些故障排除或調試，禁用登錄用戶的縮小可能會有所幫助。否則，我們建議禁用此選項。

HTML 和 XML

在“HTML & XML”部分，您可以配置 HTML 縮小設置。

內聯 CSS 縮小 –我們建議啟用此選項以刪除內聯 CSS 中的空白。
內聯 JS 縮小 –我們建議啟用此選項以刪除內聯 JavaScript 中的空格。在某些情況下，JS 縮小可能會導致代碼錯誤。如果啟用此選項會破壞您的站點功能，請將其禁用。
不要縮小提要 -我們建議禁用此選項。提要僅由 RSS 閱讀器和其他類似服務使用，因此不需要縮小提要。
換行符刪除 -默認情況下禁用此選項，我們不建議啟用它以確保您的網站正確呈現。

JS

在“JS”部分，您可以配置 JavaScript 縮小設置。

區域中的操作 -此選項允許您為縮小的 JavaScript 選擇“嵌入類型”。對於之前的 JS 文件之後，您可以在“阻塞”、“非阻塞”、“使用異步的非阻塞”和“使用延遲的非阻塞”之間進行選擇。雖然非阻塞加載方法通常會帶來更好的性能，但它們並不總是 100% 兼容所有 JavaScript 代碼。此外，“異步”和“延遲”有非常不同的用例。因此，我們建議使用默認的“阻塞”方法，除非您知道非阻塞 JavaScript 的怪癖。
僅縮小或合併 –您可以在 JavaScript 的兩種優化模式之間進行選擇。當選擇“縮小”時，您的 JS 文件將被合併和縮小。如果選擇“僅合併”，則生成的合併 JS 文件將不會被縮小。如果您遇到與縮小相關的問題並且不想調試以找出導致問題的腳本，則選擇“僅合併”選項可能會修復錯誤。
HTTP/2 推送 –如果您的服務器支持 HTTP/2 服務器推送，啟用此選項可以幫助您減少頁面加載時間。 HTTP/2 服務器推送在請求訪問者之前將文件推送給訪問者。我們建議在生產環境中啟用此選項之前進行充分的測試，因為服務器推送經常被誤用。服務器推送對於較大的 JavaScript 文件並不理想，您需要確保其好處超過直接從訪問者的瀏覽器緩存加載 JS 文件。

CSS

在“CSS”部分，您可以配置 CSS 縮小設置。

僅合併 –與 JavaScript 文件不同，CSS 通常不會遇到與縮小相關的問題。因此，我們不建議啟用“僅合併”。
Preserved Comment Removal –此設置從 CSS 文件中刪除註釋。我們建議啟用此選項以盡可能減小文件大小。
換行符刪除 -此設置從 CSS 文件中刪除換行符。我們建議也啟用此選項。如果您在啟用“換行符”後發現任何顯示問題，請將其禁用。

先進的

“高級”部分包含一些額外的設置來自定義縮小行為。

每次更新外部文件 – W3TC 允許您指定 CSS 和 JS 文件更新之間的時間量。默認設置為 86400 秒，您的資產將每 24 小時下載和壓縮一次。如果您的網站不經常更改，請隨意設置更長的時間段。
垃圾收集間隔 -此時間段設置指定刪除過期緩存數據的頻率。默認設置為 24 小時。如果您的站點存儲空間不足，我們建議降低“垃圾收集間隔”。

“高級”部分的其餘部分包括允許您指定永遠不應縮小的資產文件的輸入字段。還有一個“Rejected User Agents”字段，允許將非縮小文件提供給某些用戶代理。最後，您可以添加要包含在 W3 Total Cache 的縮小過程中的外部資產文件。

W3 總緩存設置 - 對象緩存

列表中的下一個是 W3TC 的“對象緩存”設置。對於大多數網站，默認設置可以正常工作，但不管怎樣，讓我們回顧一下。

緩存對象的默認生命週期 –未更改緩存項的到期時間。更長的時間段會導致更大的對象緩存。如果您擔心服務器的存儲容量，我們建議您保持默認值或降低它。
垃圾收集間隔 -此設置指定過期緩存數據被丟棄的頻率。對於大多數站點來說，默認值 3,600 秒（1 小時）應該沒問題。
全局組 -此設置允許您在單個多站點網絡中的站點之間配置共享緩存組。我們建議將此設置保留為默認狀態，除非您有特定的原因要更改它。
Non-Persistent Groups –此設置允許您選擇從不緩存的對象組。同樣，我們建議堅持使用默認配置。
為 wp-admin 請求啟用緩存 -默認情況下禁用此選項，我們不建議啟用它，因為它可能會導致副作用。此外，大多數 WordPress 網站的訪問者從不與 wp-admin 儀表板進行交互。

W3 總緩存設置 - 瀏覽器緩存

大多數 WordPress 主機，包括 Kinsta，已經在 Web 服務器級別實現了適當的瀏覽器緩存標頭。如果您的主機沒有，或者您想進一步自定義瀏覽器緩存行為，您可以使用 W3 Total Cache 來實現。

在“瀏覽器緩存”設置中，“常規”、“CSS 和 JS”、“HTML 和 XML”以及“媒體和其他文件”部分的默認設置對於大多數 WordPress 網站來說已經足夠了。由於此頁面上有很多設置，我們建議在對瀏覽器緩存行為進行任何更改之前諮詢開發人員。話雖如此，以下是有關瀏覽器緩存的一些關鍵設置。

Expires Headers Lifetime –配置較長的“expires headers生命週期”對於高效的瀏覽器緩存很重要。在 Kinsta，我們對 CSS、JS、圖像和字體等靜態資產強制執行 1 年的生命週期。如果您使用 W3TC 配置瀏覽器緩存，請務必將此值設置為31536000 （1 年）。
緩存控制策略 -為確保您的靜態資產可被瀏覽器緩存，請確保“緩存控制策略”設置為“public, max_age=EXPIRES SECONDS”。
啟用 HTTP (gzip) 壓縮 – GZIP 壓縮會在 HTML 頁面和資產發送給訪問者之前顯著減小文件大小，因此如果您的主機的服務器配置支持 GZIP，請務必啟用此選項。如果您的站點託管在 Kinsta 上，則無需在 W3TC 中啟用 GZIP 壓縮，因為它已作為我們默認配置的一部分啟用。
從靜態資源中刪除查詢字符串 -查詢字符串是添加到 URL 路徑末尾的附加字符串，用於指定請求參數或強制 Web 服務器交付新資產。查詢字符串以? ，並且大多數 Web 服務器都配置為繞過帶有查詢字符串的請求的緩存。從頁面請求中刪除查詢字符串有助於減少服務器負載，因為這些請求使用 PHP 來呈現頁面。我們不建議從 W3 Total Cache 中的靜態資源中刪除查詢字符串，因為它們有助於確保將最新版本的 CSS 和 JS 文件傳遞給您的訪問者。

“瀏覽器緩存”設置頁面還包含與內容安全策略 (CSP) 和 X-XSS 保護等安全標頭相關的各種設置。我們始終建議與合格的開發人員一起完成這些設置，因為不正確的配置會直接影響您網站的用戶體驗。例如，在沒有正確 SSL 證書和 HTTPS 配置的情況下啟用 HSTS 標頭可能會導致您的站點無法訪問。

W3 總緩存設置 - 用戶代理組

如果您需要根據用戶的設備類型重定向流量，W3 Total Cache 的“用戶代理組”功能非常強大。例如，如果用戶通過手機訪問您的網站，您可以將您的網站配置為使用不同的主題呈現。同樣，如果您的移動網站位於唯一的子域中，您可以將用戶重定向到完全不同的網站。

在響應式網頁設計時代，我們沒有看到太多針對此特定功能的用例。如今，最佳做法是讓您的網站從一開始就具有響應性，而不是依賴多個主題或僅限移動設備的子域。

W3 總緩存設置 - 推薦人組

HTTP 引薦來源網址是一個可選的 HTTP 標頭，它提供有關請求來源的信息。例如，如果訪問者從 Google 搜索列表中點擊您的網站，則 HTTP 引薦來源網址將是google.com 。

因停機時間和 WordPress 問題而苦苦掙扎？ Kinsta 是在設計時考慮到性能和安全性的託管解決方案！查看我們的計劃

在 W3 Total Cache 中，您可以使用“Referrer Groups”根據請求的 HTTP 引用者定義自定義緩存行為。例如，您可以創建一個由搜索引擎組成的引用組，並僅為來自這些域的請求自定義緩存行為。

與上面提到的“用戶代理組”類似，您還可以使用“引薦組”功能將請求重定向到不同的域。大多數 WordPress 網站不需要設置推薦人組，因此我們不建議進行任何配置。

W3 總緩存設置 - Cookie 組

W3 Total Cache 支持的最新緩存組是“Cookie Groups”。此功能允許您根據請求的 cookie 創建唯一的緩存桶和行為。與“User Agent Groups”和“Referer Groups”類似，大多數站點不需要設置自定義的基於 cookie 的緩存配置。如果您的站點需要基於 cookie 的緩存，我們建議您與開發人員合作以正確配置它。

W3 總緩存設置 - CDN

現在，讓我們繼續討論 W3 Total Cache 的 CDN 設置。

主機附件 -啟用此選項可從 CDN 為您的 WordPress 媒體庫中的資產提供服務。
主機 wp-includes/ 文件 -啟用此選項可從 CDN 提供wp-includes文件夾中的文件。
託管主題文件 -啟用此選項以從您的 CDN 提供您的主題文件。
託管縮小的 CSS 和 JS 文件 -啟用此選項以從您的 CDN 提供 W3TC 的縮小的 CSS 和 JS 文件。
託管自定義文件 -如果您的文件不在媒體庫或主題文件夾中，您可以在 W3TC 中添加文件路徑以從您的 CDN 提供它們。
添加規範標頭 – rel=”canonical”標籤可幫助搜索引擎識別原始來源或 URL。由於 CDN 通常使用不同的域，因此添加規範標籤會通知搜索引擎原始資產的位置。話雖如此，可以禁用此設置，因為現代搜索引擎足夠聰明，可以識別 CDN 而不會影響您網站的 SEO 排名。

先進的

僅手動清除 CDN –我們建議禁用此選項以讓 W3TC 自動處理緩存清除。
在 SSL 頁面上禁用 CDN –保持禁用此設置。如果您使用的是 CDN，最好在 HTTP 和 HTTPS 頁面上都啟用它。
在管理頁面上為媒體庫使用 CDN 鏈接 –我們不建議啟用此選項，因為它會重寫媒體庫中的 URL。
添加 CORS 標頭 -啟用此設置以允許您的 CDN 資產顯示在其他域上。
為以下角色禁用 CDN –此選項允許您為某些 WordPress 用戶角色禁用 CDN。在大多數情況下，最好禁用此選項。
wp-includes 要上傳的文件類型 -此字段指定wp-includes中將從您的 CDN 提供的文件格式。對於大多數網站來說，默認的文件格式列表應該沒問題。如果您的wp-includes文件夾中有自定義文件，請隨時根據需要添加其他格式。
要上傳的主題文件類型 -此字段指定將由 CDN 提供的 WordPress 主題文件夾中的文件格式。默認列表包含所有流行的資產、圖像和字體格式。如果需要，請隨意添加其他格式。
自定義文件列表 -如果您啟用了“託管自定義文件”，您可以在此字段中添加文件列表以從您的 CDN 提供服務。
拒絕的用戶代理 -此字段允許您指定不會從您的 CDN 提供資產的用戶代理。我們建議將此字段留空，以確保正確使用您的 CDN。
Rejected Files –此字段允許您指定不應從 CDN 提供的文件。如果您使用的服務需要從您的根域提供資產，您可以將文件路徑添加到“拒絕的文件”字段。

W3 總緩存設置——用戶體驗

接下來，讓我們自定義 W3 Total Cache 中的“用戶體驗”或延遲加載設置。

處理 HTML 圖像標籤 -啟用此選項以確保圖像是延遲加載的。
處理背景圖像 –如果您使用“背景”在 CSS 中顯示圖像，啟用此選項將允許延遲加載這些圖像。
排除單詞 -在此字段中，您可以指定文本以繞過延遲加載。例如，如果您在此字段中添加no-lazy-load ，則以<img src="image.jpg">顯示的圖像將不會被延遲加載。
Script Embed Method -此設置允許您自定義延遲加載腳本的加載方法。默認async方法是大多數站點的最佳選擇。如果您的網站僅包含一個登錄頁面，則可以使用inline方法來減少加載頁面的 HTTP 請求數。

W3 Total Cache 的可用擴展

W3 Total Cache 提供各種擴展以與第三方服務集成。 W3TC 目前有以下服務的擴展。

安培
Cloudflare
谷歌飼料燃燒器
片段緩存
創世紀框架
新遺物
群聚
Yoast 搜索引擎優化
WPML

如果您在您的站點上使用這些服務中的任何一項，我們建議您設置相關的擴展程序以確保與 W3 Total Cache 正確兼容。在本節中，我們將了解 W3 Total Cache 的 Cloudflare 擴展。

如何使用 Cloudflare 擴展設置 W3 總緩存

要將 Cloudflare 與 W3 Total Cache 集成，您需要 Cloudflare 儀表板中的兩條信息——帳戶電子郵件和 API 密鑰。帳戶電子郵件是您用於登錄 Cloudflare 的電子郵件地址。讓我們看看如何設置 Cloudflare API 密鑰。

在 Cloudflare 儀表板中，單擊“概覽”選項卡。接下來，向下滾動並單擊右側邊欄中的獲取您的 API 令牌。

向下滾動，然後單擊“全局 API 密鑰”旁邊的查看以獲取您的 Cloudflare API 密鑰。 Be careful not to share this API key anywhere outside W3 Total Cache because it can be used to control your Cloudflare account.

Next, activate the Cloudflare extension in W3 Total Cache's “Extensions” page and click “Settings”. In the “Credentials” section, click on the Authorize button.

In the subsequent popup, input your Cloudflare account email and API key. If you receive an error message, double-check to make sure your email address and API key are correct. After the credentials are authorized, you should see additional Cloudflare settings on the page.

Let's go over the Cloudflare settings in W3 Total Cache.

Widget Statistics Interval – This specifies the time period covered for W3TC's Cloudflare widget. The default setting is 30 minutes. If you'd like to see a longer time period, feel free to increase it.
Cache Time – This specifies the amount of time that widget data from Cloudflare is cached. If you don't plan on using the widget much, we recommend increasing this number to reduce the number of requests to Cloudflare from your site.
Page Caching – If you've configured Cloudflare to cache HTML pages for your WordPress site, enable this option to automatically clear the Cloudflare cache after post modifications and updates.

Cloudflare 緩存

This section lets you customize Cloudflare's caching settings.

Development Mode – Keep this option disabled unless you need to put Cloudflare in Development Mode. When Cloudflare is in Development Mode, edge caching, minification, and image optimization is disabled for three hours. This allows you to see updates to CSS and JS files immediately and is useful for troubleshooting.
Cache Level – For most sites, we recommend using the “Standard” cache level, which serves a different resource each time the query string changes. If you're 100% sure that your WordPress site does not make use of query strings to serve dynamic content, you can also use the “Ignore Query String” setting as well.
Browser Cache TTL – We recommend setting Cloudflare's browser cache TTL to 31536000 seconds, which is equal to 1 year.
Challenge TTL – Cloudflare offers a variety of security-related services, and visitor challenges is one of them. If Cloudflare detects a malicious user or strange behavior, it will serve a challenge message in the form of a Captcha. The “Challenge TTL” setting specifies how long a user will have access to your site after completing a challenge. With the default setting of 3600 seconds, a visitor who was subject to a challenge will be able to use your site for 1 hour before another challenge.
Edge Cache TTL – This setting controls how long assets will be cached at Cloudflare's edge servers. We recommend setting this to the maximum value of 31536000 seconds, or 1 year.

Cloudflare Content Processing

Let's dive into the Cloudflare content processing settings in W3 Total Cache.

Rocket Loader – Cloudflare's Rocket Loader speeds up JavaScript loading for your WordPress site. We recommend enabling Rocket Loader if your site has a lot of JS.
Minify JS/CSS/HTML – If you've already enabled minification for HTML, CSS, and JavaScript in W3 Total Cache, feel free to keep these options in the Cloudflare extension settings disabled, as there is no need to minify assets that have already been minified.
Server Side Exclude (SSE) – This option allows you to hide sensitive information from suspicious visitors (deemed by Cloudflare). Server-side excludes are useful for hiding information like email address, phone numbers, and other personal information on your site. To use SSE, enable it and wrap sensitive information in  tags in your HTML code or PHP theme template.
Email Obfuscation – When this option is enabled, Cloudflare will automatically obfuscate email addresses on your WordPress site with JavaScript. While obfuscation is not going to get rid of email spam completely, we recommend enabling this option because it does deter basic bots from scraping email addresses from your site.

Cloudflare Image Processing

Let's go over Cloudflare's image processing settings.

Hotlink Protection – Enabling hotlink protection will prevent other sites from embedding your images. If you're running into bandwidth limits due to unauthorized external embeds, enabling “Hotlink Protection” can help you reduce bandwidth usage.
Mirage (Pro Only) – Mirage optimizes image delivery to low-bandwidth devices and networks. This feature is only available on Cloudflare Pro plan and above.
Polish (Pro Only) – Polish optimizes your site's images, and can be configured to serve WEBP images to supported browsers. This feature is only available on Cloudflare Pro plan and above.

Cloudflare 保護

Cloudflare's primary feature is a sophisticated firewall that can help protect you against DDoS attacks and malicious actors. Let's go over Cloudflare's security settings.

Security Level – This setting controls the sensitivity of Cloudflare's firewall and security rules. We recommend setting the “Security Level” to “Medium” for most sites.
Browser Integrity Check – This feature looks out for bad behavior and suspicious user agents. If it detects a potentially malicious user or spammer, Cloudflare will automatically serve a challenge. We recommend enabling this feature.
Always Online – This option will serve static HTML pages of your site if your origin goes down. We recommend enabling it if you've configured Cloudflare to cache HTML.
Web Application Firewall – Cloudflare's WAF, or web application firewall, will scan incoming traffic and filter out “illegitimate traffic” from reaching your site. We recommend enabling this feature.
Advanced DDoS Protection – This feature is enabled by default, and cannot be disabled as long as Cloudflare's proxy is active. DDoS protection helps shield your site from “distributed denial of service” attacks.
Max Upload – This sets the maximum allowed file size for uploads to your site. You'll want to make sure that this setting is either equal to or greater than your upload file size setting in WordPress.

Cloudflare SSL

Lastly, you'll want to make sure your Cloudflare SSL settings are configured correctly. Let's go over the right configuration in this section.

SSL – If your site is hosted on Kinsta, we recommend using either the “Full” or “Full (Strict)” SSL option. The “Flexible” option is not compatible with our infrastructure. “Full Strict” requires an SSL from a valid certificate authority, while the “Full” option also supports self-signed SSLs. The “Flexible” option does not require an SSL certificate on the origin server – we don't recommend this option because it is the most insecure.
TLS 1.2 Only – TLS, or Transport Layer Security, is a secure protocol for transferring data over a network. Some PCI compliance standards require dropping support for TLS 1.1 and below. If that is a requirement for your site, you can enable the “TLS 1.2 Only” setting in Cloudflare to set the minimum TLS version to 1.2.

建議閱讀：如何為 WordPress 設置 Cloudflare APO。

W3 總緩存 WooCommerce 設置

WooCommerce 是 WordPress 網站最受歡迎的電子商務平台。如果您在 WooCommerce 支持的商店中使用 W3 Total Cache，您需要確保您的配置正確，以避免緩存客戶詳細信息。

繞過 WooCommerce Cookie

要繞過具有 WooCommerce 特定 cookie 的頁面的頁面緩存，請轉到 W3TC 的“頁面緩存”設置，向下滾動到“拒絕的 Cookie”，然後添加以下四個項目。

woocommerce_items_in_cart
woocommerce_cart_hash
wp_woocommerce_session_
wordpress_logged_in

繞過 W3 Total Cache 中的 WooCommerce cookie。

為了安全起見，我們還建議繞過 WooCommerce 特定的 URL，例如購物車頁面、結帳頁面和帳戶頁面。要繞過這些頁面的緩存，請轉到 W3TC 的“頁面緩存”設置，並將 URL 添加到“從不緩存以下頁面”部分。

如何重置 W3 Total Cache 中的所有設置

在某些情況下，您可能需要重新開始您的 W3TC 配置。以下是將 W3 Total Cache 恢復為默認設置的方法。轉到 W3TC 的“常規設置”菜單，向下滾動到“導入/導出設置”部分，然後單擊恢復默認設置。

W3 Total Cache 擁有超過 100 萬的活躍安裝量，之所以受歡迎是有原因的。在此處了解如何設置和優化您的設置點擊鳴叫

概括

如您所見，W3 Total Cache 插件充滿了功能和設置。從頁面緩存到資產縮小，再到 Cloudflare 集成，W3TC 擁有提升 WordPress 網站性能所需的一切！

在本文中，我們介紹了我們推薦的 W3TC 配置插件。你有最喜歡的 WordPress 優化插件嗎？在下面的評論中讓我們知道！