Home
Support Forums

Expected TTFB / response time for cache miss

I am evaluating Netlify and a couple other vendors. I have some questions about TTFB and your standard edge vs high performance edge.

Here are my questions:

  1. What is the average TTFB / response time for static files (HTML, CSS, JS, images, etc.) on your standard edge?
    a) What about for cache misses only (sometimes called miss latency)?
    b) What about for cache hits only (sometimes called hit latency)?
  2. Would the hit latency and miss latency be the same for the high-performance edge? I understand that the hit rate is higher so that will make it faster on average, but I’m still interested to know if the miss latency is any different.

I would understand if you don’t have all those tracked. The most important one is the miss latency (TTFB / response time when the cache misses).

I’m asking because my project has high expectations for TTFB on cache miss (but the files to deliver are always static HTML / assets).

Let me know if I can clarify anything.

While you wait for a more detailed answer, I can answer this part to some extent. I’m using the standard (free) plan and the TTFB depends on access location. For example, if my website has got not many users from a particular area, my website is removed from the CDN cache and then, the TTFB goes up to around 700 ms (accessing from London). However, when accessing from United States, the TTFB is around 130 ms in my case.

Hi @hrishikesh, thanks for sharing your TTFB data! It looks like the TTFB for a cache miss you see is around 700ms.

@support_staff, what TTFB range would be considered acceptable for a cache miss on Netlify? I’ve seen the other community articles about TTFB and they don’t seem to answer that question.

What is the TTFB range you would consider to be normal / supported? Imagine if I was a paying customer and opened a support ticket for high TTFB on cache misses. What TTFB would be high enough to warrant a fix? 800ms? At what point would you say it’s in the acceptable / supported range and decline to fix it? 400ms?

Hi folks!

Good question and happy to help out with a staff point of view.

Executive summary: At a high level, our standard CDN has a lower cache hit ratio than the high-performance edge, and the larger number and better distribution of CDN nodes on each network will combine with that to in general give better performance on our high performance edge.

Stats change over time, but in the past hour, here’s a snapshot of what I see across each of those CDN’s:

standard

  • average response time (we can’t measure TTFB since that is from a browser point of view; instead we measure time from receiving the request, to sending the last byte) is around 100ms across tens of millions of requests, with average size of 17,859 bytes for those assets.
  • for cache misses only, that’s around 250ms with average asset size of 17,669 bytes
  • for cache hits only, that’s around 80ms with average asset size of 18,128
  • cache hits are around 80% of that traffic.

high performance

  • average response time is also around 100ms across millions of requests, with average size of 26,447 bytes for those assets.
  • for cache misses only, that’s around 350ms with average asset size of 31k
  • for cache hits only, that’s around 50ms with average asset size of 25.7k
  • cache hits are around 93% of that traffic.

I didn’t do any deep analysis of why this hour had a slower cache miss average send timing, but that could be based on a lot of things - the kinds of sites customers host on that CDN are typically different than the ones hosted on our regular CDN (deploy more frequently, have more assets, etc). I’d bet there are a much higher percentage of files that we’d never cache such as large zips or PDF’s (we do not try to cache really large files on any of our CDN’s except those handled by our large media service.

To answer your direct questions from the followup:

@support_staff, what TTFB range would be considered acceptable for a cache miss on Netlify? I’ve seen the other community articles about TTFB and they don’t seem to answer that question.

We don’t really specify a “standard,” but we in general don’t really try to debug deeply if it is under around a second. I would expect it to be over a second for the very large files I describe above, but if your file are all under say 3 MByte they will all be quite cacheable/should serve fairly quickly. I don’t have an exact number where we cut off caching.

If you saw a higher TTFB than a second on average, we’d be happy to look into it at any account level. If you’re on the high performance network, you pay enough that we will look into it for lower numbers too - we just can’t afford to deeply debug slightly suboptimal behavior (which quite often turn out to have a cause like “your internet is slow; your site visitors on average see a total response time of 100ms”) for someone who is paying us $0 or $19/mo. We will take a look, but we will almost certainly ask for your help in showing the problem, particularly if our logs show uniformly fast sends. In about 10% of the reports we see, a DNS misconfiguration or other config setting is causing the problem and the situation vastly improves with a simple config change - so it always makes sense to ask if you see something you think should be better!

At what point would you say it’s in the acceptable / supported range and decline to fix it? 400ms?

Our support team doesn’t do the fixin’; our network engineers will make the call as to what is needing fixing on a case-by-case basis after we escalate to them. We would be unlikely to escalate anything under 400ms even for our VIP customers, though this like everything is open to debate based on circumstances.

Thanks for all the info! This is what I needed.

1 Like