Blog 和內容行銷已成為許多新創公司選擇的行銷工具，並且相當多的創始人發現自己選擇 WordPress 來支持他們的消息傳遞。WordPress 已經成為 28% 的網絡所選擇的內容管理系統 (CMS)，它是世界上最大的自託管博客工具，並且可能是哈佛法學院、華特迪士尼公司、官方網站使用的唯一開源項目。瑞典網站和 Rackspace。
WordPress 的開箱即用性能相當不錯，但仍有改進的空間——解決性能問題的 WordPress 插件的數量就是證明。然而，改善用戶體驗的最簡單方法是使用 CloudFront 加速整個 WordPress 網站。這樣做不僅可以提高網站的響應能力，還可以降低運行 WordPress 基礎設施的總體成本，因為減少 Web 服務器上的負載可以幫助您縮小所需基礎設施的規模。事實上，當您的網站變得流行時，CloudFront 可以顯著幫助您的網站應對意外負載。
現在，如果您之前在互聯網上搜索過有關加速 WordPress 網站的建議，您可能會發現許多有關 CloudFront 配置的指南，其中的建議各不相同，有時甚至是相互衝突的。今天，這篇文章將明確解釋如何在任何合理的標準配置下為您的 WordPress 網站或博客提供性能提升。（此解決方案還將包括AWS Shield 標準的優勢，例如針對最常見的 DDoS 攻擊提供保護，且啟動友好，無需額外付費。）但是，如果您的站點安裝了任何其他插件，您可能需要運行一些額外的測試，以防插件導致 WordPress 以我未測試過的方式運行。
CloudFront 如何提供幫助？
許多 AWS 客戶的用戶遍布全球，他們希望覆蓋這些用戶。然而，曾經需要大量工程工作的內容現在可以使用 AWS 區域和邊緣站點輕鬆構建，這使您可以從距離這些用戶最近的位置提供內容。
互聯網上的數據傳輸很大程度上依賴於全球光纖電纜網絡，從而允許非常高的帶寬數據傳輸（請參閱James Hamilton關於 AWS 全球網絡的精彩re:Invent 演講）。這些光纖網絡已經以光速發送數據，但人類缺乏耐心，當從世界另一端訪問內容時，可能會出現輕微的延遲。由於光速是一個難以克服的挑戰，Amazon CloudFront 通過其他幾種方式改善了用戶訪問您網站的體驗，包括：
- 任播 DNS 可確保您的客戶被路由到最近的邊緣位置。
- 緩存內容（如果可用）將從邊緣位置傳送給您的用戶。
- 當需要從您的站點獲取數據時，CloudFront 通過管理邊緣站點與您的網站之間的傳輸來優化網絡吞吐量。此流量在 Amazon Global Backbone 上運行，其中優化的 TCP 配置可確保網絡上傳輸更多字節，從而提高吞吐量，而 TCP 連接重用則消除了與建立連接相關的大部分延遲。這樣，無論內容是否被緩存，都將通過優化的網絡路徑來加速傳輸。
- 最後，在 CloudFront Edge 上協商和卸載傳輸層安全性 (TLS) 進一步提高性能，減少連接設置延遲，並進一步支持後端連接重用。
解決方案概述
上面的簡化架構描述了 WordPress 的常見架構，其中靜態內容存儲在 AWS S3 中，而 WordPress 在 EC2、Lightsail 或其他託管設施上運行。WordPress 默認將所有內容存儲在本地 Web 服務器上。然而，有幾個插件可以輕鬆地將靜態內容移動到 S3，W3 Total Cache 就是一個例子。無論您的網站是否在 S3 中存儲靜態內容，此處的建議都是相關的，並且在任何情況下都會加速您的網站。
分佈、起源和行為
首先，我將簡要回顧一些術語，以確保我們達成共識。具有 DNS 終端節點的 CloudFront 配置稱為分配。網站的所有配置設置都可以用單個分發來配置，儘管可能存在具有不同屬性的內容，例如可緩存的圖像，以及為查看者定制的動態生成的內容，不應緩存這些內容。WordPress 將內容分為下表所述的文件夾結構。我們可以使用適當的設置來配置 CloudFront，以通過緩存行為來服務每一類內容，這允許請求 URL（通常按文件擴展名或路徑前綴分組）應用適當的緩存配置。
即使是相對簡單的網站也可以從不同的位置提供內容。CloudFront 將這些單獨的位置稱為origin。源可以是 Amazon S3 存儲桶或 HTTP 終端節點。您的 HTTP 服務器可以託管在 AWS 或任何面向互聯網的 HTTP 系統上。在上圖中，S3 和 WordPress 服務器將在您的分發設置中配置為單獨的源。
接下來我將描述配置 CloudFront 的三個主要步驟：
- 創建發行版
- 定義你的起源
- 配置緩存行為
起源
創建 CloudFront 分配
我假設您的 WordPress 網站已啟動並正在運行。如果沒有，請參閱WS WordPress 參考架構頁面，獲取腳本化解決方案，讓您在幾分鐘內啟動並運行。您應該註冊一個域名，也許是一個指向您的 WordPress 站點或服務器的“www”條目。就我而言，“www”記錄定向到我的應用程序負載均衡器的 CNAME。但是，在您的情況下，DNS 記錄將通過 DNS 名稱或 IP 地址引用您的 WordPress 網站。
www.example.com ⇒ wordpress-abxdef-111222333.eu-west1.elb.amazonaws.com
或更通用；
⇒ <WordPress DNS 名稱或 IP>
現在，您應該從CloudFront控制台創建一個 CloudFront _Web_分配。如果我沒有提及配置，您可以假設我已經接受了默認選項。
填寫分發所需的詳細信息。
源域名是您當前 DNS 記錄的目標，在本例中是應用程序負載均衡器，但您可能選擇了 Amazon Lightsail、EC2 或託管 WordPress 服務。CloudFront 控制台將提供一個下拉列表，列出您的 AWS 賬戶中配置的 S3 存儲桶和任何負載均衡器，以幫助避免錯誤，但如果未列出，您只需鍵入 DNS 名稱或 IP 地址即可。
注意：無論網站是否託管在 AWS 上，CloudFront 都可以配置為加速您的網站。
傳輸層安全/SSL
Amazon Certificate Manager 免費提供 TLS/SSL 證書，可與 CloudFront 和 AWS Elastic 或 Application Load Balancer 配合使用。由於對傳輸中的數據進行加密有助於與用戶建立信任，因此我假設您將使用 TLS 加密。
選擇 CloudFront 與您的 WordPress 站點通信時可能使用的 SSL 協議。如果您已將站點配置為接受 HTTPS 流量，則這很重要。AWS 不建議配置 SSLv3，除非您的後端無法支持傳輸層安全性 (TLS)。
源協議策略決定 CloudFront 如何與您的源（WordPress 服務器）進行通信。您可以選擇始終讓 CloudFront 使用 HTTP，無論原始 Web 查看器（客戶端或瀏覽器）請求如何，讓 CloudFront 使用 HTTPS 進行 Origin 連接，或者匹配查看器的請求。我已使用 Amazon Certificate Manager 在我的站點上配置了證書，因此我將選擇僅 HTTPS 以確保 CloudFront 和我的源之間的通信加密。
超時和端口
CloudFront 允許用戶配置 Origin 響應和保持活動超時。您的 WordPress 網站不太可能需要更長的請求超時。但是，如果您的站點接收的流量較少，則增加保持活動超時可能會很有用，可能會達到最大值 60 秒。這將導致 CloudFront 在請求之間保持與源的開放 TCP 連接，從而避免與為後續用戶或頁面獲取重新建立連接相關的延遲。默認行為是關閉空閒 5 秒的連接。
注意：如果您配置了較長的保持活動時間並且您的站點流量很大，您可能會發現需要擴展源以維持與 CloudFront 的許多開放連接。
自定義標頭
CloudFront 能夠將用戶指定的標頭添加到發送到源的每個請求，這可能會覆蓋查看器設置的標頭。例如，這可用於添加秘密或“密鑰”，指示該請求是通過 CloudFront 提供的。您的 Web 應用程序或者應用程序負載均衡器上的 AWS WAF 規則可以驗證此標頭，以確保僅接受來自 CloudFront 分配的流量。
默認緩存行為設置
這些默認設置是“包羅萬象”的行為，並且必須適用於我們將根據上面的行為表定義的更具體規則未處理的任何請求。
對於我的查看器協議策略，我將配置 CloudFront 以將任何 HTTP 請求重定向到 HTTPS。請注意，如果您選擇“僅 HTTPS”，則您的用戶在訪問您的網站時可能必須鍵入完整的 https://url，除非他們始終通過其他頁面的鏈接進行導航。
對於允許的方法，由於 WordPress 使用需要 POST 的表單，因此我選擇啟用所有 HTTP 方法。此外，我還啟用了選項請求的緩存，這可以加速 CORS 請求。
標頭
當您的 Web 服務器配置為託管多個站點（通過虛擬主機等）時，主機標頭確定將提供的內容。我建議基於白名單標頭進行緩存，並至少配置 Host 和 Origin 標頭。您應該轉發通過 Web 應用程序處理的標頭，或者改變返回給查看者的內容的標頭。如果您跟踪將用戶引導至您網站的引薦來源網址，您可能還需要轉發引薦來源網址標頭。
注意：如果您選擇“無”，則 CloudFront 在某些情況下可能會提供錯誤的內容，例如當您在同一服務器上託管多個網站的內容時。另一方面，如果您選擇“全部”，CloudFront 將不會緩存對象，而是會將所有請求發送到您的源進行處理，從而降低緩存命中率並為您的源增加額外負載。獲得正確的平衡需要了解您的環境，而我沒有，因此，如果您託管多個站點，則可能需要進一步調整。
對象緩存
默認情況下，WordPress 不會設置 Expires 或 max-age 等緩存控制標頭。您可以安裝插件（請參閱有關緩存的WordPress 文檔）或配置“.htaccess”文件來設置這些標頭。如果您選擇不以這種方式配置 WordPress，您仍然可以通過選擇在“對象緩存”下進行自定義來獲得 CloudFront 緩存內容。（如果您已將 WordPress 配置為添加緩存控制標頭，則選擇“用戶來源緩存標頭”）。當 WordPress 服務器未配置緩存標頭時，下面的“默認 TTL”設置告訴 CloudFront 將對象緩存 300 秒。
這將緩存您網站上的動態頁面，並且還可能阻止未登錄的用戶看到發佈到頁面的評論，直到緩存在 1 分鐘/300 秒後過期。如果您希望用戶在發布後立即看到評論，請選擇較低的默認 TTL。此緩存將減少服務器上的負載，特別是當您的網站流量突然激增時，因為大多數訪問者都會看到緩存的頁面。
餅乾
WordPress 廣泛使用 cookie，我建議基於白名單轉發 cookie。您的里程可能會有所不同，具體取決於您的網站或插件的配置，但以下 cookie 對於大多數情況來說應該足夠了。您可以在此處的官方文檔中找到 WordPress cookie 使用的詳細信息。
查詢字符串
WordPress 使用查詢字符串來確定要返回的內容，例如搜索結果或單個文章請求。因此，這些應該被發送到源（WordPress），但我們也應該根據實際的查詢字符串緩存一小段時間，以避免從先前用戶的查詢中返回緩存的結果。
媒體流（平滑流）和限制內容（例如付費牆後面）超出了本文的範圍，因此我們將保留它們的默認值。
我建議打開“自動壓縮對象”。使用此選項，當請求的查看器或瀏覽器包含標頭：“Accept-Encoding：gzip”時，CloudFront 將壓縮某些文件。交付壓縮對象將提高用戶的性能。
分發設置
CloudFront 允許許多配置選項，但我將重點介紹可能與 WordPress 網站相關的選項。您還會看到我尚未配置 AWS WAF，這同樣超出了本文的討論範圍，但當然值得考慮為您的網站提供這種額外保護。
傳輸層安全/SSL
如前所述，我已使用 Amazon Certificate Manager 創建了免費的 TLS/SSL 證書。此證書是在我的應用程序負載均衡器上配置的，除了保護 CloudFront 和我的網站之間的後端流量之外，我還可以將證書與 CloudFront 一起使用，以確保我的用戶和 CloudFront 邊緣站點之間的通信安全。
自定義 TLS/SSL 客戶端支持
CloudFront 提供兩種託管 TLS/SSL 證書的選項。默認選項是僅為支持服務器名稱指示 (SNI) 的客戶端提供服務。使用此默認選項，CloudFront 會將您的證書與不專用於您的分配的 IP 地址相關聯。SNI 是 TLS 協議的擴展，大多數現代瀏覽器都支持，它在請求標頭中包含域名。這允許 CloudFront 確定在協商加密通道時使用哪個證書。如果客戶端瀏覽器不支持 SNI，則連接無法得到保護並且將被丟棄。
另一種方法是讓 CloudFront 在託管您的分配的每個邊緣站點中提供專用 IP 地址。在這種情況下，不支持 SNI 的瀏覽器將能夠協商與您網站的安全連接。注意：此選項每月需支付額外費用。
維基百科在此頁面列出了支持 SNI 的瀏覽器。
我建議使用服務器名稱指示的默認選項。
安全政策
CloudFront 支持各種安全策略，使您可以通過強制執行 TLS v1.2 等措施來提高 Web 應用程序的安全性，並消除 RC4 等弱密碼。但是，我們建議您使用 TLSv1.2_2016 安全策略以獲得最廣泛的瀏覽器兼容性。使用更新的安全策略將需要瀏覽器支持更高版本的 TLS，並且還會放棄對弱密碼（例如 3DES）的支持。有關密碼和協議詳細信息，請參閱CloudFront 文檔。
默認根對象
這與 WordPress 無關，因為您的站點將自動配置為提供 index.php 服務。如果您託管來自 S3 源的靜態站點，您可以選擇將 index.html 作為默認服務器。
記錄
根據您自己的要求，您可以選擇記錄由 CloudFront、彈性或應用程序負載均衡器、WordPress 服務器或以上所有服務器處理的 HTTP 請求。默認設置是不記錄所有查看者請求，目前我將保留此默認設置。
最後，您可以添加註釋，選擇“已啟用”作為分發狀態，然後單擊“創建分發”。
狀態：進行中
創建分配後，您將被重定向回 CloudFront Web 控制台，您可以在其中看到列出的分配，狀態為“正在進行”。狀態更改為“已部署”可能需要幾分鐘的時間，但我們可以繼續指定 WordPress 內容的來源和行為。
添加起源和行為
選擇您的發行版並單擊發行版設置按鈕以編輯設置。
在 Origins 選項卡上，您應該會看到一個在初始設置期間創建的 Origin，如下所示：
選擇創建源以添加 CloudFront 將從中請求內容的源。
由於我已將 WordPress 配置為在 S3 中存儲圖像、CSS 和 JavaScript 文件等靜態內容，因此我將添加 S3 存儲桶作為源並配置適當的緩存行為。
接下來，從“行為”選項卡中，我們將創建上表中提到的配置。
目前，您只會看到默認（*）行為：
我已經描述了上面的設置，因此我不會再詳細介紹，但您應該使用這些設置再創建四個行為。
由於內容是靜態的，因此它應該非常容易緩存。
不要忘記 DNS
此時，對您的發行版所做的更改將生效（狀態：進行中）。但是，我們尚未對您的 WordPress 網站進行任何更改。與以前一樣，它仍然可以在 www.example.com 上找到。
為了使您的域的 CloudFront 配置處於活動狀態，您只需更新 DNS 記錄，創建指向您的 CloudFront 分配的 DNS 名稱的 CNAME 或別名。如果您將 DNS 託管在 Route 53 中，這是一個快速且簡單的更改，但我將把它作為練習留給讀者。但是，在對所有用戶進行此更改之前，您可以測試設置，通過編輯主機文件來覆蓋您自己計算機的 DNS：
1. 從命令行在您的 CloudFront 分配上執行 DNS 查找；
挖掘 dywhc8e9dt67j.cloudfront.net
dywhc8e9dt67j.cloudfront.net。54 在 54.192.31.130
dywhc8e9dt67j.cloudfront.net。54 在 54.192.31.131
……
……
2. 選擇返回的任何 IP 地址並將其添加到您的主機文件 C:\Windows\System32\drivers\etc\hosts（Windows 上）
或 /etc/hosts（Mac 或 Linux 系統上）
在文件底部添加一行，它應該如下所示；
www.example.com 54.192.31.130
3. 現在，當您使用瀏覽器訪問站點時，主機文件將覆蓋 DNS，並且您將被定向到 CloudFront 發行版進行測試。確保充分測試網站的所有區域，包括管理界面和插件行為。
4. 最後，一旦您對改進感到滿意，請從您的主機文件中刪除該條目，並在您的 DNS 中創建一個指向 www.example.com 的 CNAME 到您的 CloudFront 分發 DNS 端點 dywhc8e9dt67j.cloudfront.net（在我的情況下），但您的也會有所不同。
概括
本分步指南應該可以讓您的 WordPress 網站比以往更好地運行，並為任何突然的流量高峰做好準備。有關我在此處描述的選項的更多詳細信息，請參閱Amazon CloudFront – 入門網站。另外，請查看GitHub 上的 WordPress 參考架構，它提供了 CloudFormation 腳本，可在幾分鐘內啟動並運行可擴展的 WordPress 架構，包括 CloudFront 加速。