Pinterset

Would you like to try it for free?

I was shadow banned from messaging other users & my posted questions ( after the 30 day ban ) were removed within 1 minutes. Again I contacted SW support asking why ?

I was permanently banned ( IP Banned ) If you question the SW Team’s rules then they take actions against you.

Moderators have favourite users, they can bend the TOS with no action against them. These user are very outspoken & popular BUT they draw plenty of answers to their questions or comments which is good for SW.

With only 2 controlling Mods SW is a total dictatorship, if you are not liked by a mod,,,, you will be restricted, limited or suspended in the future.

Reddit is not great but mods don’t pick and choose whom they like.

Here is why: WP Fastest Cache already does almost all work for you, out of the box. Beyond any WordPress-specific things, all you need to do is check if an URL has been stored in the cache or not. You don’t need Nginx to figure out first if a user is logged in etc. etc. since WP Fastest Cache already deals with all of that — you might get everything you’ve typed with just

location / {
try_files /wp-content/cache/all/${uri}/index.html $uri $uri/ /index.php$is_args$args;
}

That’s all it takes. The rest is up to WP Fastest Cache to figure out, and it does a remarkably good job at that.

Granted, if you really want to, you can add a bit more code to properly set header files. That would require adding another location section, specifically just to find if something is already cached, and, if so, do the appropriate reply with an additional header showing that; if not, it falls back to the usual WP try_files.

For multisite installations, you’d use a variant:

location / {
try_files /wp-content/cache/$host/all/$uri/index.html $uri $uri/ /index.php$is_args$args;
}


And as Anastasia already explained, WP Fastest Cache can also deal with different languages as well with yet another twist.

Things just become slightly more complicated if you have enabled separate caches for mobile and non-mobile versions of your website. In such a scenario, you’ll need to split things among both — because WP Fastest Cache will keep two separate directory structures for that.

However, these days, the burden of figuring out what to render for a mobile device has been mostly addresses at the HTML side of things; mobile devices basically just pull whatever HTML is there and formats it accordingly. The option for having two separate structures made sense around 2007, when the iPhone was launched, and most websites were not designed for such a small form factor, so website owners would just use a very basic template for mobile, and switch to it according to the device being used. But nobody bothers to do so any more in the 2020s — it’s so much easier to build your HTML/CSS around flex or similar technologies to make it fully responsible. As such, I would simply forget about mobile, and just worry about the rest.

Granted, if you’re lazy and want a one-size-fits all solution, nothing prevents you from doing a try_files on all possible combinations, even if you know beforehand that some don’t exist. The way the Nginx engine works, anything done with try_files is way faster to evaluate than doing complex queries to figure out how exactly you should construct your URL/path. Instead, Nginx is super-accelerated to execute
try_files blindingly fast — so long as it gets some help from the other end, i.e. the caching plugin. And that’s one of the reasons why WP Fastest Cache is so useful: it’s got a very regular and logic way of organising the cache on disk, so that web servers can very easily check if a file is on cache or not.

Hint: if you want things even faster, put Cloudflare in front of your website. It’s free, and WP Fastest Cache will very easily integrate with it. With a bit of magic, you can essentially push a substantial part of your website (HTML, CSS, JS, images, fonts, and other media) to Cloudflare — and force people’s browsers to cache as much as possible on their end — and essentially let Nginx take a break (not that it needs to). Watch carefully as your server’s CPU usage drops to zero and how MySQL suddenly has little to do, while getting insanely fast performance (well, if you pick a modern WP theme that was designed from scratch for performance…) and unbelievably low overall latency. The results are simply fantastic.

To be honest, while I’ve been using WP Fastest Cache for an eternity now (with Cloudflare), I’ve only noticed all of the above relatively recently. The more I simplified the Nginx configuration to pt as much as possible inside try_files and as few conditions outside it as I could master (these days, they are hardly more than listing what is static content and flagging it as such; all the rest is up to try_files), the faster were the results, to a certain degree of bafflement. Like you, I started from a reasonably complex set of rules to figure out which cases needed to be retrieved from the cache, and how to properly construct URLs or pathnames for each scenario. At the end of the day, however, I figured out that most of that is absolutely unnecessary. All these tools work seamlessly together, and there is no need for giving all those “hints” to any of them — that’s just overoptimisation (which might have been important a decade ago) which will consume CPU to replicate what the many components already do on their own without further configuration…