Support » Plugin: W3 Total Cache » Don't upgrade to v. 0.9.3 for now

  • It has done more bad than good to some servers of ours.

    Basically there’s an high chance the minify will screw your blog over.

    Even emptying the caches, v 0.9.3 may cause jquery to not get loaded and affect the rendering. Those with responsive themes like Montezuma basically get a blank page (content is still there, if you select you see the writings are still there, just white on white).
    Disabling minify immediately restores the website.

    Another issue comes directly in the minify window. Some options that may be disabled, return enabled after you save the settings. Furthermore, invoking the helper popup to get the list of minification candidates (JS and CSS) usually results in it being showed for 2-3 second and then a redirect to… nothing. W3TC just hangs and stays stuck till you load another page.

    Anyone experiencing these issues should revert to that one works much better.

Viewing 6 replies - 1 through 6 (of 6 total)
  • Do you have to delete 0.9.3? If so will it retain settings when reverting to

    I exported the settings just in case, then downgraded.

    The downgrade retained the settings.

    I’ve experienced the same issues with W3 9.3 on my political news blog. I eventually disabled minify totally in W3 and installed WPminify. I retained the speed W3 affords due to it’s precise expires headers and the WPminify does an excellent job with compressing and combining the JS, CSS and HTML.

    Folks, I am running (reverted from 0.9.3 after initial failure) and facing some issues. The inconsistency is with TTFB when I test it on webpagetest. Sometimes it gives an A but mostly goes back to rating C soon. Here’s the link to the affected site. Everything else works perfectly except the time to first byte.

    Has 0.9.3 done any good with respect to initial byte speed?

    For what I recall, 0.9.3 fixed some open issues (not all enabled caching would work) and added some features and broke others. I don’t recall anything special being done about reducing TTFB though.

    There are zillions of reasons for bad TTFB and several are due to just bad hosting. But there are others that may be tweaked. I.e. the cache self invalidates after a settable period and you can change that.
    The cache may be primed, and that you can affect as well in various ways. Timeout and time to live (TTL) values for various single elements (images, javascript & CSS files…) may be changed as well.
    Beware some of those settings rely on a functioning host. Those using NGinx like me have somehow an easier life as said server admits less bad configuring than Apache (so hosting companies have to be more competent setting it up) and the single configuration file helps spotting overrides and differences across the website areas.
    Regardless of web server, a portion of fine tuning the website has to be spent into checking that the generated headers really contain the time outs and settings you entered in W3TC administration, you’ll be suprised by what you find!

    Hi dfumagalli,
    Thanks for your reply. In fact, I have done everything from cache priming to multiple configurations. What I see is that, once I access the page, the TTFB comes down drastically for the next few minutes. If I access the site after a long time, it is slow again. I used a reasonably powerful VPS server. I guess, I need to dig into the header details as you suggested.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Don't upgrade to v. 0.9.3 for now’ is closed to new replies.