Viewing 15 replies - 1 through 15 (of 36 total)
  • Hi stellamaris5,

    Try disabling database and object caching.

    Best,
    AJ

    Thread Starter stellamaris5

    (@stellamaris5)

    Ok Will try. Is this just a guess or from experience?

    Thread Starter stellamaris5

    (@stellamaris5)

    Done those now. It ‘seems’ to have improved. Anything else you recommend?
    I am on shared hosting and the site is natureheals.co.uk

    Without getting into your site and set up all I (or anyone) can do is give best guesses — there a simply too many variables and too many ways for ‘wires’ to get crossed when using both CloudFlare and W3TC. Your site and setup are unique: When someone finds on online W3TC how-to that ‘works’ for them it is usually out of luck more than anything else (learn more). All that said, I am indeed the dood you want to be guessing at the issue:

    1.) Set up a Page Rule in CloudFlare to exclude Rocket Loader from WP Admin and to bypass CloudFlare’s cache for WP Admin;
    2.) Set up a ‘cache everything’ directive in Page Rules (CloudFlare) for the whole site (https://natureheals.co.uk/*) making sure to select “respect all existing headers”
    2.) Make sure you do not have minify enabled in both W3TC and CloudFlare;

    As seen here, the site’s biggest problem is Time to First Byte: a standard problem with shared hosting. Do 1, 2 and 3 above, re-run the above linked test a few times, evaluate the results, and again see how WP Admin feels. Let’s see if that betters things and go from there.

    Good luck,
    AJ

    Thread Starter stellamaris5

    (@stellamaris5)

    I have improved it by following your recommendations in the previous post seems ok now I am happy with that.

    Point 1 and 2 can’t do as I am onfree cloudflare and have already used my 1 rule for the flexible SSL Rule.

    Point 3 is already sorted only using minify in W3TC

    Thread Starter stellamaris5

    (@stellamaris5)

    Correction :

    I had three rules set up – in this order:

    1) force ssl ( for flexible ssl)
    2) exclude WP-admin from caching
    3) exclude WP-login from caching

    Deleted rule 3 and substituted with your point 2

    So the order is :
    1) force ssl
    2) exclude WP admin
    3)cache everything

    Thread Starter stellamaris5

    (@stellamaris5)

    Interesting. Now I can’t get into my admin panel although the the site is up.

    I have previously changed my admin login url with ithemes security to let’s say xxxx so when I go to natureheals.co.uk/xxxx I get to the log on page enter my creds but then get directed to a page saying not found

    You will indeed have to exclude WP Login from CloudFlare’s cache (or use Simplified caching). So, if you have only 3 page rules you have a few choices:
    1.) Upgrade to CloudFlare Pro which will give you 20 Page Rules;
    2.) Forgo the SSL, Re-exclude the login page and keep the Cache Everything directive.
    3.) Keep everything as it was (bad choice).

    I re-ran the test I previously linked and it looks like you disabled the Cache Everything directive as it was running. This test run, however, captures precisely why you should make use of the Cache Everything directive (note key metrics such as TTFB, First Paint, Time to Start Render and the Speed Index).

    If you’re happy with things without the Cache Everything directive then it is what it is. But I promise: the metrics indicated here will give the site a sky-high bounce rate since the user experience will be poor (insofar as speed and UX are synonymous with one another).

    Best,
    AJ

    Thread Starter stellamaris5

    (@stellamaris5)

    cheers for the comprehensive explanation.

    Would combining wp-admin and wp-login in one rule work, like:

    *natureheals.co.uk/wp-*/*

    Probably not, that’s not how dynamic URL patterning works.

    In many respects CloudFlare is on their own ride, however, so go ahead and try it. Easily enough deleted if things get funky.

    AJ

    A couple of things I forgot to mention…

    I.) I know Rocket Loader seems like an easy, push-button solution to asyncing JavaScript, but you really ought to be handling that inside of W3TC. The main reasons being:

    A.) Rocket Loader is in perpetual beta which means your site is a perpetual guinea pig: Your site may be humming along just fine and one day stop functioning correctly even though you haven’t made a single change. For most site’s making use of Rocket Loader, this will be because CloudFlare has pushed out an update that disagrees with your site/setup.

    B.) CloudFlare ‘sells’ Rocket Loader as something that functions on a multitude of browsers. It doesn’t. It (as of typing this) ‘works’ in Chrome and Firefox. Standard attributes (e.g. async), however, do in fact function on a multitude of browsers. W3TC enables one to use standard attributes.

    C.) For the browsers on which Rocket Loader does function, the browser’s capacity to cache your site’s .JS is removed and must therefore process Rocket Loader’s combined .JS file every time a user navigates from one Rocket Loader enabled page to the next Rocket Loader enabled page. This diminishes speed and therefore user experience.

    D.) Even though Rocket Loader does affect Chrome, Google bot does not recognize CloudFlare’s script type="text/rocketscript" data-rocketsrc. Which means you will receive no SEO benefit by asyncing your site’s .JS with Rocket Loader.

    II.) All minification/concatenation should take place within W3TC as opposed to on CloudFlare’s end. The optimization of one’s origin is always the faster, ultimately more problem-free scenario.

    Best,
    AJ

    Thread Starter stellamaris5

    (@stellamaris5)

    Wow, a lot of info there to process.

    How does it look now? (dropped the https)

    Thread Starter stellamaris5

    (@stellamaris5)

    I’ve got these 3 rules now and can’t get back into my site.

    *natureheals.co.uk/wp-admin/* Apps: Off, Performance: Off, Security: Off, Always online: Off, SSL: Off, Smart Errors: Off, Cache level: Bypass cache

    *natureheals.co.uk/wp-login/* Apps: Off, Performance: Off, Security: Off, Always online: Off, SSL: Off, Cache level: Bypass cache

    *natureheals.co.uk/* Cache expiration: 4 hours, Cache level: Cache everything

    In Cloudflare: I’ve disabled Flexible SSL and deleted the force SSL rule, and turned Rocket Loader off

    On my site I have disabled the Cloudflare SSL plugin and have set my site URL to http in Settings –> General so everything should deb back to normal

    but

    I get to the logon page natureheals.co.uk/xxx fine and enter my login creds but get to a page not found page again

    hmm

    Make sure your login URL is not being cached in W3TC. If you have to, set a specific directive for this under Page Cache in W3TC.

    Then:
    1.) Enter Development Mode in CloudFlare;
    2.) Clear all caches in W3TC;
    3.) With a cleared browser cache (or in private mode), click around your site to revalidate the W3TC cache;
    4.) Disable Development Mode in CloudFlare;
    5.) With a cleared browser cache (or in private mode), click around your site again;
    6.) Try logging in.

    You can also try purging your login URL as a single file purge in CloudFlare in case it somehow ended up in CloudFlare’s cache in the shuffle (CloudFlare Settings –> Settings Overview –> Purge Single File).
    ____________

    Some of your images are still being served over HTTPS which is blocking rendering, so you’ll want to get that remedied (which the above process might do for you).

    You’re on your way, though. Implementing minification, combining your files, and deferring/asyncing .JS in W3TC will further improve things.

    AJ

    Thread Starter stellamaris5

    (@stellamaris5)

    1) Done
    2) I can’t log in to do this ??

Viewing 15 replies - 1 through 15 (of 36 total)
  • The topic ‘Not working as people say’ is closed to new replies.