Store CSS as files

[Kirby]

As it is right now, XenForo does deliver CSS through css.php.
This does work just fine, gives a lot of flexibility and the generated CSS can be cached efficiently by browsers.

However, doing it this way does require some PHP processing for each CSS call (there are typically 2 calls per page).
Also webservers will perform compression on every request.

While it is possible to setup a reverse proxy in front of css.php to avoid PHP processing and recompressing for every request, this is rather complicated and not smth. a lot of customers could use (due to shared hosting, etc.)

If CSS was stored as files, PHP processing (and compression if storing pre-compressed files and the webserver is configured to support that) could be avoided.
This was already suggested several years ago but rejected due to the dynamic nature of CSS URLs.

It would be nice if this idea could be given a second thought as I think it should be possible without much hassle:

1. Just before delivering the final CSS to the browser though css.php, write the CSS to a file (ideally uncompressed, compressed with gzip and compressed with brotli if available) within data.
2. Change the HTML to always point to those files
3. Have webserver rewrite rules in place to rewrite those requests to css.php in case the file does not exist
4. Add code to cleanup the generated files when CSS changes

This way, if the files do exist the webserver can just serve them (precompressed), if they do not exist they will be created on the fly.
Also this approach should be easy enough so it could benefit a lot of customers.

We are using this approach in production and it does seem to work just fine

 

[briansol]

Dynamic urls tend to not be stored as often (if at all) in archive.org. Cache hits of our sites tend to be unstyled as a result of css.php?params style URLS.

Would love to see this updated to even a friendly rewrite variant instead of an actual file cache if it's easier.

 

[Lukas W.]

However, doing it this way does require some PHP processing for each CSS call (there are typically 2 calls per page).

Realistically there's only one call per page, the core css is split out and shared between all pages, so only the first page load by a new user will actually trigger it. The css is also already being cached and only updated when you update certain things, such as addons, templates, etc., so the php processing is really just loading the cache.

 

[Kirby]

Realistically there's only one call per page, the core css is split out and shared between all pages,

Depends on your audience. If the overwhelming majority of traffic is from guests that only view one page (and leave afterwards as their question was answered), most sessions will have 2 calls.

First page view performance is important and we should optimize for this

Anyway, I've taken a different approach which was quite straightforward (serving the cached & precompressed CSS directly from Memcached/Redis without any PHP processing and compression going on).

 

[briansol]

Anyway, I've taken a different approach which was quite straightforward (serving the cached & procompressed CSS directly from Memcached/Redis without any PHP processing and compression going on).

can you share what you did?