如果你有像 /新聞/ 2頁/ /新聞的每個分頁頁面上 /新聞/ 和20 20篇/ page399/ 您在理論上需要更新緩存（在Akamai或任何）如果這些400頁，如果你添加一個額外的文章到第1頁。策略，以避免
新聞網站的任何聰明的方式，以避免這種情況？
我們想過要在最後加入最新的文章。但是這對新聞網站來說感覺很奇怪。也許緩存每個部分的前10頁是一個選項？
簡而言之，您需要停止將頁面視爲一個整體，並將重點放在各個頁面元素上。 HTML可以用相對較低的TTL進行緩存，而更多靜態元素（如圖像，JS，CSS和字體）可以用更高的TTL進行緩存。這可以防止您擔心清除緩存，並讓CDN爲您處理負載。
Akamai客戶社區有一個很棒的blog post that looks at managing caches with frequently updated websites。關鍵是找出TTL和更新內容的頻率之間的適當平衡，以及支持IMS請求和「HTTP/1.1 304未修改」響應。
從博客文章：
對於快速[LY]更新[d]的內容，我們需要平衡緩存和更新時間。這是我推薦的一個很好的公式;
- HTML緩存：代替具有原點重新驗證爲每個最終用戶請求，或具有一或兩分鐘的固定低TTL的 - 想像，絕大多數用戶可以接收更新每60秒，用一小部分的用戶有時會看到長達2分鐘的內容 - 但這些內容刷新請求的數量卻大大減少。
- 圖像，字體，圖標可以緩存很長時間，因爲這些很少更改。在這些項目確實發生變化的情況下，可以使用新文件名來確保快速獲取新圖像 - 或者可以使用Akamais CCU/CCU API來強制內容刷新。 7天或30天的TTL在這裏很常見 - 雖然我看到網站緩存了幾個月（或更多！）非常流行，非常靜態的內容。
- 需要啓用原點來支持「If-Modified-Since」HTTP GET和HTTP 304響應。
在規定的時間（1）可以向上或向下調整，但一般來說，我發現，在HTML內容，爲廣大用戶的60或120秒TTL往往是一個甜蜜點，雖然有些客戶喜歡3至5分鐘的範圍。如果您發現您的業務需求更新頻率較低，則該數字可能處於較高範圍。這個數字也可能更小，但請記住，我們正試圖保持原始請求的下降 - 較低的數字意味着更頻繁地從Akamai刷新到Origin。
...
如果我告訴你這個CMS驅動的網站幾乎都確保其用戶的HTML，JS和CSS內容是從原產地刷新每3.5分鐘 - 但在任何時候，產地獲得超過來自Akamai的每秒28次點擊或使用超過3mbps的帶寬？