Whatever I do TTFB doesn't go down

[Ashutosh Khadka]

Hi Guys,
I am having a bit of problem here.
We changed from Porto to Hyva last year on November 2025.
And have tried everything to get the lab scores to 90+ but now the crux data I see has all messed up numbers. We have invested all our time and effort for 6 months on this but our TTBF is significantly high 1.8seconds which results to LCP and FCP being high.
As you can see in the screenshots, our lab data is perfect. Crux data is failing. I will be very thankful for anyone who ha suggestions and are willing to help.
https://pagespeed.web.dev/analysis/https-www-digitalcinema-com-au-denon-avc-x4800h-9-4-channel-8k-av-receiver-html/25rrrxaqt5?form_factor=desktop

https://cruxvis.withgoogle.com/#/?view=cwvsummary&url=https%3A%2F%2Fwww.digitalcinema.co[…]in&device=DESKTOP&periodStart=0&periodEnd=-1&display=p75s

Product page is
https://www.digitalcinema.com.au/denon-avc-x4800h-9-4-channel-8k-av-receiver.html

Things we have tried to minimalise TTFB:

1. Maintain server or application full page caching so product and category pages are served as prebuilt HTML.
2. Use CDN edge caching for static assets (CSS, JS, images) so global users receive files from the nearest server.
3. Optimise origin server response by ensuring database and PHP processes are not overloaded.
4. Ensure compression (Brotli or Gzip) is enabled for faster transfer of HTML and assets.
5. Reduce unnecessary backend requests triggered during page load (for example excessive dynamic section calls).
6. Maintain efficient object caching (Redis or equivalent) for Magento session and page elements.
7. PNG to WebP conversion of images.

I doubt we are still missing something. Can you help me debug this? We have tried everything that's on our reach.

Thanks

Ash

[Gilberto Cocchi]

Hi Ash, I am not an expert of Cloudflare CDN but it looks like you are not leveraging CDN Edge Cache hit on the HTML, that means that users are most likely always hitting the Origin Server that is quite slow (perhaps missing some caching layers on the Hyva side) and the CDN is hot helping making this better wihtout Caching the HTML at the edge.

See: https://developers.cloudflare.com/cache/how-to/cache-rules/

You also seems to be having some URLs with the query param "srsltid=" that is causing Origin Caching invalidation, that is definitively contributing to keep TTFB up.

In order to emulate these scenarios, try looking for "digitalcinema au" on Google Search, with DevTools Cache disabled and Network Fast 3G or 4G, it's really easy to get a TTFB from 1.5 to 4s on that site locally.

Hope this helps.

--
You received this message because you are subscribed to the Google Groups "Chrome UX Report (Discussions)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ux-repo...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ux-report/c491549a-cff0-4d46-a95a-032b93164528n%40chromium.org.

--

gTech Up

Gilberto Cocchi Web Ecosystem Consultant gilb...@google.com

Google Italy | Via Federico Confalonieri 4 | Porta Nuova Isola | Building C | Milan 20124

Registered in Milan, Italy

This email may be confidential and privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

The above terms reflect a potential business arrangement, are provided solely as a basis for further discussion, and are not intended to be and do not constitute a legally binding obligation. No legally binding obligations will be created, implied, or inferred until an agreement in final form is executed in writing by all parties involved.