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 performance, touching various topics:

• 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

This series of blog posts is about the network related performance issues.The goal is to give you a set of tools to use that will provide you with insights that help you deliver fewer and shorter loading screens to your customers. Because what is more annoying than waiting for a page or a screen to load?

I would like to start with the first tool I have used regarding performance monitoring: Zipkin“Zipkin is a distributed tracing system.” states the website. The Zipkin library consists of a server which collects the traces and clients that send the trace information to the server. There are many Zipkin clients for various languages, such as Javascript, C#, Go, Java, Ruby, and Python. There are also premade instrumentations for libraries, for example, express, fetch, Postgres, and Redis.

A screenshot from Zipkin

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.

Performance Monitoring for the Frontend — An introduction was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.