如果您在/ news /上有20篇文章，并且每个分页页面上有20篇文章，例如/ news / page2 / / news / 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未修改”响应。
来自博文：
对于快速[更新] [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的内容带宽？