Support Forums

Resposne time / wait time is too big

I run my website https://www.matweb.cz/ (matweb.netlify.app) on Netlify and often I see quite big response times. Sometimes it takes about a half a second to load a single HTML file and according to the console it spends a lot of time in the „wait time” phase. If I request the page again the response time is usually smaller — like it was temporarily stored in a cache or something like that. But in a while I get slow responses again. I tried it on many pages such as Důkaz sporem — Matematika polopatě or Derivace funkce — Matematika polopatě with the same result. You can find HAR file of one of my tries here: https://www.matweb.cz/files/dukaz-sporem.har

Is this the common behaviour? Or is it a bug? It really bugs me because although I have a static website it’s slower than my forum which is written in PHP and uses a database.

Hi @lukashavrlant,

Wait time is TTFB and from the HAR file I could see that it was around 400 ms for you. In my experience that much TTFB is normal on Netlify. I am getting around 800 ms on one of my websites - and it’s safe to consider 500 ms as an average time.

Are you seeing even longer times that that?

Hi @hrishikesh, thank you for your response! No, I don’t see longer response times than 800 ms. It’s usually about 500 ms for the first request. But is it really OK? My main reason for using static generator and “static webhosting” was to make my website as fast as possible. Currently, my PHP-based forum that fetches data from MySQL database has lower response times than my static website which sounds really weird. I usually get a response in 200 ms when requesting the PHP forum.

Lots of variables at play, @lukashavrlant! If you can provide an x-nf-request-id for a load time which you’re unhappy with, we can dig in. However, there’s a few reasons why requests may take “a bit longer” which fall in to two categories.

  • Extraneous variables (not Netlify)

    • Page size
    • Distance from the CDN
    • Connection speed/stability
    • Device speed/stability
    • External DNS configuration/performance[1]
  • Variables within our platform

    • Whether content is cached[2]
    • Netlify DNS configuration/performance[1]
    • CDN health/performance[3]

RE: [1]
If you are using external DNS, ensure that you configure a subdomain (such as www ) to be the primary domain in our UI. You should use a CNAME record at your DNS provider for subdomain (such as www). If you use Netlify DNS, you will not need to perform this as we will always route traffic via our CDN using NETLIFY and NETLIFYv6 DNS records.

RE: [2]
In general, you may experience slow loads on our CDN, if a CDN node hasn’t cached the file before. In each region where we have a CDN presence, we have multiple nodes and they each have their own cache. If the node which responds to your request hasn’t cached the asset, the node must request the asset (uncompressed) from our west-coast US origin server. The asset is then sent uncompressed to the CDN node, compressed, then sent to the browser. This is a one-off longer load. Each node will preserve the asset until your site is re-deployed and the asset changes.

Other caveats (such as password protecting your site – either site-wide or using Basic-Auth – or fingerprinting your assets) will jeopardise how or whether we cache your content.

RE: [3]
You can always check out our Statuspage for our service health.

It may be the case that your other site was smaller, and/or you were closer to the server than our CDN. You may be unfortunate and requesting assets which the CDN hasn’t cached (common for frequently deploying, low visitor sites – especially if files are hashed).

Again, feel free to provide an x-nf-request-id and we can see which of the above possible causes may be in effect.

Thank you for the detailed answer! I tried to request the same page multiple times and I got mixed results. If I request a page for the first time, it takes about 500 ms or more. If I request it for the second time it takes about 200 ms (which is absolutely fine). If I wait a minute or two and I request it again I am back to the 500 ms response time. This suggests me:

  • page size is not an issue. The pagesize is usually arround 10—20 Kb.
  • the distance from CDN does matter but it does not explain the 300 ms gam between the first and the second request.
  • my internet or device speed/stability is fine (and I let my friend test it with the same result)
  • DNS should not be an issue (I use your DNS anyway).
  • I do not use password protection.

The only thing that makes sense to me is the cache. If I almost always miss the cache and the CND has to download the content from the US origin server then the numbers make sense. But I have not done any release in eight hours yet I see cache misses all the time. You can try for yourself. Measure response time for Důkaz sporem — Matematika polopatě, do more measurements in a quick succession and then wait a few minutes. Every time I try it I get the same result. After a while it gets slow again.

