Instant for static, slow (>4.5s) for dynamic

Hello fellow tech enthusiasts,

I have been experiencing erratic behaviour with response times of a basic website that serves a mixed range of resources. What is happening is that static resources, such as images. CSS and javascripts load almost instantaneously, but anything that triggers a server side script (PHP) takes a minimum of 4.5 seconds before the end client browser receives anything, even if the returned payload is just the origin server’s current time in plain text; but, the alarming part here is that accessing my server directly, non-proxied, via IP address gives instantaneous responses in all cases.

Are there any particular settings I should be aware of that could cause these mind-blowing delays?

Please temporary disable Cloudflare (by setting it into the developer mode) or send a request directly to your servers IP, that will bypass Cloudflare.

If your site then still is so slow, then that means that your server is the cause for the 4.5s TTFB. If it suddenly gets faster that could be an indicator for Cloudflare slowing down things.

Please do so and report back.

Here is the results, I did purge the CF cache just to be doubly sure:

Through CF (developer mode): no difference (>4.5s)
Directly via IP (x.x.x.x): near-instant (~8-30ms)

Are you able to share some test URLs so we can analyse this on our side?


Through CF:

This should return a (UTC) timestamp in “text/plain” as to when my end receives the request. The URLS are scripted to put “Cache-Control: no-store” in the response headers, which disables CF’s cache.

Yes I indeed can reproduce the issue. Since I can’t (and shouldn’t) look into your account or server etc. I would recommend you to open a ticket and post the ticketnumber here so we can escalate it internally.

Unfortunately, I’m on the free tier, so I am unable to file one.

If you wish to submit a ticket for 1:1 support from Cloudflare, you must upgrade your plan type.

Just write an Email to support[AT]cloudflare[DOT].com. Once you got a Ticket #ID post it here.

Oh ok, thank you M4rt1n! I will get on to that asap and return here once I have a ticket
ID. I’ll mention this thread so that I have proof that this problem can be replicated.

Got a response already, sadly…

Email support is not available for customers on your plan type… Upgrade now or you can still get great support for general questions and basic troubleshooting from our…

It further adds that I have to wait until 3 days have passed since I opened this thread and @-mention a certain name after that amount of time has elapsed.

Guess I’ll have to wait… Will continue trying every once in a while, hoping I might spot something.

The MVP’s can escalate a given ticket whenever they feel like it’s something beyond the scope of what we can help with on the community - which I’d expect will be sooner rather than later with something like this.

1 Like

Ok, I will keep my notifications on if any further input is needed on my part.

Just a pointer that currently my website has been running part-time from my desktop for the time being, so if you get a 523, then it’s because my desktop is switched off or is in standby mode. I do have a dedicated machine built but as of yet to get it fully set up.

I have escalated your ticket internaly. Thanks for sharing your ticketnumber with us.

Yes, there indeed is something to do. To make debugging and testing for the engineers more easy please create the subdomain which accesses the site directly again, as it seems like you have deleted it.

Second thing is, the site should be up and running, so please keep your desktop running if possible, so the devs can debug and compare the two domains.

Sorry for deleting it without warning; it was because I was trying to keep my origin endpoint directly exposed for a short as possible.

I have recreated the subdomain entry.

Just copying the addresses for the dev’s convenience so they don’t have to dig it out:

Through CF:

Don’t worry I can understand that, it’s just harder to debug if it’s gone.
Your home IP anyway should change every day, so that should not be a too big problem. At least it’s how it is at me :slight_smile:

Just posting some test results that I shared with the support agent.

Through CF

Direct Connection (configured to ignore certificate errors due to CF’s origin certificate)

It is essentially the same results we got, but the direct connection was 0.5s, which isn’t unusual and within margin-of-error because of the distance the data had to travel.

1 Like

I found out the problem. My server was trying to identify connecting “clients” by performing reverse DNS lookups on-access. But because Cloudflare’s servers do not have DNS names assigned to them, it was confusing my server software.

The reason it looked delayed but the response timestamp was consistent, was because execution of the server script did not actually occur until these reverse DNS lookups completed.

I added this directive to my server’s config file:

HostnameLookups Off

Who knew that it was this one simple change could turn things right side up…