What is the name of the domain?
www.prosofteng.com
Please help me understand why Cloudflare CDN is slower for real users than a standalone server and how to fix it (of course if possible).
After migrating from a custom solution to Cloufllare Pages I noticed that for one website ranking noticeable decreased and Google Console started to show “LCP issue: longer that 4s (desktop)”.
Experiment: I installed nginx to $5 Nanode and uploaded exactly the same files as to Cloudflare Pages (it’s a static website and all files are only htmls and jpgs).
Then I only changed DNS between this Nanode and Cloudflare Pages, and collected daily data with a script (“curl --request POST … chromeuxreport.googleapis.com”).
At least 6 months for each test to make sure that the readings have stabilized.
Curious that synthetic benchmarks on pagespeed.web.dev and speedvitals/ttfb-test always show a little better results for Cloudflare Pages, but CRuX data is much worse. To compare results with one year between tests:
AVG for test 2023-05-18:
- LCP: 2.1, TTFB: 1.5; FCP: 2.2 - Nanode
- LCP: 6.1, TTFB: 3.6; FCP: 7.9 - Cloudflare Pages
AVG for test 2024-06-13:
- LCP: 3.1, TTFB: 2.2; FCP: 3.4 - Nanode
- LCP: 6.4, TTFB: 3.6; FCP: 7.0 - Cloudflare Pages
Even TTFB differs, which does not depend on webpages, and, just for reference, “Performance” on pagespeed.web.dev is “Green 100”:
- First Contentful Paint: 0.2 s
- Largest Contentful Paint: 0.2 s
- Total Blocking Time: 0 ms
- Cumulative Layout Shift: 0
- Speed Index: 0.2 s
so IMHO it does not make sense to optimize webpages (as advised in chat).
Another curious observation such a huge CrUX difference is only for the root webpage. For example, webpage “/downloads” in pagespeed.web.dev looks fine:
- LCP 0.6, TTFB: 0.3, FCP: 0.4
Note about Google Analytics (which is currently disabled for the purity of the experiment): it was enabled in all previous experiments but
- It showed much less visits that nginx logs (most probably because of modern Ads/Trackers Blockers, percentage depends on the website audience).
- Average values from Web Vital Analytics never matched CrUX (most probably because CRuX is collected only for users who enabled statistic reporting, sync their browser history, use supported platform etc. Nevertheless it’s important parameter since it’s used by Google Search to inform the page experience ranking factor). Though Analytics detected really slow connections from some countries, the average is still much better than CrUX for Cloudflare Pages.
In short, how to analyze Google Analytics data now (with blockers) is one more question, not the answer.
In the last Cloudflare Pages experiment I also added custom “Caching Rules” in “Proxied” mode for all files, just to mimic Nanode nginx configuration:
- HTMLs:
- Browser TTL > Override origin and use this TTL > 1 hour
- Cache key > Ignore query string
- Respect strong ETags > Use strong ETag headers
- Resources (http.request.uri.path.extension in { “css” “ico” “jpg” “js” “png” “svg” })
- Browser TTL > Override origin and use this TTL > 1 year
- Cache key > Ignore query string
- Respect strong ETags > Use strong ETag headers
and seems performance did not change (see the numbers above), though “curl --head …” now shows correct “cache-control” and strong “etag”. Anyway this would not explain the difference in TTFB.
Please share if anyone has already seen the similar symptoms or knows what else I could try to track down what exactly is causing such a serious CrUX difference between CDN and standalone server. Of course it is possible that for this particular website with it’s audience, Linode network is objectively better than Cloudflare CDN, and it’s time to migrate again, I’m just wondering why.
Thanks in advance,
Michael