I tried to request a page with x-nf-request-id=317b4984-18fa-4358-93a9-b74a64876f9a and the response time was about 700 ms and the wait time was also about 680 ms.

It’s worth noting that a CDN node is actually 10… 20… 30 nodes! So, let’s say your nearest CDN PoP is Frankfurt…

  • When you first deploy your site, and first browse to the homepage, let’s say that node number 8 in Frankfurt responds to your request. The homepage was not cached as this was the first ever visit to your site. So, the node it will request the data from the Origin, in the US… then, it’ll serve it to you.

  • Your browser may serve this from memory, if the content is unchanged, when you refresh.

  • Eventually, you’ll re-request this data (hard refresh) and there’s no promise that node 8 (which has already seen your homepage) responds. Another node, which has yet to cache the content, may serve your homepage. If this is the case, it repeats the steps in step 1.

  • In time, most/all online nodes will have cached the homepage :tada:!

  • But remember: the cache for each request is unique! This scenario will be repeated for all pages on your site. A random, available node will fulfil your request, each time.

We’re always looking at how we can improve this scenario to improve first load times.

Unfortunately, your x-nf-request-id appears to be invalid! But, what I can tell you is that:

  • www.matweb.cz/dukaz-sporem was requested 35 times in the last 2 days
  • 10 cache hits
    • approx. 1ms response, not including latency between the CDN and you
  • 25 cache misses
    • approx. 400ms response, not including latency between the CDN and you

So, you’re right, it’s a caching scenario. With low traffic sites, this is exemplified but provided that your content doesn’t change all too often (see this for more info on how we cache) more nodes should cache your content and deliver it faster!

Ah, now it makes sense! If there are about 30 different caches and I have about 300 different pages on my website I can expect up to 9000 slow requests per release. Unfortunately, that is too much slow requests. It seems Netlify is not well suited for my needs :frowning:

I do have one more question, though. I tried to measure response times using curl in the command line and I noticed curl is somehow slower than when I measure the same URL in Chrome dev tools. Do you have any idea why? E. g. why was the request with x-nf-request-id: 01FGGJ6R0VYPNBMH5RR9BYDXWV slow? According to the curl statistics the TTFB was about 0.4s and whole response time was about 0.6s. The same URL (and others) were significantly faster in Chrome (even if I turned off the cache in the browser).

Hi @lukashavrlant,

Just like @Scott explained above - it’s a matter of which CDN node responds and in how much time. Chances are the ones that served curl took longer than the ones that served Chrome.

I’d still consider curl to be the source of truth.

I do understand that. But the page I requested via curl have been visited by hundreds of real users since the last release (according to the Google Analytics) and hence I suppose it should be cached on all nodes by now. I find it hard to believe that I would hit with the curl the nodes that have not been hit by any real user in the last three days. I gave it another try. I have requested Sčítání, odečítání, násobení a dělení zlomků — Matematika polopatě a few more times and I got multiple responses with TTFB greater than 0.4s. And I’ve generated them in the last 15 minutes. These are the x-nf-request-id IDs:


It’s 11 responses. And there have been no release of the website in the last three days and hundreds of real users have visited the same page. So was I just extremely unlucky and have I requested the nodes that were not requested by any real user in the last three days…?

Here’s the data I got:

(Req. ID - Status - CDN Node #)

01FGGNPH105Y419TYT8QZ12N2R: MISS #05
01FGGNYGQC5H322M338WB48QV9: HIT  #12

As you can see, each of these requests was served by a different node. While yeah, it should have been cached based on your description, but it could also have been dropped from cache if it was 3 days ago - I’m just making a guess as I don’t have reports to back that up.

I can see that 241651 346341 (~70%) of your traffic in the past 7 days has served through cache - which to me sounds like a good number.

But yes, chances are even with the cached status you might be getting TTFB > 0.4s.

1 Like

Ok, thank you for all your responses. I understand it now and I have no more questions! :slight_smile: