Pretty much at the end of my wits on this issue. I’m using Newspaper 6.5.1 & W3TC, which I’ve said before I hate but have since moved to a managed VPS that is built to use it for APC and Varnish.
The problem I’m getting is encoded pages being served from the page cache module, regardless of what other modules are or are not enabled. If I change themes to something from a different developer, the problem goes away. The W3TC plugin FAQ on WP.org addresses this and says it’s due to the use of php_flush() or the function flush() by the theme, but I’m not seeing that in the header, index, or footer files though it’s entirely possible that one of those calls is in a deeper file.
Here’s what it looks like:
This has been an on-going issue for me since about July of last year (I’ve kept Newspaper up to date within a few days of every update) and has remained consistent across two hosts (one cloud shared and one VPS). At the time this started W3TC was the recommended caching plugin for theme and even though that recommendation has changed, it’s not because the plugin breaks the theme. I can’t figure out what’s going on.
The host has looked into it with no luck. The W3TC support team doesn’t exist. And I’m not seeing the flush methods called from the theme to answer the documentation’s claimed cause of the problem.
Any ideas? I’m at a loss now. I’ve got a beautiful varnish/memcached/apache/nginx setup going to waste because of this and it’s starting the impede growth of the site.
Thanks.
And for good measure, I’ve tested with all gzip compression settings in W3TC disabled. No change.
Hi Bryson,
Unfortunately it is very hard to debug this thing without replicating it.
We run the theme about one year ago on nginx + w3total cache and we did not encounter any problems. I’ve also used in that time the APC user cache.
Why can’t you switch to disk caching + wp super cache? Even when disk caching is used, the linux kernel will actually cache the files in memory if ram is available : https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics
We tested the apc cache VS the normal disk cache and we did not found big improvements. We are currently using wp super cache and normal php disk caching on all of our installs.
Please send me the page (by using save as)…. the page source is encoded?
Part of it not understanding what you mean by “disk cache” in that reply. I have APC, Varnish, Memcache, Apache and Nginx all running. It’s a Cloudways managed setup, so my options are somewhat limited. My understanding is that WP Super Cache doesn’t work with reverse proxy or any of the other advanced stuff.
Your installs may not matter on this issue because you don’t have but a few plugins on any of the demos. Extra plugins means extra bloat and more need for premium caching.
Any further help on that is appreciated.
And as for W3TC’s claim that some flush method is responsible… are any instances used in the theme that I missed?
Thanks, Radu.
Hi,
with disk caching I was referring to the caching method used by w3 total cache and wp super cache that save the page on the HDD/SSD. W3 total cache also supports caching to APC user cache or memcached. I was tring to point out that wp super cache, even if it saves the page on the hdd/sdd can be as fast as APC or memcached due to the linux’s kernel caching mechanism.
We switch our recommended caching plugin to wp super cache because it’s written better, it’s maintained by automattic (the WordPress developers), it’s leaner and overall we did not encountered many problems with it.
Regarding the flush methods… there are 2 instances: http://screencast.com/t/qO7msUmvI – this is an experiment it may not work.
What caching method are you using now? Your site gets a very good response time from my end even when I’ve bypass cloudflare: http://screencast.com/t/xZ3x2n4Jdvw8 . TTFB is very good and I do not think you can push it more without hardware updates. I’m on the other side of the globe relating to your server and 363ms first page load is very good here with USA.
Regarding the flush calls, since that’s in TGM I don’t know if that counts. Doesn’t seem to me that code is run on every front end page load to throw W3TC off. But you tell me?
Right now I’m using W3TC with just the reverse proxy, browser, and database cache modules active. That’s with a very lightly applied Varnish cache (doesn’t do much for WP without page caching activated), apache, nginx, and APC running. It’s actually a smaller server at the moment, but handled some better loads yesterday. Using SSDs. I’m going to upgrade it in the next week or so, which will help.
My main concern with speed for mobile (more than half my traffic is mobile) and a caching plugin that doesn’t hold stale pages. WPSC tends to not update the front page cache for half an hour after a new post is published. I’ve used it with Newspaper.
Bryson, try this. Deactivate w3tc and install wp rocket + TagDiv Speed booster. Few months ago i was on Nginx server and this config works very good for me
Can’t use WP Rocket though… conflicts with some tracking codes used for ads. Or at least my ad people tell me. Shame too, because I’ve heard good things about it.
Thanks for the tip, tho.
And one more comment; make sure your server has 10/100/1000 switch vs 10/100 switch/connection in datacenter. Most older hosting companies only provide a 10/100 connection to the network where the modern servers all work better with gigabit switch. Even in our Class A datacenter (owned by IBM) we had to “ask” for that upgrade with our newest server package end of 2013, which was dumb. Now in 2015 they finally made that “standard” — but some still won’t give it to you unless you ask, or in some cases pay an extra $10/mo or whatever — it’s totally worth it as you have a 10x faster connection to the net for your physical box.
In case you were not already aware of that 🙂
I was aware of the sppeds, but not how hosts treat it. Thanks for the tip, Chris. I’ll contact them today.
I do, yes.
