Bug Fixed: 6+ second TTFB on certain assets and paths

While we can’t see anything outside of the request - such as if the connection creation was retransmitted 5 times, or the response was, which would make it much slower from the client PoV. All I can see is that as soon as the connection was established, we sent the answer.

Hiya @hk-abhijith - that request was answered in 351 milliseconds by our service, so I can’t tell what might have caused the issue you’re talking about (but I also don’t know what a “pagespeed score” is so maybe 351 ms gets you a “30” - but that’s normal behavior for our service so not actionable as it is).

This community thread, though, is about requests that take six seconds, so is not related o that one. Since you’re on a paid plan, feel free to ping our helpdesk directly if you’d rather not talk about it in community, but if you do want to talk in community, I’d appreciate a lot more details such as “what is a pagespeed score and what does it measure” :slight_smile:

This appears to potentially affect our website as well:

Update: we’ve moved away from Netlify due to slow load times. Our site is now live on an S3 bucket and is blazingly fast.

Hi, @jmikrut, I’m not seeing this behavior in the logs for this site.

I do see large files (around 9.3 MiB) taking longer than six seconds to download, but that isn’t the same as the 6+ seconds time to first byte issue. Large files rarely stay in a CDN node’s cache and therefore do send at about 1 MiB/second with our service.

Are you seeing a slow time to first byte (TTFB) issue? If so, would you please send us a HAR file capture of this or the x-nf-request-id response header for a slow to respond request?

There more information about this header here:

If that header isn’t available for any reason, please send the information it replaces (or as many of these details as possible). Those details are:

  • the complete URL requested
  • the IP address for the system making the request
  • the IP address for the CDN node that responded
  • the day of the request
  • the time of the request
  • the timezone the time is in

With this information we’ll be able to research any high TTFB issues.

Hi Luke,

It’s not a six second delay but I was just able to pull this x-nf-request-id header from a 155 B file. It took 2.85 seconds to load.

30f04745-8cb8-40df-9b2c-af552cc0acef-8715143

The weird thing is that generally the first load is fast, and it’s attempting to load a second or third page that takes forever. Note that because Gatsby prefetches resoures, you need to load the homepage and then quickly try to navigate to a secondary page like About or Development to notice the loading delay.

Anyway I guess this might not be the 6 second TTFB issue above but my site’s load speed is still being crippled and thought you guys should know about it. The problem does not persist when since the site is now hosted on an S3 bucket. I will leave the suspicious-goldwasser Netlify bucket up in the interim.

Hi,

Any update on this? I am still getting excruciatingly slow loading times, first reported here.

We’re experiencing slow loading times on assets on the paid tier:

x-nf-request-id: 55bee952-3e03-4b58-8c4d-eb122ef914aa-34168

It’s starting to become a show stopper for us, hopefully we can find a resolution :pray:

I’m also experiencing extremely slow load times - more than 14 sec TTFB for my single page static site! Any chance this is related? Any ideas how to resolve?
x-nf-request-id:
f054cd8c-f542-44f0-8618-6f8067f186e4-13258060
URL: https://thirdhandcollaborative.com

Hey @ianbrennanskew, we do see that it took 5-6 seconds for us to get this back to the browser. The culprit seems to be a 1.3 MB video file, for a total response size of 6-7 MB so that timing makes sense. As @luke explains above:

Large files rarely stay in a CDN node’s cache and therefore do send at about 1 MiB/second with our service.

If you were sending six smaller files, they would transfer quickly in parallel but that’s not the case with the one large file.

Hey @noelco, we took a look at this as well. Your request was done sending from us in 5 milliseconds and your DNS setup looks good, so we don’t have a good explanation for the load times you experienced. Assuming you had good network connectivity, the next thing we’d want to look at is your network timing. In Google Chrome’s devtools, you can check this out by clicking the Network tab, clicking into a request, and then looking at the Timing tab. If nothing stands out to you there, go ahead and send us a HAR file so we can dig in further:
https://toolbox.googleapps.com/apps/har_analyzer/

This bug is fixed, so if you have a new performance problem, please post in a new topic, and include:

…so that folks are most easily able to help you debug.