If you have 20 articles on /news/ and 20 on every paginated page like /news/page2/ /news/page399/ you need in theory update the cache (on Akamai or whatever) for every if these 400 pages if you add one additional article to page 1.
Any clever way for news sites to avoid that?
We thought about adding the latest article at the end. But this feels kind of strange for a news site. Maybe caching just the first 10 pages in each section is an option?
答案 0 :(得分：1)
简而言之，您需要停止将页面视为整个实体，并专注于各个页面元素。 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的带宽？