TTFB & Download are slow and Site is not on CDN properly

Hi,

I have lambda resource that has TTFB more then 2sec. Would you please look up what makes it slow down?
x-nf-request-id: 299a45ec-98c9-4abf-8a2b-a2de24b724b3-156079
site: https://urbangeeks-admin.netlify.app/

In the case of the next js file, It has more then 1.6s download time. Is that normal?
x-nf-request-id: c1e551ba-b443-416b-8b4f-bbfcdb6767ce-76062
x-nf-request-id: 299a45ec-98c9-4abf-8a2b-a2de24b724b3-572726

Also, I’ve used some speed testing sites and one of them says that the resources are not served via CDN.

I checked the site IP address is located according to the test location. But wonder if that means that It’s serving on CDN.

hey there,

thanks for letting us know.

The person who knows most about TTFB woes is out on vacation this week, but i will make sure he sees this when he is back.

in the mean time, could you capture a HAR file for us so we can take a closer look?

https://toolbox.googleapps.com/apps/har_analyzer/

Hi and thank you for reply.

Sure! Here is HAR file. I’ve used webpagetest.org for testing and here is the result:
WebPageTest Test - WebPageTest Details

This is actually a little bit different issue(taking more then 10sec to load the whole page). Whenever I test from the Korea region, first 5~6 tests are all like that :frowning:

I assume that it is somehow relevant to CND propagation.

And here is HAR file after 5~6 tests are done.

The amount of JS is a big part of the long load times, nearly 800kb of JS will cause a lot of slowdown.

It might not seem like much when compared to loading a 5MB JPEG for instance, but JS is parsed quite differently and takes much longer to download.

Hi, @peter-wd-1. I do see the x-nf-request-id in the first slower HAR file (before the 5-6 tests) taking much longer to download the 800k javascript file.

This is a known issue with uncached content on the CDN. Large files are unlikely to remain in the cache long and uncached content is slower to send the first time. There is work being done to address this for CDN nodes far from the origin but that work is still in progress.

Regarding the TTFB for the faster response (after 5-6 tests are done), the connection appears fast to the CDN node itself. I do see the request coming from Korea and the CDN node is in Singapore so that might explain some of the delay.

If there are other questions about this, please let us know.