Caching 避免缓存分页页面更新的策略

如果你有20篇关于 /新闻/ 每个分页页面上有20个 /新闻/第2页/ /新闻/第399页/ 从理论上讲，如果在第1页中添加一篇额外的文章，则您需要在这400页中的每一页更新缓存（在Akamai或其他网站上）

新闻网站有什么聪明的方法来避免这种情况吗

---

我们考虑在结尾添加最新的文章。但对于一个新闻网站来说，这感觉有点奇怪。也许缓存每个部分的前10个页面是一种选择？

简而言之，您需要停止将页面作为一个整体来考虑，而将重点放在各个页面元素上。HTML可以用相对较低的TTL进行缓存，而图像、JS、CSS和字体等静态元素可以用较高的TTL进行缓存。这可以防止您担心清除缓存，并让CDN为您处理负载

Akamai客户社区有着巨大的发展潜力。关键是要在TTL和更新内容的频率之间找到正确的平衡，以及支持IMS请求和“HTTP/1.1 304未修改”响应

从博客帖子：

对于快速更新内容，我们需要平衡缓存和更新时间。这是我推荐的一个很好的配方

HTML缓存：不必为每个最终用户请求重新验证源代码，也不必设置一两分钟的固定低位TTL——想象一下，绝大多数用户可以每60秒接收一次更新，一小部分用户有时会看到长达2分钟的内容，但向origin发出的内容刷新请求数量会显著减少

图像、字体、图标可以缓存很长时间，因为它们很少发生变化。在这些项目很少发生更改的情况下，可以使用新文件名来确保快速拾取新图像，或者使用Akamais CCU/CCU API强制内容刷新。7天或30天的TTL在这里很常见——尽管我已经看到一些网站为非常流行、非常静态的内容缓存了数月（甚至更长！）

需要启用源站以支持“如果自修改”HTTP GET和HTTP 304响应

在（1）中指定的时间可以向上或向下调整，但一般来说，我发现对于大量用户来说，HTML内容上60秒或120秒的TTL是一个最佳选择，尽管一些客户喜欢3到5分钟的范围。如果您发现更新的业务需求不太频繁，则该数字可能在更高的范围内。该数字也可能更小，但请记住，我们正在努力降低源站请求的数量–数字越低，则意味着Akamai向源站的刷新频率越高

如果我告诉你，这个CMS驱动的网站确保几乎所有用户的HTML、JS和CSS内容每3.5分钟从源站刷新一次，但源站从未收到Akamai每秒超过28次的点击，或使用超过3mbps的带宽，该怎么办