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…

Yes.

I made a small video tutorial. check this out

I read your question. In this guide, it doesn’t cache if the URL contains a query string. That’s what it shows here. If the URL contains a $query_string, which is an embedded variable, then it sets the condition to null, and thereby the fullURL contains null string; hence the PHP content are served since wordpress is unable to find null folder. So I suggest you to remove it. Let me know how it goes. I don’t think this is valid in nginx. “location ~ /?lang=.* “. I suggest to use $query_string variable provided by nginx for matching query strings. nginx also has $arg_name variable, where name is the parameter. You can use it in between location to match en and ru so easily. like $arg_lang, or you can use map too, which is very simple, but use it outside of the server block.


#Use this outside of Server block
map $query_string $lang{
~lang=en en/
~lang=ru ru/
}

#remove this, as you use query string with cache on
if ($query_string)
{
set $condition "null";
}


In your case the code can be corrected as this.

I didn’t test this, so let me know the result. This works like this. first condition variable is created and assigned nothing, then it checks the request method, if it’s post then condition is null, or it’s ”. likewise it checks the http cookie, if request has any of mentioned cookie then condition is null, otherwise ”. It creates a new variable fullURL, and is assigned /wp-content/cache/all${condition}. If the condition is null, then it’s /wp-content/cache/allnull, otherwise /wp-content/cache/all, which is the correct one to make cache works. So now cache only works if POST request isn’t used, and mentioned cookies are not used. When the URL matches /, meaning anything like yourwebsite.com/, then it creates a variable serve_URL and is assigned, $fullurl${uri}${lang}index.html. it has three variables, FULLURL, which you used, URI meaning the requested URL, and lang url, which calls map module to checks. Map module evaluates the value in query_string, if it’s lang=en, then lang variable is assigned en, if it’s lang=en, then lang variable is assigned ru. If no query string presents, then lang is an empty string. you can use default too, but it’s not needed. ~ is used in front to imply it’s a case sensitive check.
https://stackoverflow.com/a/45129826/7409460

Assuming the condition variable is ”. if query string is lang=en, then lang is en, if uri is /, then serve URL is
ignore +, I used it so it’s clear.


$fullurl${uri}${lang}index.html
/wp-content/cache/all + / + en/ + index.html
/wp-content/cache/all/en/index.html

Assuming the condition variable is ”. if query string is lang=en, then lang is en, if uri is /wp-fastest-cache-configuration-for-nginx/, then serve URL is
ignore +, I used it so it’s clear.


$fullurl${uri}${lang}index.html
/wp-content/cache/all + /wp-fastest-cache-configuration-for-nginx/ + en/ + index.html
/wp-content/cache/all/wp-fastest-cache-configuration-for-nginx/en/index.html

You can change the position of lang variable too, like if en comes before URI, but pay attention to forward slash always.


$fullurl${lang}${uri}index.html


so if it comes first use in map
~lang=en /en
instead of
~lang=en en/


$fullurl${lang}${uri}index.html
/wp-content/cache/all + /en + / + index.html
/wp-content/cache/all + /en + /wp-fastest-cache-configuration-for-nginx/ + index.html


I will look into it.

Hello Dear Sir or Madam.

I have a problem with caching of URL QueryString format /post-name/?lang=en
I was trying to fix it using your article: https://nucuta.com/wp-fastest-cache-configuration-for-nginx/
Our site has two languages: Russian (main) and English.
Using plugins: WPML Multilingual CMS v4.0.3 and WP Fastest Cache v0.8.8.2
In file wp-config.php I added define(‘WPFC_CACHE_QUERYSTRING’, true);
Plugin wp-fastest-cache creates folders for each language
/wp-content/cache/all/ru
/wp-content/cache/all/en

I changed settings in Nginx conf:
set $fullurl ‘/wp-content/cache/all/ru${condition}’;
set $fullurlen ‘/wp-content/cache/all/en${condition}’;

And added section:
location ~ /?lang=.* {
set $serve_URL $fullurlen${uri}index.html;
try_files $serve_URL $uri $uri/ /index.php$is_args$args;
}

Russion version is working right but English one is caching only via php as I saw in tag
Also in catalogue /wp-content/cache/all/en there are cache pages.

Please tell me how to fix this. I really appreciate.
Or probably you will want to write a decision in your article which I think will be so usefull for other people.

Thank you so much.
Have a good day.

Thanks for your feedback. I updated the post, please check at end of the post. 🙂