Article cache times in your app
Table of Contents
The length of time we cache articles for depends on the age of the article (an exponential back off algorithm). We have three different options here, depending how important it is for you that updates are quick. These options control the Time To Live (TTL) in the cache on the device - the app will only check for updates to these articles once the TTL expires.
Performance Trade Offs
Note that the more often we check for updates, the more requests the app will make. This means that performance in the app will be slightly worse, and you'll use slightly more bandwidth.
Note: Shorter cache times are appropriate if you have stories that update with new content frequently. However, if it is purely for fixing mistakes it is probably not needed. These cache times only affect users that have already seen the article, and users very rarely go back to read old articles.
We understand that editors often return to view articles in a way that users don't. Instead of making the experience worse for all users, we recommend editors clear their cache to view updates.
Default
Unpublished: 1 second cache
Less than an hour old: 1 hour cache
Less than 2 days old: 1 day cache
Older than 2 days: 1 month cache
Fast TTL
Unpublished: 1 second cache
Less than an hour old: 1 minute cache
Less than 2 days old: 5 minutes cache
Older than 2 days: 6 hour cache
Older than 1 month: 1 day cache
Very fast TTL
Unpublished: 1 second cache
Less than an hour old: 10 second cache
Less than 6 hours old: 60 second cache
Less than 12 hours old: 180 second cache
Less than 1 day old: 10 minute cache
Less than 1 month old: 1 hour cache
Older than 1 month: 1 day cache
Checking the TTLs
X-Pugpig-Content-Age
and X-Pugpig-Content-Age-Bucket
we return. For example, in the terminal:curl -I https://test.content.pugpig.com/2019/01/29/my-article/pugpig_index.html
HTTP/1.1 200 OK
X-Pugpig-Content-Age: 26672901s
X-Pugpig-Content-Age-Bucket: older than 2 days, 1 month cache
Cache-Control: max-age=2592000
You should also be able to check the headers on anything by opening it in the browser and looking at the response headers for the item after re/loading it in the network tab of the browser console.
You can also use a proxy tool to check these headers (for example, if you're looking at an app).
Other ways to control the TTLs
We have two other ways to control the TTLs, which will override the settings above:
- edition_based_ttls - this allows us to set a fixed TTL for certain editions, for example you may want your Latest News edition/timeline to be quicker
- page_type_ttls - this allows us to set a TTL based on the type of page. For example, if you have certain kinds of stories that update more often, we could use this.
Questions/Comments
Please sense check - TTL will not have an effect on anything already cached.
Also there are 6 references to TTL - what do each of them do?
page_type_ttl - above, but how do we use it?
editions_based_ttl - above, but how do we use it?
content_backoff_ttl_algorithm - what is this and how do we use it?
bolt_timelines_json_ttl_seconds -