Bypassing Cache or Development Mode = Slow Down Site

Hi,

If I select to bypass the cache for my entire site (for prolonged testing over 2 weeks), OR use Development Mode, does this make a website slower than if CloudFlare was not configured at all?

For example, are there any tasks during the page load process that require “extra work” (load) to take place with CloudFlare with this type of setup?

Thanks.

Depends on how fast your site itself is (it should be reasonably fast even without Cloudflare) and how much you cache. But generally it is safe to assume that performance might become slower as the whole caching layer is out of the equation and requests will always go to your server.

1 Like

Hi @sandro - I guess what I’m trying to say is, my site is OK without Cloudlare, but I like to use it for the 301 redirect (Forwarding URL) page rules.

I don’t need the caching as it creates some conflict with my WebP code.

So, I’m thinking to bypass the Cloudflare cache for all of my site through a simple page rule, but I am concerned that I am adding extra load to my site’s speed, simply by having the bypass cache rule as another layer. I.e. without Cloudflare altogether, it might be faster/better than the setup I am proposing with Cloudflare.

Hope that’s a little clearer (my fault).

Thanks.

Using Cloudflare just for redirects is a bit of an overkill, as you can usually easily configure that server side too.

As for your question, no skipping the cache altogether won’t make the site slower in that case. All it means is that requests will always be served by your server and never by the cache. What could make it a tad slower is the fact that you are adding an additional layer to your site (Cloudflare) but unless you cache everything you’ll always have that anyhow in a proxied context and that should not necessarily make your site slower. Unless of course your visitors get routed via some odd path, in which case it could be a bit slower but that’s not the default.

But again, if you only need redirects, it’s better to do that server side and not use Cloudflare.

1 Like

Thanks @sandro - makes sense… Yes I was hoping to configure the redirects on my NGINX server but my host has a limitation with the type of redirect I need… Hence, Cloudflare offers an easy (but overkill) solution.

What kind of limitations? Keep in mind Cloudflare only offers three page rules as well for free.

Plus, you’d need one to disable caching for /*, so you’d be left with two redirects.

My advice, really look into doing this server-side and, only if that really is not an option, look into Cloudflare. But then it also depends on how many redirects you want to have for aforementioned reason.

1 Like

1 redirect for /* is all I need :grin:

But, I am still figuring out if the caching by Cloudflare is useable. The issue I have currently is with a WordPress site and plugin that offers PNG/JPEG to WebP conversion. However, Cloudflare is sometimes serving WebP files (after they’ve been cached), to unsupported browsers (i.e. an older version of Safari in my own case).

It should be falling back to JPEG and PNG for unsupported browsers, but the Cloudflare caching I’m told is causing the problem…

I’m not convinced, but what do I know.

But in that case everything would get redirected and the cache would never be hit anyhow. In that case Cloudflare would work just fine for you.

Can you provide a few examples?

Cloudflare offers a paid option for that → Polish

1 Like

Sure, the page rule I have is this:

example.com/*
Forwarding URL (Status Code: 301 - Permanent Redirect, Url: https://www.example.com/$1)

The only reason for this redirect is to go from all non-WWW and non-HTTPS, directly to WWW-HTTPS. E.g. example.com > https://www.example.com. or example.com/page1 to https://www.example.com/page1/.

I know it’s weird, but my web host can’t configure this on NGINX, and they prefer to leave as this:
example.com > https://example.com > https://www.example.com. It’s minimal latency for the redirect, but I just don’t like it :slight_smile:

In any case, the cache is being hit without issues (I think), because in all the relevant Headers, I am seeing CF-Cache-Status: HIT. Attached a screenshot for reference:

So, Cloudflare helps me fix this very easily with that page rule, for ALL pages with the one redirect.

Regarding the paid option of Polish: thanks, I will look into that… It does make me question though why anyone would then even consider using Cloudflare (free version) with a setup I’ve described in that WebP images are being served where possible.

Since I am literally just starting out, would you suggest that it’s best to DISABLE WebP files entirely > keep Cloudflare on for ‘free’ caching > see how we go until I’ve scaled a little? I’m running a Stock photo website so not images overload anyway! :slight_smile:

But that’s a whole different issue as you are still redirecting within your domain.

So what you essentially want is all requests on “www”?

If so you could use two rules

  1. example.com/* forwarding to https://www.example.com/$1
  2. www.example.com/* disabling the cache altogether

That setup should work just fine for you.

2 Likes

Yes, all requests on www (w/ HTTPS of course).

Yes #2 to disable the cache would be nice, but the dilemma I face is:

  • disable WebP files altogether on my server, because Cloudflare (free) is getting confused with which files to serve (e.g. WebP to unsupported browsers, if already cached from a supported browser request. OR PNG files to WebP-supported browsers, if PNG files are already cached from unsupported browser request).
  • disable Cloudflare caching altogether and rely on CF-Cache-Status: DYNAMIC, while being able to reliably serve WebP, PNG, and JPEG files where needed.

May I ask (as you clearly know a lot more than me here :slight_smile: ), what approach would you go with here, simply to get started for next 2-3 months!

Thanks.

Performance-wise it is most likely better to forgo WebP and keep the proxy caching. WebP can sometimes generate smaller files than the traditional formats, but that’s not a given. Make sure your files are somewhat optimised in the first place (in their native formats) and you should be good to go.

1 Like

I can’t thank you enough for your help here… :+1:

Thank you.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.