Yes, agreed, 512 MB of caching for something like njump.me is basically nothing. That’s the nature of caches. Especially with crawlers doing range scans, cached stuff will certainly be evicted. Cloudflare also wants you to upgrade to an Enterprise plan so they can make money that’s how you unlock the much more useful 5 GB cache.
Still, there are things you can do with the Free and Business tiers, such as Cache Rule magic, Tiered Cache, Cache Reserve (very useful, but the R2 free tier is consumed quickly and costs can shoot up), Always Online, etc.
nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp a few comments on your changes:
1. For immutable events, there’s no reason not to cache them for a whole year. You can always purge items from the Cloudflare cache if really needed. Also,`public` is implied by `s-maxage`. Finally, I forgot to mention this earlier, but `stale-while-revalidate` can also help keep things running faster for end users when njump.me is under load.
```
Cache-Control: max-age=604800, s-maxage=31536000, stale-while-revalidate=86400, immutable
```
2. I don’t think the `ETag` implementation based on event ID worked, or maybe Cloudflare is stripping it: https://developers.cloudflare.com/cache/reference/etag-headers/ . When I hit an event rendering endpoint I'm not getting an ETag back. Also, don’t forget to add one to the profile rendering endpoint, since I assume this is one of the most popular kinds that can’t be made immutable when caching.
Without either `Last-Modified` or `ETag`, Cloudflare falls back to "Smart Edge Revalidation", which, while better than nothing, in my experience can be finicky with the reverse-proxy hitting the server quite often: https://developers.cloudflare.com/cache/concepts/revalidation/ . So it’s definitely worth sending at least one of these headers on all cache-enabled responses.