最佳化AEM網站快取
最佳化AEM架構中的快取，是大幅提升效能的最快速方式之一。 本文主要說明如何最佳化AEM架構中可用的各種快取。
說明 description
環境
Adobe Experience Manager 6.5
問題/症狀
如何最佳化AEM網站快取？
AEM架構和快取
在所有AEM架構中，使用者造訪您的網站時會遇到多個快取階層。 標準AEM架構中需考慮4個快取層。 這包括網頁瀏覽器、CDN、Dispatcher和AEM執行個體。
解決方法 resolution
A.瀏覽器快取
使用者重複造訪您的網站時遇到的第一個快取層級是自己的瀏覽器。 瀏覽器層級的快取通常是透過 Cache-Control： max-age=… 回應標頭來完成。 max-age設定會告訴瀏覽器，在嘗試「重新驗證」或再次從網站要求之前，它應該快取檔案的秒數。 這個快取 max-age 的概念通常稱為「快取有效期」或TTL （「存留時間」）。
Cache-Control標頭中有各種選項（或「指示」）會影響快取發生的方式。 以下是一些常見的指示：
-
private - Cache-Control標頭中的private指示詞可讓檔案只在瀏覽器中快取，不會在CDN等中繼快取中快取。 此指示的實用方式是如果您的頁面包含個人化/使用者特定內容。
使用範例：
Cache-Control: max-age=300, private -
s-maxage - Cache-Control標頭中的s-maxage指示詞可讓您為CDN之類的共用快取設定不同的TTL。 設定此值時，瀏覽器會使用max-age中設定的內容，而其他快取會改為遵循s-maxage設定。
使用範例：
Cache-Control: max-age=600, s-maxage=300
現代瀏覽器全都支援 Cache-Control 標頭，不過HTTP/1.0中有些舊式過時的標頭，仍可能對快取產生影響。 這些標頭是 Expires 和Pragma。 如果您不需要支援非常舊的瀏覽器，那麼請勿傳送這些回應標題。
除了快取以外，重新驗證也是一個重要的概念。 重新驗證仰賴Last-Modified（回應） / If-Modified-Since (request)標頭，以及ETag （回應） / If-None-Match （請求）標頭。
瀏覽器測試時請小心：
在Google Chrome中測試快取時，如果您透過https進行測試，而且您擁有自我簽署憑證，則不會快取任何內容。 當憑證不受信任或無效時，Chrome不會快取回應或執行重新驗證。
在Dispatcher上的備註：
AEM Dispatcher v4.2.3及舊版發生問題，其中/enableTTL只會使用 max-age 指示詞來快取。 這表示即使設定 private 或 s-maxage 指示詞，如果已設定max-age，它仍會快取。 此問題已在Dispatcher 4.2.4及更高版本中解決。
B. CDN快取
CDN或「內容傳遞網路」是Web伺服器的分散式網路，專為從最接近使用者的位置快取及提供內容而設計。 這會減少網路躍點數，以及使用者電腦與您的內容之間的距離，進而減少「往返時間」(RTT)。 RTT是瀏覽器傳送要求至您的網站及接收回應所花的時間。 由於CDN提供者領域的競爭，使得CDN變得極具成本效益。 因此，決定使用CDN來處理您的網站相當容易。 如果您尚未使用CDN，則務必應該在您的網站中加入CDN。
有許許多多的CDN提供者，每一家都提供不同的功能和設定。
CDN快取如何運作？
CDN會依照類似瀏覽器的規則快取內容。 它們仰賴Cache-Control HTTP 回應標頭，而且如果找不到 Cache-Control標頭，通常會回復到 Expires標頭。
大部分的CDN都會提供觸發手動排清快取的方法。 在許多情況下，將快取排清傳播到具有您的檔案的所有邊緣伺服器會有一些延遲（例如15分鐘）。
最佳化CDN使用量
為了確保在CDN中快取檔案的方式最佳化，有以下幾點：
-
在 Cache-Control 標頭中使用支援 stale-while-revalidate 和 stale-if-error 指示詞的CDN。
- stale-while-revalidate — 這個指示詞會通知CDN在快取檔案過期後擷取新的檔案時，提供該檔案的舊（已快取）版本。
- stale-if-error — 同樣地，當來源在重新驗證期間回應錯誤時，這個指示詞會告訴CDN提供舊版（已快取）的檔案。
-
未預先壓縮的所有檔案型別的GZip壓縮回應。
您應該從排程程式層級執行這項操作。 這將確保您減少傳送至CDN的位元組數。 CDN通常依傳輸的位元組收費，因此壓縮回應可降低成本。
-
在Dispatcher層級上啟用GZip壓縮： Apache - 使用mod_deflate。 當mod_deflate使用Vary時，請務必小心。 在某些情況下，Vary標題可能會導致CDN和瀏覽器完全略過快取。
-
Microsoft IIS — 使用動態壓縮。
-
不允許大型檔案或已經壓縮的檔案使用gzip壓縮。 請注意，大部分的影像和視訊格式都已預先壓縮。 在Web伺服器層級即時壓縮這些檔案時，效能成本非常高。
- 在Apache上，這可透過AddOutputFilterByType指示詞來完成： AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
- 在IIS上，這可以透過
<dynamicTypes>設定來控制。
-
如果您的CDN提供者支援Edge-side Include (ESI)，請善用此功能。 AEM元件可使用ESI進行分組。 若要這麼做，請使用Apache
\[Sling Dynamic Include\]或實作自訂解決方案。 如果您有相當多的靜態頁面，但需要在頁面的某些部分提供較動態的內容，這個選項會很有用。 針對這些情況，您基本上是將頁面分割為多個CDN檔案。 如此一來，您就可以將頁面的不同部分快取至不同時段。
-
熱門CDN提供者
以下為部分熱門CDN提供者的清單：
- Microsoft Azure CDN
- Amazon Cloudfront
- Akamai
- Google Cloud CDN
- Rackspace CDN
- Stackpath CDN （先前稱為Max CDN）
- Cloudflare
- Fastly
- F5網路CDN
此外還有數種功能，各有不同功能。
警告：
Vary回應標頭請小心。 在某些情況下，Vary可能會導致CDN和瀏覽器完全略過快取。 一般經驗是，請避免新增Vary，但 Vary： Accept-Encoding 除外（僅在回應經過gzip壓縮時套用）。 換言之，如果您需要「變更」回應的輸出，請使用不同的URL。
例如，如果您的行動版與案頭版的HTML版本不同，則使用不同的URL。 這可讓CDN和瀏覽器更有效地進行快取。
C. AEM Dispatcher快取
如果CDN快取已過期，則要求會送達AEM Dispatcher快取。 在此層級，有許多操作可以執行以最佳化快取。 如需相關步驟，請參閱如何最佳化Dispatcher快取？
D. AEM發佈執行個體
在AEM層級，應執行幾項操作以最佳化各種快取層：
-
設定下列HTTP回應標頭，這些標頭在預設情況下不會由AEM設定。
- Cache-Control： max-age=… — 若要設定此標頭，可以使用ACS Commons - Dispatcher TTL，或者您可以實作自訂程式碼來進行設定。
- Last-Modified — 如果頁面內容是相對靜態的（例如文章），則您可以將其last-modified標頭設定為cq:lastModified日期/時間（上次修改文章的時間）。 不過，如果頁面是動態的，且元件內容包含JCR查詢結果，則最好將其設定為使用目前的日期/時間。
- ETag — 如果您決定使用這個而非Last-Modified，您可以撰寫一個ReplicationEventListener，它會接聽頁面啟用並產生頁面內容的md5雜湊。 這可以在作者執行個體上的頁面的jcr:content節點上設定為屬性。 復寫頁面時，系統會將頁面傳送至發佈執行個體。 對於內容相對靜態的頁面元件，這可以正常運作，但如果頁面有點動態或參考了大量內容，則必須省略（或計算） ETag。
-
如果網站有個人化/動態內容：
-
使用Apache Sling Dynamic Include來分解內容，以便可以在不同時段快取頁面的不同部分。
-
快取可透過下列技術完成：
- CDN上的Edge端包含(ESI)
- 網頁伺服器上的Server-side Include (SSI)
- 瀏覽器上的非同步Javascript和XML (AJAX)
-
頁面上的元件可以分成不同的請求，以便針對不同的時段進行快取。 相對靜態的頁面部分可以快取較長的一段時間。
-
-
請考慮使用ACS Commons的HTTP快取功能。
-
-
最佳化使用者端程式庫。