Best Synthetics type to monitor TTFB?

So I was wondering which is the best synthetics monitor type to check on ttfb’s for multiple sites/customers.

At first I had a look into a Simple Browser monitor because it already includes a First Byte attribute.

If you look into the NRQL query then it says:

SELECT average(durationBlocked + durationConnect + durationDNS + durationWait) as 'First Byte' FROM SyntheticRequest WHERE monitorName = 'xxx' AND isNavigationRoot is true  TIMESERIES auto

Here I already got several questions.

Do I have to keep the isNavigationRoot is true for synth browser?

In this forum discussion it was suggested to use the duration attribute.
Does that mean that the Synthetic Request duration == durationBlocked + durationConnect + durationDNS + durationWait ?

Then I was also wondering if the normal ping monitors are better suited for TTFB checks as they do not emulate a whole browser have less load in general and less impact to the customers site as suggested here forum post

Would I calculate my first byte the same way here?

  • average(durationBlocked + durationConnect + durationDNS + durationWait)
    Does that apply for Simple Browser and Simple Monitor in the same way?

Also I have set up a test dashboard for the same url to compare the values from the two resource types and it seems that they differ.

Hello @louhnmn.

Welcome to the community!

Thank you for such a detailed first post. While I am not a support engineer and this is quite a bit out of my scope, I am going to loop one of our engineers in to assist in answering your questions. They will reply on this post when available. We appreciate your patience.

Please reach out if you have other questions or need anything else and we will be happy to help!

Hi @louhnmn - let’s see if we can help with Time To First Byte:

Time to First Byte (TTFB) refers to the time between the browser requesting a page and when it receives the first byte of information from the server. This time includes DNS lookup and establishing the connection using a TCP handshake and SSL handshake if the request is made over https.

In my experience TTFB is most often calculated using Synthetic monitors as they already contain the data needed:

  • In our Synthetics Monitors the this TTFB is made up of the attributes you have listed above:
    TTFB = durationBlocked + durationConnect + durationDNS + durationWait

  • isNavigationRoot is a boolean value that indicates the start point of request navigation in a scripted browser Synthetic Request Data Dictionary.

Browser Monitors also have the ability to report TTFB:

  • duration is a Browser Monitor Page View metric providing browser response time in seconds. Derived from the Navigation Timing API as loadEventEnd minus navigationStart - as described here: PageView Data Dictionary

  • Here is a good resource regarding building out dashboards, including TTFB, around the Browser Monitors and the Navigation Timing API : Relic Browser Dashboard Time to First Byte (TTFB).

Ping monitors are looking for an HTTP response code in the 200-300 range. The Request/Response and Connection Time results are related to network response times and can be broken down further as needed to find network bottlenecks. Details here on the Summary Results.

Do let us know if that helps get your TTFB dashboards up and functioning!

1 Like

Hi @jpotter1,
Thanks for your informative reply. It already gave me big insight.

I examined my initial post and it feels like it was not that well structured and a little messy.
Maybe it is because I wrote it in a hurry and could not make my points clear enough or didn’t think it through.
So that’s why some questions are still open to me or I didn’t fully understand them yet.

Focusing on synthetics only:

The attribute duration is available for all the synthetic monitors, cause it’s included by the SynteticRequest data type as stated in the Synthetic Request Data Dictionary - Duration.

Ping monitor:
It seems to me that the duration attribute exactly matches the term durationBlocked + durationConnect + durationDNS + durationWait.
This is also what my test dashboard showed me, when I compared the queries.
The curves resemble very well, even the values seem to be almost equal.

See here:

Simple browser monitor (the synthetics monitor for page load performance)
With the Simple browser monitor I tried the same but the data seems to differ from each other.

See here:

I mean the curves do not deviate a lot only in a few points but still here for the synthetic Simple browser it seems that:

  • duration != durationBlocked + durationConnect + durationDNS + durationWait
  • Are there still some attributes that add up to the equation?

I don’t quite understand that because I thought that it is the same for every SyntheticRequest type.

So the big overall question for me is basically: which synthetics type can I trust for ttfb when the same query for different monitor types shows different values?


Regarding the real Browser monitors from the browser module I can only say that we are not using that currently. Only synthetics right now.

That’s why the proposed dashboard is not really suitable for us cause it uses - as you said - the PageView metrics from the BrowserInteraction data type and as far as I know you cannot use this type for synthetics.

But yeah I guess this would be another route to monitor TTFB’s (maybe even the best?).
Installing the NR agent script on the customer’s frontend having all the live metrics.

But just right now we are stuck with synthetics.

Hi @louhnmn
Thanks for the info and taking the time for those lovely visuals, definitely helps illustrate what’s going on!

When I saw your numbers were smaller, I realized I must have missed some information in my previous reply. So, I took a bit of time and recreated your examples to see what was happening.

:point_right: It turns out that the Synthetic Request duration attribute is made up of a sum of 7 attributes, not just the 4 I listed above:

  • duration = durationBlocked + durationConnect + durationDNS + durationWait + durationSSL + durationSend + durationReceive
  • These are the 7 attributes that make up duration in a SyntheticRequest

These two graphs illustrate three duration calculations on both a Simple Browser and a Ping monitor:

  • average(duration)
    • our baseline for comparison
    • data points are calculated on the backend
  • average(durationBlocked + durationConnect + durationDNS + durationWait)
    • this is what I erroneously provided above :see_no_evil:
    • data points are summed in the query
    • lower numbers due to missing data points
  • average(durationBlocked + durationConnect + durationDNS + durationWait + durationSSL + durationSend + durationReceive)

Try these two NRQL Queries, they should return the same:

SELECT average(duration) FROM SyntheticRequest WHERE monitorName = '<awesome test monitor>' SINCE 30 MINUTES AGO TIMESERIES

SELECT average(durationBlocked + durationConnect + durationDNS + durationReceive + durationSend + durationSSL + durationWait) WHERE monitorName = '<awesome test monitor>' SINCE 30 MINUTES AGO TIMESERIES

Do let me know if that was it, if so I’ll gleefully update my previous reply with a more correct answer.

1 Like