Performance Monitoring for the Frontend — An introduction

Over the course of this year, I have seen a lot of talks given at different conferences around the globe. Quite a few of them had the focus on , touching various topics: performance Remove jank from your application Have a faster time to screen or interaction Load only the data you need when you need it through GraphQL + Apollo or Relay Optimize your redux-thunk or redux-saga to load data faster or prefetch specific resources Terminology To get you started in the tracing context, we need to define the things we talk about. Luckily there are already terms in place, so let’s go over them together: Instrumentation An instrumented version of something, let’s say an API Client is a version that extends the original one by adding tracing to it. In our case, this might be a fetch API sending not only the payload itself but also an update to the Zipkin server with tracing information. Trace A Trace (see image below) describes an interaction (e.g., a user interaction or an API call) with a particular focus on execution timings. It consists of *Spans* and their dependencies with each other. The topmost and earliest span is called the *Root Span*, it is typically the interaction that triggered the workload, and it is on the outer edge of your system. Each Span can be the father of another span, similar to a function being able to invoke others. Zipkin automatically orders the spans to go deeper under each other if there is such a child relation. Services Have you noticed the blue labels on the very left of the image below. These are called services, and they are configured when building the tracer. Think of them as the different layers of your application. You might cut them to your specific needs: If you have one express API, it might be the various middlewares that you want to separate into services. If you have a microservice architecture, each service might have its layer. Logs and Tags Searching particular spans with specific properties would be tedious if it wasn’t for logs and tags. They map string keys to values and allow a smooth search in the user interface. The difference between a tag and a log is that tags can be thought of as a per span annotation whereas logs have a time component. As far as I can see Zipkin doesn’t honor this difference, but it is still nice to know what the community is talking about. If you would like to know more about the terminology check out the . opentracing specification You read until this point, so it seems like you are interested in this topic. I have a follow-up article for you where you can see these terms in action. We will learn how to add monitoring to your application through Zipkin: Performance Monitoring for the Frontend — Using Zipkin Want to hear more from me? Feel free to subscribe to my newsletter, I send out news roughly once a month.