TTFB > 30s on Free Plan

I provide link via PM if necessary.

A production webpage, a SPA in React.

Randomly, when I refresh the page, I can get < 200ms or > 30s.

Anyone knows why this happens? Is that a normal behaviour on a Free plan?

Would you mind capturing a HAR file (see https://toolbox.googleapps.com/apps/har_analyzer/ for details about how to get one from Chrome) of those slow loads so we can dig in a bit more? It’s hard to be sure without seeing a HAR file of you experiencing it.

Hi Perry,

I attach two examples, the first test was slow, and the second fast.

Slow: Easyupload.io - Upload files for free and transfer big files easily.
Fast: Easyupload.io - Upload files for free and transfer big files easily.

Hope it helps.

Hi, @angel-luis, the HAR file does show slow responses and I see the same in our logs.

Our logs also show the CDN node used was near San Francisco while the HTTP request IP address was in Europe. We have CDN nodes in Europe and I would expect one of those to be used instead.

This is likely the reason for the slowness but I cannot explain why the wrong CDN node was used yet.

The decision about the CDN node happens at the DNS level. What happens when you make the following DNS lookup locally?

host -v www.microsalamanca.es

This is what I see when testing.

$ host -v www.microsalamanca.es
Trying "www.microsalamanca.es"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57882
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.microsalamanca.es.		IN	A

;; ANSWER SECTION:
www.microsalamanca.es.	1759	IN	CNAME	movistar-salamanca.netlify.com.
movistar-salamanca.netlify.com.	19 IN	A	167.172.215.127

Received 99 bytes from 8.8.8.8#53 in 34 ms
Trying "movistar-salamanca.netlify.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18281
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;movistar-salamanca.netlify.com.	IN	AAAA

;; ANSWER SECTION:
movistar-salamanca.netlify.com.	19 IN	AAAA	2604:a880:2:d0::1541:1001

Received 76 bytes from 8.8.8.8#53 in 36 ms
Trying "movistar-salamanca.netlify.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40013
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;movistar-salamanca.netlify.com.	IN	MX

;; AUTHORITY SECTION:
netlify.com.		259	IN	SOA	dns1.p04.nsone.net. hostmaster.nsone.net. 1586159315 43200 7200 1209600 300

Received 113 bytes from 8.8.8.8#53 in 23 ms

Would you please make the same lookup locally and share the output here? Also, were you using a VPN or specialized DNS configuration at the time the slow page loads occurred?

Hi, thanks for your reply,

The website is 100% spanish so I need always an European CDN.

C:\Users\mail>nslookup -debug www.microsalamanca.es

Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0

QUESTIONS:
    1.1.1.1.in-addr.arpa, type = PTR, class = IN
ANSWERS:
->  1.1.1.1.in-addr.arpa
    name = one.one.one.one
    ttl = 1130 (18 mins 50 secs)

Servidor: one.one.one.one
Address: 1.1.1.1


Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 2, authority records = 0, additional = 0

QUESTIONS:
    www.microsalamanca.es, type = A, class = IN
ANSWERS:
->  www.microsalamanca.es
    canonical name = movistar-salamanca.netlify.com
    ttl = 1692 (28 mins 12 secs)
->  movistar-salamanca.netlify.com
    internet address = 138.68.244.143
    ttl = 20 (20 secs)

Respuesta no autoritativa:

Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 2, authority records = 0, additional = 0

QUESTIONS:
    www.microsalamanca.es, type = AAAA, class = IN
ANSWERS:
->  www.microsalamanca.es
    canonical name = movistar-salamanca.netlify.com
    ttl = 1692 (28 mins 12 secs)
->  movistar-salamanca.netlify.com
    AAAA IPv6 address = 2604:a880:2:d1::1a9:8001
    ttl = 20 (20 secs)

Nombre: movistar-salamanca.netlify.com
Addresses: 2604:a880:2:d1::1a9:8001
138.68.244.143
Aliases: www.microsalamanca.es

No VPN in my computer. Cloudflare DNS (1.1.1.1). Tested also in another computer with another network.

Hi, @angel-luis.

To summarize, the DNS server 1.1.1.1 is directing you to an incorrect CDN node based on a query made from the western U.S.A.

This DNS server is making the DNS lookup from an IP address which is geographically closest to our CDN node near San Francisco, CA in the U.S.A.

For best performance the DNS query should be made from the location of the DNS query IP address, this is not what this DNS service is doing. If you check the IP address that was returned by 1.1.1.1 (which was 138.68.244.143) you can see the geographic location here:

You will get a location like so:

Santa Clara,
California,
United States,
North America

You can see how the geoip lookup should work here:

This will show the IP address returned for the CDN nodes are close to the location of where the request is being made from.

Instead, 1.1.1.1 is always returning an IP address in California. Again, this is happening because the DNS server is making this query from somewhere in the U.S.A. and returning a record from that location instead of submitting the lookup from your location and returning that record.

For example, this is a DNS server IP address in Barcelona: 217.13.116.5

If I query that IP address for the DNS lookup I get this:

$ dig www.microsalamanca.es  @217.13.116.5 +noall +answer

; <<>> DiG 9.10.6 <<>> www.microsalamanca.es @217.13.116.5 +noall +answer
;; global options: +cmd
www.microsalamanca.es.	1786	IN	CNAME	movistar-salamanca.netlify.com.
movistar-salamanca.netlify.com.	6 IN	A	167.99.137.12

The IP address returned this time (167.99.137.12) is in Frankfurt, Germany and would give much better performance than HTTP requests to Santa Clara in the U.S.A.

You can test this with nslookup on Windows like so:

nslookup -debug www.microsalamanca.es 217.13.116.5

You might also try Google’s public DNS as they are quite good about getting the geographically correct IP address:

nslookup -debug www.microsalamanca.es 8.8.8.8

There are two solutions:

  • use a different DNS server which doesn’t exhibit this behavior
  • the DNS server itself will need to start making the query from your location (or as close to it as possible)

Again, a more local DNS service or the 8.8.8.8/8.8.4.4 DNS servers will work correctly.

​Please let us know if there are other questions about this.

1 Like

Thank you very much for your explanation.

I’ve changed the DNS to Google, tested again, and well, it’s not the best TTFB (9,4s) + 12s for the main JS files from the Frankfurt DNS. But it’s better than 40s.