Alert on time to interactive

I have alerts on “page load time”, which seems to be “the time it takes for all JavaScript to finish executing”. This is not a useful metric, because the user can do what they need on the page well before that happens.

I’d like to alert on time-to-interactive. In session traces, I can see the event domInteractive, but I cannot for the life of me figure out where this shows up in New Relic. I have gone through docs and NRQL and cannot figure out where it might be. I can measure “first interaction” time, but this is not what I want (that appears to be when the user does something).

To me, measuring TTI is the most basic front-end measurement of web performance, so I must be missing something. Can anyone help?

New Relic edit

We take feature ideas seriously and our product managers review every one when plotting their roadmaps. However, there is no guarantee this feature will be implemented. This post ensures the idea is put on the table and discussed though. So please vote and share your extra details with our team.

Hi, @dave12: You are correct that New Relic Browser does not provide time-to-interactive (TTI) out of the box. Beginning with version 1177, the Browser agent supports Google’s Core Web Vitals, including Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift. More info here: https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/pageviewtiming-async-or-dynamic-page-details.

Calculating TTI is a bit more complex; this article details a nice way to add it to your site. After you have added TTI support, you may call the Browser agent’s finished() function, or add a page action or custom attribute to send the value to New Relic.

If you just want to track domInteractive, you can use the domProcessingDuration attribute of the PageView event.

Hi @dave12,

Building on Phil’s responses a bit here… you’re not overlooking anything - we’ve made the choice not to report the time to interactive (TTI) measurement. Because of the nature of the measurement, it’s better suited as a lab measurement vs. a measurement of real user experience.

Generally, to get a similar sense of how your application is performing for your end users, we suggest looking at the firstInputDelay data, which falls in between our FirstContentfulPaint timing and the Time to Interactive (TTI) . This is going to tell you how long it took from the time when a first input can be made and when the browser’s main thread is able to respond to any interactions. It’s not an exact match for TTI, but we believe it should provide an accurate representation of how responsive your site is in real user conditions.

@philweber’s first post is helpful, thanks! I’m going to look into alerting on those and not try to deduce TTI, though it is super frustrating that New Relic clearly has access to when the dom becomes interactive but does not provide that value in its metrics.

The problem I’m having is that the documentation is vague and disconnected from what I see in the web UI. For example, if I find that my website has an unfavorable value for “largest contentful paint”, there is no way that I can find to observe that in a session trace. The waterfall diagram doesn’t show any of this stuff. It seems to be showing an entirely different set of values than what is available via PageView or PageViewTimings and the documentation doesn’t provide a connection between the two sets of values.

Given that “Page Load” is meaningless (since it counts async scripts that have do not prevent the user from using the page), what is the “new relic happy path” for measuring front end performance? I just have simple web pages that are rendered on the server.

@dave12 Thank you for the great questions! I wanted to follow up on your alerts creation using domProcessingDuration and how it was going?

I wanted to share some additional items since you mentioned the metric largest ContentfulPaint and were asking about measuring frontend performance. The charts for Core Web Vitals in your dashboard include metrics such as cumulative layout shift, first input delay and largest contentful paint. For more context, these charts are somewhat new to the UI, having been added a couple of weeks ago (to more easily see this data when in your application dashboard.

To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading and a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices. Please see links here and here.

I hope that adds some more detail on PageViewTiming, LCP and measuring Core Web Vitals (and where to find this data in your account). Thanks!

The problem is that the session trace shows totally different data. LCP is not shown, for example, so if I my app starts to get an increase in LCP, I have no real way to diagnose why that might be, since the session trace shows a totally different set of data—it definitely does not seem to show any Core Web Vitals.

What’s super frustrating is that I really want to measure DOM interactive and it is on the session trace, it’s just not a metric New Relic makes available. Would love if it could do that.

Hi @dave12, I have gone ahead and submitted a feature idea for our product review team to potentially make TTI reportable.

I have +1 this internally and if there is any movement on this, I will update the thread.

Great, thanks!!

(these characters added to appease Discourse

Hi all cc/ @dave12 & @nmcnamara , I want to clarify the key points in this request and why there seems to be some confusion.

1. Time to interactive is NOT domInteractive. Those are very different metrics with extremely different outcomes and goals. We do report domInteractive in BrowserInteractions, but it likely is not what you are looking for if you are trying to gauge page readiness.

2. Time to Interactive is part of the suite of perceived performance metrics developed by the team at Google and is squarely listed as lab-only, meaning we do not capture and report it for Browser (aka Real User Monitoring) data. First Input Delay (and the other Google Core Web Vitals) are the most modern recommendations for reporting performance. I recommend reviewing our documentation on the PageViewTiming event where you will find all the latest metrics you are looking for!
   

   

   Core Web Vitals.jpg1912×1062 241 KB

And, if you want to go a step further, I recently gave a talk on the subject!

I hope this helps!
Lindsy

OK, this is helpful info re: domInteractive.

I am tracking the the metrics you are referencing, but this leads to another problem which is that if my app experiences poor performance there’s no way; that i can see to diagnose this using New Relic, because the session traces don’t show anything about LCP, FID, or CLS, and I can’t correlate a triggered alert on front-end performance with what users might be experiencing to fix it.