Page caching seems not working or does it?

They might be getting added via your server level rules. Or maybe some other plugins? It’s impossible for me to say what’s adding that second cache control ruie. You need to dig deeper to find that out.

So there is no way to find out the source of the response? That means your plugin doesn’t work until I get rid of the second cache-control? What makes me wonder as the error message says if I see cf-cache-status:HIT then the caching works.

The server setting is currently set to Ngix. There are bypass options you see in this pictures:
https://support.plesk.com/hc/user_images/ZWQfeaeitnCdancS56tujg.png

Could they interfere here?

//Edit: I see in the network logs that for instance jpg (cache-control:max-age=31536000) have just one cache control header but JS or the main document have two. So does it mean just jpg get handled by the CF plugin cache right now?

• This reply was modified 3 years, 10 months ago by mike8040.
• This reply was modified 3 years, 10 months ago by mike8040.

What makes me wonder as the error message says if I see cf-cache-status:HIT then the caching works.

– The plugin works but it confuses the browser and CF system with two cache control header. They are confused between which one to follow. This might lead to lower cache hit and quick cache expiration from CDN.

I see in the network logs that for instance jpg (cache-control:max-age=31536000) have just one cache control header but JS or the main document have two. So does it mean just jpg get handled by the CF plugin cache right now?

– Static files are not handled by the plugin. So whatever cache control you set for the static files CF will follow that. For the dynamically generated pages, you need to run search in your server with the cache control value to see from where it is getting added.

OK, I’m having a hard time to understand your instructions. But in the meantime I think I solved it. I did deactivate ngix caching, removed two entries in the htaccess and set Browser Cache TTL in CF to a period from “respect the header”. Now the second entries are gone. Still the first byte test is bad with >3s. Not sure if about re-activating ngix caching. Doing testing.

Do you recommend to use CF Rocketloader and CF minimize function?

Do share your website url so that I can run test on my end

Its acido.shop

So, upon checking your site I saw that when I go to https://acido.shop/ it 302 redirects me to https://acido.shop/en/

Now the https://acido.shop/ 302 request has cache-control no-store, no-cache, must-revalidate which tells CF not to cache that request. https://i.imgur.com/Q1DCHsS.png

But when I am checking the header of https://acido.shop/en/ I can see that proper cache control header there and that page is being cached. https://i.imgur.com/6BtJGhm.png

But then again the cache control header of that request is not what the plugin is adding. As you can see the plugin cache-control header in the value of x-wp-cf-super-cache-cache-control.

The value of cache-control header and x-wp-cf-super-cache-cache-control should match.
Which is not the cache for your site: https://i.imgur.com/XdHeRIh.png

Now for running the TTFB check you should run that on the actual path that users are seeing and CF is caching so run it on https://acido.shop/en/

Also, make sure you don’t have any other page rules in the CF beside the one added by the plugin

Thanks a lot for investigating even I’m not sure what to make out of it. The /en path is a redirect by WeGlot translation plugin that switches to it by checking the browsers language. I try to deactivate the auto redirect and test it.

Oh you use WeGlot translation? It’s not cache friendly. It changes the URL in browser without actually sending a request to the server for that URL.

Yes, wasn’t keen on the alternatives out there and Polylang does take long to setup. Do you suggest to get rid of WeGlot completely or just the redirect? Do you know an alternative you would recommend?

Its weird as with Wp-Optimize caching in conjunction with CF I got <0.2s First byte results and overall a really good performance even on mobile. So you definitely right that something shady is going on in the background right now.

Do you suggest to get rid of WeGlot completely or just the redirect? Do you know an alternative you would recommend?

– Well, you can try turning off the redirect and see. I’m not sure about the other stuffs. The reason I was able to tell you about the WeGlot translation is because I’ve seen the same issue on other websites.

Inside the plugin settings if you enable Purge HTML pages only then under that settings you will see a option for Show cached HTML pages list which basically shows all the pages that received a request and cached by CF and the plugin. Screenshot: https://i.imgur.com/jeGBp79.png

Now when using the WeGlot translation and you visit to different language pages, you will see that this list doesn’t get populated by those language URLs. WHich means the server is not receiving a request for that URL and hence CF is not seeing that as well, so it can’t cache it.

Thanks for clearing it up. After some tinkering I decided to ditch WeGLot and go the Polylang route again. Seems they did some workflow updates since I last used it. Anyway I couldn’t get any suitable or better performance with CF Super Cache plugin in my case and switched back to CF with Wp-Optimize. Thanks for your help

If you translation plugin is adding cookies to pages then CF won’t cache them as when CF sees a custom cookie on any page it thinks that the content of that page might be dependent on the cookie value and hence don’t cache that page.