Improve the front end caching mechanism

[jonasraoni]

Introduction

Our applications generate mostly static content, and the frontend lacks a good caching mechanism.
A nice cache strategy will highly improve the performance. The drawbacks are minimal, because once articles are published, it's unlikely the output will be changed often, it's not as sensitive as a product stock.

Current status

We have two settings, [cache].web_cache and [cache].web_cache_hours, which enable a global cache for a couple of static pages, it works, but it has problems and can be improved.

• It can cover more static routes
• It doesn't make use of caching headers.
• When cached content is served, it doesn't trigger the generation of statistics.
• In a multi-journal installation, where each journal uses a custom domain, the cache of one journal might be overwritten by another.
• The current strategy generates a full page cache, which has bad limits. The cache cannot be used when there's a logged in user, POST data, different arguments, etc.
• The cache invalidation is per time. Therefore after some time, everything is invalidated, which is not ideal.

A plugin was created with some of the ideas presented below: https://github.com/jonasraoni/frontEndCache.

Ideas

First step

• It should be easy to enable the cache (maybe enabled by default) and clear its data, the only dangerous setting is the max-age (the browser will be lazier to look for updates)
• Store the generated cache using gzip, therefore the content can be served packed right away (if unsupported by the client, unpacking instead of storing N different formats is an option).
• Investigate the feasibility of supporting better algorithms (zstd/brotli).
• Make use of cache headers, the etag (hash check) and cache-control (specify when a new request/cache validation should be done) are enough.
• The statistics must be triggered. But instead of sending a useless request, just to fulfill this purpose, a JavaScript trigger might fit better... It will also help to decrease statistics related with bots (a real browser, that can run JavaScript and send the request will be less flawed than our isBot() check), this will also allow playing with higher max-age values for the cache-control.
• More static routes should be covered (e.g. sitemap).
• Some types of paged content do not need to be cached extensively, as nobody goes until the N page, except bots.
• Use the Laravel framework to store the data, in order to allow the usage of a distributed/memory based cache (e.g. Redis).
• When the cache is about to expire, it's feasible to regenerate it on the background, then the next user won't suffer a penalty.

Second step

Ideally we should probably implement a granular cache strategy at a template level. This will allow us to cache content even for logged in users. The content should be better fragmented, and each include should have its cache controlled individually (e.g. if the template has user data, the cache can be done, but it cannot be shared).

As templates can have hooks, plugin developers should be able to integrate with the cache invalidation (e.g. change the expiration, content hash, implement a callback, ...).

Third step

The cache invalidation can be improved. Instead of invalidating by time, we can listen to events, check modification dates of records, make use of hashes, etc.
Preemptive cache, where we generate cached content after saving a record, is also an option, it would probably require defining a dependency chain.

Fourth step

Back end caching can be done as well.

[asmecher]

There is some overlap between this issue and #11377 -- linking them together.

[asmecher]

@jonasraoni, I'd be interested in exploring ways to support a variety of front-end caching tools. The old web_cache option was pretty brutally simple, and while that kept requirements low, it was kind of a dead end. If we're able to improve our infrastructural tools to better support good practices around last-modified dates and HTTP headers, then maybe we can use the same mechanism to implement both a built-in (probably still simplistic) model, but leverage the same toolset to support something richer like an external caching proxy.

Hopefully we can rely on Laravel for significant parts of this, e.g. cache the implementation and perhaps even some of the last-modified stuff, but we'll be a little hobbled in that by our partial adoption of both Eloquent and our non-Laravel handling of page requests. Charting a path towards standard adoption of Laravel would be a good thing here, and would hopefully keep us from growing out more custom code (and tech debt), which I'd really like to avoid.