Increased page load times after Cloudflare implementation

[user8931]

Hi all. We are having some issues with server response time and how it’s increased after Cloudflare implementation. If someone could help us with tips and previous experience would be awesome.

We have a WordPress (WooCommerce). We are working on our Staging shop, that is a subdomain of our live domain (https://staging.domain.cl). Yesterday, we setup Cloudflare as our website CDN. More than anything, to use Cloudflare as first security layer against DDoS and general threats. Before Cloudflare, the server returned content directly from an Nginx preload implementation. Also, there is a Redis cache and assets were served with AWS CloudFront (consuming from an S3 Bucket).

With the first tech stack, the site had TTFB of ~200ms-300ms. We really though that Cloudflare could be a boost on our response times, but after the implementation (we deactivated CloudFront so assets are being served by Cloudflare now), we are having solid 700ms-800ms every time. We are using Full Encryption Mode on Cloudflare (this is our first theory for the delay) but actually we are kind of lost in configs. We already activated some options in Cloudflare (HSTS Preload, Preload, TLS 1.3, Brotli and more) but we cannot figure out if this is a normal behavior or something caused by Cloudflare/Config/Server/etc.

In Cloudflare, we have Page Rules already setup to Cache Everything:

and actually the site is responding with Cloudflare Cache hits on all resources, so we don’t think is caused by a slow fetch of resources.

We made some tests in Web Page Test as well.
(I created an imgur album due to new users links limit restriction, with the pictures and their references for the following part: Album Here)

The first one, is directly to current site (Cloudflare):

• Image Reference: Test #1 - Summary
• Image Reference: Test #1 - TTFB Detail

The second one has a custom script to test directly to AWS Lightsail machine (consider that it’s working without any assets CDN cause Cloudflare is resolving this now for the platform):

• Image Reference: Test #2 - Summary
• Image Reference: Test #2 - TTFB Detail

As you can see, First Byte directly to the server is slower, but TTFB is faster (just 50ms, almost imperceptible).

The problem starts now: we are having ~800ms TTFB constantly from our Browser (I say we cause we are doing tests from to different cities in Santiago, South America, and the behavior is the same):

• Image Reference: Chrome Inspector TTFB 1
• Image Reference: Chrome Inspector TTFB 2
• Image Reference: Chrome Inspector TTFB 3

These are three requests, one after another. The range is 700-900ms.
Based on what we are seeing, is possible to think about some routing issues. As I said before, we are testing from Chile, mostly Santiago. Here is my CDN CGI Trace (*** values are hidden by me):

fl=193f19
h=staging.domain.cl
ip=***
ts=1589385173.234
visit_scheme=https
uag=***
colo=SCL
http=http/2
loc=CL
tls=TLSv1.3
sni=plaintext
warp=off

The request is resolving to SCL (Santiago, Chile), but we are having different page load times than Web Page Test, and is not only from here (we test from another city in Chile and the result is the same). We have to say that this impact is not only present in Staging. Also in live shop TTFB and init page load times are increased.

Please if someone could give us a hand would be incredible. We are lost in our path to resolve this. We only want to know about the reason of the difference and a possible solution.

Thank you in advance.

[M4rt1n]

@user8931

What are you actually doing with this 3 rules?
For my understanding you just need one single rule to achive the same.
Rule number 3 is perfectly fine for all your needs.

Also: Rule number 2 is a sub-sub domain which is not covered by any SSL Cert Cloudflare offers.
I have the same issue. Read here: Slow Website if routed through CF

But to come to your website. The html is actually not cached, also your PageRules are not like you posted above.

I see:

So your rule is deactivated or not working.

[DecryptoBL]

I think cf-cache-status is probably BYPASS because cache-control is instructing CF not to cache with the no-cache header. Is your cache setting in CF set to “respect origin headers”?

[user8931]

Yes, I assigned Edge Cache TTL to every Page Rule and I think that did the trick for me (server had already set Cache Control headers and Cloudflare has Respect Origin Headers behavior). Now we are having HITs on Cloudflare cache but we are facing another issue: session.
In Home Page, when a user logs in, the session is not present (I supposed its because of Cache Everything Page Rule). If I go to another page, I think the Browser stores cache and doesn’t show session as well until I hard refresh the page. The Home Page stays without session even if I hard refresh the Browser.

Is there any way of having this static page behavior only without a current session?

Thanks!

[M4rt1n]

@user8931

Now we are having HITs on Cloudflare cache

I dont see HIT at html documents.

@user8931

Is there any way of having this static page behavior only without a current session?

I think on enterprise plan it is possible.

But you could just solve it like this:
Bypass on all pages (with pattern) which are dynamic.

Or: optimize your site natively which is the very best way to optimize anyway!
Or: implement Varnish and configurate it well.

[user8931]

Thanks for your answer Martin, actually we disabled Cache Everything Cache Level cause of session issue, but we were having HITs on HTML before

I think we have all pages dynamic, cause there is a Sidecart panel and menu/header content that depends on user login status. I’m not sure if we can have a pattern for that.

About your last two suggestions: actually, we are having around 300ms TTFB directly from the server (with a Nginx Preload + Redis implementation). But Cloudflare is getting ~800ms. We are ok if Cloudflare adds 100-200ms, but I think 500ms is too much. I’m not sure how to improve that from Cloudflare’s end, so we can have Standard Cache Level (not Cache Everything) and operates normally.

Thanks again!