如果你有像 /新闻/ 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的带宽？