Slowness with TTFB with custom domains

Support
, ,
#1

Hello,
I’ve migrated my blog to Netlify with a custom domain and I’ve found some weird behaviors.

I’ve a really slow time to first byte when using cURL with the custom domain. It’s working well with the domain *.netlify.com. I’ve hardcoded the IP (with the /etc/hosts file) to use the same server for both requests (167.99.137.12).

With the Netlify domain (aerialls.netlify.com with request ID b44bd1e7-9aa5-4653-8bda-a34ddf2d06fc-3994746)

      time_connect:  0.016061
   time_appconnect:  0.036165
  time_pretransfer:  0.036583
     time_redirect:  0.000000
time_starttransfer:  0.047494
                     --------
        time_total:  0.047690

All good. But with my custom domain (www.aerialls.io with request ID b44bd1e7-9aa5-4653-8bda-a34ddf2d06fc-4043648)

      time_connect:  0.017006
   time_appconnect:  0.041514
  time_pretransfer:  0.043533
     time_redirect:  0.000000
time_starttransfer:  6.255878
                     --------
        time_total:  6.256035

If I’m accepting GZIP encoding (Accept-Encoding: deflate, gzip), the TTFB is much better with both domains but I still can see a x5 factor between the two times (0.310832 for my domain vs 0.055943 for netlify).

The server is the same for both requests. I can’t explain why the TTFB is so much higher in this situation. I’m doing a simple cURL request without any extra parameter.

Thanks!

2 Likes
Consistent 6+ second TTFB on small index.html file
#3

Heya @aerialls and welcome to our community! Sorry our welcome mat was not out and we took so long to respond!

The 6 second TTFB for uncompressed requests is something that is not unique to your site and our platform team is working on a fix for it right now after a long string of debugging to figure out what you figured out - it’s (some) uncompressed requests. Fortunately, no real browsers connect without compression - just monitors and curl, so I don’t think your organic/human traffic is suffering.

The 301ms ttfb though is something we consider normal (better performance is likely, if your content is in cache already; the cache however is contested by tens of millions of sites, and is per-cdn-node, so it is quite frequently the case that sites not under constant traffic from all locations are not always in cache).

But - if you’re seeing over a second TTFB reliably, we’ll be happy to take a bit closer look, since that is not normal.

#4

We are seeing this problem occur as well, and it’s particularly bad for proxied requests.

See x-nf-request-id: 278df88c-a357-43d6-84e1-47738993e46c-9429347 for an example slow request. Occasionally the slow URL above is fast, but ~90% of the time it is ~7s.

1 Like
#5

Yup, this is the open bug we have around slow TTFB for some requests. I understand that your tests show it pretty often, but in the grand scheme of things for your site, the average response time is 264.03 ms over the 793,667 requests that were neither 404 nor “client hangups” to all sites within your account in the past week, so I think the typical performance is still pretty good.

During that same time, there were 661 requests that were as far as I can tell affected by the bug.

We’ll update here once we have a fix for that bug in place.

#6

Thanks. In case it helps, the only (as best we can tell) slow URLs are https://about.sourcegraph.com/search?q=sql (and other queries). Pages without a query string seem reliably fast. Note that even some queries seem reliably fast (<1s), such as https://about.sourcegraph.com/search?q=foo.

#7

thanks for sharing that additional info, @sqs. Appreciate it. We’ll update here once we have more information. :+1:

#8

Hi everyone, we have some great news :tada:

We have tested & rolled out a fix for these issues.

More information here:

Please feel free to discuss on that thread, I will close this one (and others) so to contain the conversation a bit more. Thank you all for your patience :pray:

#9