Evaluating React Application Performance with a Sip of RUM

Hello, everybody. How are we all doing? Whoo! Good. Now, I'm going to disappoint you. There is no drinks in this talk. I'm going to be talking about Rome. I'm going to explain what that is. I'm going to talk about OpenTelemetry and how each of these can be used to identify performance bottlenecks and various issues within our React applications and how you would go about doing that.

Oh, dear. There we go. Right. So, first thing I'm going to talk about is the pillars of observability. Or if you do know Otel, then you know these as signals. So, if we think about in an agnostic terms outside of React ecosystem, how we figure out if our particular application is going wrong. There's normally three different types of signals.

So, with each of these, raise your hand at any point if you actually collect these in your app. So, how many people are looking at logs or collecting them somewhere? I'm slightly worried that there's some hands that are not up. If there's a reason for this, let me know. But we all know what logs are even if we're not collecting them. It's those wacky structured messages, sometimes that are useful, sometimes that are not so useful, that we have omitted from our application, either as a warning of something happening, as an indicator that something has happened or an error that's going to tell us that we need to run and panic and go and fix something.

The second thing we can collect is metrics. Does anyone collect any metrics? Okay. So, the same number of hands. That's kind of positive. So, metrics, we might think of things like throughput, we might think of latency, maybe you want some custom ones like number of requests or something useful towards a particular component or page within your React app. But the common one we'll think of is core web vitals. Have we all heard of core web vitals? I've got some nods and some waves and some people looking very confused and scared. That's fine. So, for those who are looking confused and scared, core web vitals are a set of kind of user-centric performance metrics. If you ever looked in your Chrome DevTools and saw the little lighthouse tab, then you'll probably go in and have a look and see these random measures that you don't necessarily understand what they are. But they're an indication of the performance from a user perspective.

We're not going to talk about core web vitals and details for this, but it's a common standard measure that you can use. It's a rough indication as to whether the user experience is going to be reasonable or your page is taking an age to load and you should probably do something about it.

The third thing we talk about is traces. So, who's collecting those? And there's far less in the room, which kind of made sense. Right. You probably are using traces and didn't think about it. I think my laptop wants me to update. We're not doing this right now. It's not the time, laptop. We're fine.

So, what are traces? You've probably been using these and not really thinking about it. What these traces are, in simple terms, going back, there we go. Is a process of seeing through the pathway of your application what's being called. So, this could be relating to function calls. This could be relating to network calls. Maybe your React application is firing off to different services. But the thing that a trace often gives us, as well, is the knowledge of how long something is actually taking to run through.

Which is why they're normally pretty useful. If you're wanting to identify a bottleneck and you're going through, you know, three, four microservices deep, you probably want to see which one of those is taking a bit of a long time. So, when it comes to tools that we can use for collecting each of these types of things, one of the common open standards is what we call open telemetry.

Show of hands, who has heard of open telemetry? Good. Cool. Happy. So, for those who haven't heard of it, it is an open standard set of APIs and tools. Basically pioneered as part of the CNCF foundation. And what it allows you to do is in a language-agnostic way, as long as there's an appropriate supported SDK, allows you to collect those pillars or signal types I just talked about.

And with regards to the state of adoption in the JavaScript ecosystem, it's a bit of a mixed picture, because traces and metrics are currently stable. So, by all means, go off and use the SDK, and you can run it within node and do some stuff on the web as well, and that's great, because we can get some telemetry information from our React application for what's going on. Logs is in development. We'll see what happens with that.

But if we think about React and the front-end perspective and the client instrumentation, you'll see there's a big warning behind me. That basically, it's experimental and mostly unspecified. Now, there is a SIG group that is doing some really fab things. But the problem is that it's not quite there yet.

So, this is a big code snippet. Really high. You can go and check out the open telemetry demo. Within the open telemetry demo, they have an example using React that shows the front-end tracing snippet that I've got here. So, what you have to do is specify a web trace provider and give your name, your appropriate application a unique service name, and from there, what you'll do is add in the context and the auto instrumentations, and that will give you some pretty cool stuff out of the box. It's going to give you some basic metrics, albeit there's some other stuff that's coming along, but it also gives you a good idea of the tracing.

So, here's the example from the front end within the open telemetry demo. And what you can see is, I can see quite well that there's an HTTP POST request being initiated, and I can also see the pathway through the proxy, which is always very interesting to know. And I can see how long each of those steps is taking.

Because there's quite a few things that they're working on at the moment in the client seg that's actually work in progress. And one of them is those core web vital metrics that I was talking about before, alongside some other ones, such as the page view event stuff. With the emergence of events over time, I'm hoping that we won't need to use other particular types of tools, and you can hopefully use an open standard alongside the same thing for any back-end services that you're talking to.

But for the moment, that means we need to crack out the rum. As I said, I'm not talking about the favorite beverage of pirates, or maybe some of you in the audience today, I'm talking about real user monitoring. And the way that this works is you have an agent that you run within your JavaScript application that picks up those pieces that are currently missing from the open telemetry ecosystem.

So, in conclusion, we talked about logs, metrics, and traces, and why we should capture them, and found out who is capturing them and who isn't. If you're interested, check out that example for the RUM agent, the open telemetry demo and GitHub as well, or come and ask me questions. Thank you.