1

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?

Tobi
  • 1,702
  • 2
  • 23
  • 42

1 Answers1

1

In short, you need to stop considering the page as a whole entity and focus on the individual page elements. The HTML can be cached with a relatively low TTL, while the more static elements like images, JS, CSS, and fonts can be cached with higher TTLs. This prevents you from worrying over purging the cache, and let the CDN handle the load for you.

The Akamai Customer Community has a great blog post that looks at managing caches with frequently updated websites. The key is to figure out the right balance between TTL and frequency of updating your content, along with supporting IMS requests and "HTTP/1.1 304 Not Modified" responses.

From the blog post:

For the rapid[ly] update[d] content, we need to balance caching and update times. Here is a good formula I recommend;

  1. HTML caching: Instead of revalidating with origin for every end user request, or having a fixed low TTL of a minute or two – imagine that the vast majority of users could receive updates every 60 seconds, with a small portion of users sometimes seeing content up to 2 mins old - but with a very significant reduction in the amount of those content refresh requests made towards origin.
  2. Images, fonts, icons can cache for a long time, as these rarely change. In the rare occurrence that these items do change, new filenames can be used to ensure new images are picked up quickly – or Akamais CCU/CCU API can be used to force content refresh. TTLs of 7 days or 30 days are common here – though I have seen sites caching for months (or more!) for very popular, very static content.
  3. The origin needs to be enabled to support ‘If-Modified-Since’ HTTP GET and HTTP 304 responses.

The times specified in (1) could be adjusted upwards or downwards, but generally I find that 60 or 120 seconds TTL on the HTML content for the vast of users tends to be a sweet spot, though some customers like the 3 to 5 minute range. The number could be in the higher range if you find your business needs for updates are less frequent. The number could also be smaller but bear in mind that we are trying to keep origin requests down – lower numbers will mean more frequent refreshes from Akamai to Origin.

...

What if I told you this CMS driven site ensures nearly all of its users HTML, JS and CSS content is refreshing from origin every 3.5 minutes - but at no point did the origin receive more than 28 hits per second from Akamai or use more than 3mbps bandwidth?

Josh Cheshire
  • 334
  • 1
  • 10