Option to load CSS files directly via web server

Your rewrites 100% push all static files to PHP like I indicated at the start. Here’s the complete rewrite code:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /wp-content/cache/minify/
    RewriteCond %{HTTP:Accept-Encoding} gzip
    RewriteRule .* - [E=APPEND_EXT:_gzip]
    RewriteCond %{REQUEST_FILENAME}%{ENV:APPEND_EXT} -f
    RewriteRule (.*) $1%{ENV:APPEND_EXT} [L]
    RewriteRule ^(.+\.(css|js))$ /index.php [L]
</IfModule>

For optimal performance these should *never* rely on PHP. Think about scenarios where there’s thousands of new simultaenous visitors. nginx can handle that kind of traffic for static files all on its own, but these rewrites make it so that nearly every page load of every single static file requires PHP to serve. (Minus browser cached of course, but this doesn’t help with there’s a lot of unique traffic)

This is why I’m asking for the option for a direct link to the file on disk in the static HTML output – doing it that way will ensure better performance AND simpler compatibility with Plesk’s default nginx config.

Keep in mind that this is the same priciple as why you already have static HTML page output working that way – to avoid PHP processing. It should be the same for static files that were like that from the start – it shouldn’t be *more* PHP processing necessary than before W3 got involved.

• This reply was modified 1 month, 2 weeks ago by websavers.
• This reply was modified 1 month, 2 weeks ago by websavers.
• This reply was modified 1 month, 2 weeks ago by websavers.
• This reply was modified 1 month, 2 weeks ago by websavers.

Thanks @vmarko

Your notes above indicate that there should be static files in wp-content/cache/minify/

And I’m finding now why this isn’t the case for me. Those files only exist if I turn off “Rewrite URL structure” which uses requests like this:

https://schelew.com/?w3tc_minify=a5ff7.css

That definitely gets passed to PHP becuase it’s a query string.

If I then disable “Rewrite URL structure”, the static files remain and are loaded by the web server (great!) until the minified cache is cleared, at which point they are again not written to the minify folder, so they can never be loaded by the web server (not so great).

With Rewrite URL structure ON someone needs to request those static resources once to get them generated in the first place, then after that first load of the file, they’re fully static. This means only the first load would require PHP.

This method of JS/CSS file generation creates problems in a performance optimized environment because of two optimizations:

1. Those using Plesk with nginx’s static file handling enabled may never hit the rewrites, and
2. Those using an apache 404 handler for static files that keeps those requests lightweight (to avoid repeated 404s bogging down the server/website) will not hit those rewrites and instead will be served a 404.

I propose an option where you disconnect the static file generation process from loading the static file itself. Instead when a page’s cache file is generated, *also* generate connected static files at the same time. This way you don’t rely upon rewrites for the static files to work for *any* static file loading to function in these environments.

Meantime I’ll get working on adding the minification rewrites in nginx, as I now see that with the right config, it doesn’t *need* to hit PHP every time – just the first load after new minified files are generated.

Hey Mario,

As you probably know, the default for most hosting environments with WordPress is to pass all non-existent files directly to index.php.

This presents a performance problem: what happens if you’ve got one (or more) static file(s) that’s included one very page and suddenly turns into a 404? Every single page load is going to generate PHP processing, for absolutely nothing: simply to say “this file doesn’t exist”. Now magnify this on a very busy site and you’ve got dozens, maybe hundreds of PHP processes being launched just to say a file doesn’t exist. I’ve seen this in practice and it’s not pretty.

It makes no sense to do that.

And so we – along with other WP performance optimized hosts – have either server-wide nginx or apache rules (it was easier to do it in apache for us) that explicitly check for 404s for static files and immediately serve a simple 404 page rather than allow it to be passed to PHP.

The problem, as I’ve now discovered, is that W3’s minification system requires the first load of any css or js file to be sent to PHP, which the above noted rules will not allow. This hasn’t been a problem with other optimization plugins because they all appear to generate their minified files when the *page* is generated, not when the static file is loaded.

I’ve written an exception for this into our apache rules that detects if the static file request is for a non-existent file within a ‘minify’ folder and sends it through to PHP after all. I’d rather not have to do this though. And I suspect you’ll find better support for your minification system if you’re able to link the minfication process to the page and not the static file load.