CF_HIT : server wait

Hi!
It’s a follow-up from CF slowness for CF-Status: HIT

We removed every notion of lazy loading around our images, but we still meet those weird Waiting (TTFB) that can go as far as 9s (!) for a cf-cache-status: HIT
I’d really like to understand how to avoid this wait to offer a better experience for our users.
Any advice is welcome :slight_smile:

Better with an example: https://cults3d.com/en/3d-model/tool/well-engineered-hemera-fan-duct
Filter the host on studio.cults3d.com : you’ll see that most of the images have a very long TTFB.

Of course the one specific resource you call out returned a 500 for me.

Though after a bunch of reloads to get everything cached, every image from ‘studio’ with a cacheable file extension is served in about 100ms or less, including that PCF one.

Thank you sdayman.
I’m really surprised. To be sure we talk about the same ressource, that’s that link:

https://studio.cults3d.com/aWX5j0fiB6t-_3iudXaSx32E-zI=/516x516/filters:format(webp)/https://files.cults3d.com/uploaders/13391317/illustration-file/6c7a90a9-571f-49c1-b397-6b8227318778/PCF-real-water-lines.jpeg (maybe you’ll recognize an image altered by a Thumbor service).

It’s a jpeg transformed into a webp. The headers I see are:


I read it like that:

  • the image is correctly fetched from CF cache (at CDG center at least, and I confirm I don’t see that request on my server)
  • the image is in the cache for 2 days
  • the image will stay valid in cache for 1year (minus 2 days)

Maybe I don’t understand correctly how a CDN should work. For me the “first client” will trigger a MISS at CF level, that’ll issue a request against the original server, CF will cache the result, and then return the result to the client. At this moment, all clients will get HIT at CF level for the cache TTL (1yr here).
Am I wrong?

I don’t understand the reason of the >1s TTFB wait when CF has the resource in cache: can you help me to understand it (and reduce it?)

Thank you.

That’s the one. I’m pretty sure there was only one PCF filename in there.

Not likely a year in the edge cache. Cloudflare doesn’t leave a file in the cache for very long if it isn’t used enough. And Edge Cache maxes out at about a month in those rare cases.

And maybe a second and third as well. There are many servers at CDG and they don’t all share the same cache, but if you have Argo Tiered Caching enabled, that might help.

I’d attribute it to network congestion. I rarely see such behavior at my end.

Quick check of your URL you provided via WPT cults3d.com : Chrome...rginia USA - EC2 - WebPageTest Details

  1. Huge 14-20MB page size. Cloudflare can only operate in a reality that networks can’t transfer data faster than the speed of light. So CF CDN caching still has limits as to how fast it can serve content. Larger asset and page size, means slower transfer times. The ideal total page size would be <400-1200KB.

Document took 96+ seconds to load and page 120+ seconds to fully load on 5Mbps cable connection with a lot of javascript resulting in >8+ seconds of total main thread browser blocking time. And with 1,967 total HTTP requests for the page! That’s close to a record for the number of requests a web page had to load! Probably 20x times higher than optimal!

  1. Thumbor backend system isn’t working properly - I see a lot of 502 errors in WPT suggestion Thumbor system was unavailable or not working properly.

502 error timed out response took 8.7+ TTFB

Other evidence is Thumbor served images have a cache miss for CF cache but you have another intermediate proxy showing a Hit. If that intermediate proxy is on your origin or behind Cloudflare, then Cloudflare still needs to connect and communicate with that intermediate proxy and it shows the TTFB very slow for that intermediate proxy to return a response.

Here it’s 5.6+ seconds TTFB

  1. Cloudflare by default doesn’t cache dynamic HTML pages only certain assets unless you tell it specifically to do so https://blog.cloudflare.com/caching-anonymous-page-views/. So it shows that your server response time (TTFB) is much slower than optimal non-cached HTML page’s TTFB at 1.5 seconds. I’ve see your page vary from 1.5-8+s TTFB so your backend server stack (Phusion Pasenger) isn’t optimally configured.

Here your index HTML page TTFB = 1.34s

3x run WPT results plotted show variance up to 8.2+ seconds TTFB

To fully optimise a site for performance and speed, you need to optimize 3 segments.

  • segment 1 - connection between visitor and CF edge server i.e. CDN cache, WAF, Firewall, Page Rules, Mirage, Polish webP, HTTP/2, HTTP/3, CF APO, CF Workers (i.e. custom/advanced caching), 103 Early Priority Hints, Automatic Signed Exchanges (SXGs) etc

  • segment 2 - connection between CF edge server and your origin i.e. Argo smart routing, Railgun, Tiered Caching & Full SSL/ECDSA SSL certificates, origin server with TLSv1.3 support

  • segment 3 - your origin server’s performance/optimisations i.e. web server, PHP, MySQL server optimisations and server hardware specs. In your case Phusion Passenger configuration.

Cloudflare can only help for segments 1 & 2 for cached guest/non-logged based visitors. Now for Cloudflare CDN cache miss/bypass and logged in user for web apps like forums/wordpress or CF CDN default no cache for dynamic HTML, performance is determined by segment 3.

1 Like

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