Page/Post Specific Cache Length

Thank you! I appreciate the feedback! There are some more things coming down the pipeline at WP Engine that will impact performance that I am looking forward to, so hopefully you’ll get to take advantage of those.

I do understand the use case here, and it is something I would hope to implement for another reason in the future. In some themes the homepage isn’t associated with a post type, so the plugin never picks it up, so it defaults to 10 minutes. That would be a big use case for being about to increase the cache time, in addition to this one here.

That said, when a post or page is created, the homepage is purged as part of that function, so if there is a feed or anything like that on the homepage, it should be getting the updated content. This would allow you to leverage the longer cache time while also getting that content live on the homepage that much faster.

Another option would be the “Smarter Cache” option and a smaller time. If the other pages aren’t updated, it’ll start setting the cache times to 6 months but won’t touch anything that’s been updated more recently.

Let me know if you’re seeing any challenges with either of those options, and I can see what I can do to help.

Thanks!

Hey Ethan,

I’m guessing it might be because we’re running CF too, but the homepage won’t seem to update unless I flush caches. That said, your Smarter Cache is a brilliant workaround. I honestly think that is better than what I was requesting. It does make the cache ‘smarter’ (nice naming-work there hah). It would allow us to get all the benefit of the increased cache length, without the downside of the site not updating!

Great option, and thank you for your help! I’m looking forward to the new things coming down the pipeline!

K

Hey Ethan, one question with this, does the smarter cache only work with posts / pages… or will it work with other stuff, for example:

– Custom post types
– Rest APIs

K

That sounds like it probably is cloudflare if I’d have to guess, their plugin has the ability to kill the cache when the “appearance of the site changes”, so I’d try that and see if it helps with the stale content. Also try an incognito tab to make sure it isn’t chrome caching it if you haven’t already.

It does work for custom post types, but not rest routes. The cache for the routes is killed on updates too, so I don’t think it’d get much of a benefit outside of the normal cache increases. I’ll keep it in mind when I revisit that stuff though in the future.

Awesome, thanks Ethan.

Can you explain the cache on those APIs? It makes much more sense with posts / pages / cpts… I don’t really understand what caching the apis would do

K

Yeah!

For the average person just using WordPress as a front end it probably won’t make a difference, but if you’re using the APIs to pull content into a headless frontend or something like that, increasing the cache of those endpoints is super important.

The APIs are just like the concentrated version of your site’s content, so it makes even less sense to cache them for only a short amount of time, especially when they could theoretically do a lot of concurrency. In most cases it’s probably better to think of the posts/page cache and the APIs as an or solution instead of an and, since you’re probably only going to be getting the benefit out of one or another at any point.

I am really excited about WordPress as a headless CMS, so allowing customization to the rest routes allows the plugin to be feature forward for something I am hoping takes off in the future.

Hah alright given I lost you in the first paragraph… I’m guessing messing with the rest APIs are not for me!

Thank you Ethan!

K