Frontend Observability Explained

Observability refers to the ability to gain insights about the performance, behaviour, and health of application by collecting and analysing relevant data. In terms of frontend observability, It involves monitoring various aspects of the website, such as user interactions, web vitals, page load times, error rates, and resource utilisation, to ensure a seamless and optimised user experience.

If we deep dive, Frontend Observability has few major components:

Metrics

Imagine you’re trying to measure how well your favourite sports team is doing. You’d look at scores, right? In the digital world, we use something similar called metrics. These are numbers that tell us how our systems, websites, or apps are performing.

• Web vitals

A bunch of tech wizards from Google, alongside the web community, initiated a guideline for core web vitals for website. Web vital metrics were designed to offer a standardised approach to measuring and quantifying the user experience. Let’s discuss few commonly used web vitals.

• TTFB: Time to first byte is an indicator of how quickly a browser receives a first byte from the server. The number should be below 500ms.
• LCP: Largest Contentful Paint. Ever clicked on a link and waited for an eternity for something to show up? That’s where LCP steps in. It clocks how fast the main stuff on a page appears. To be in the good books, aim for an LCP of under 2.5 seconds.
• FID: First Input Delay. Imagine trying to click a button, and it feels like the webpage is napping. FID times how quickly a page responds to your first interaction. Should strictly be below 100ms, because no one like the delays after interactions.
• CLS: Cumulative Layout Shift keeps track of surprise layout changes while your page loads. CLS should be less than 0.1.

Web vitals

• Errors

Error collection is crucial for understanding and managing the health and performance of a system. Error rate helps quantify the health of the system by indicating how frequently users encounter issues. A sudden spike in error rate can signal potential problems.

Knowing the specific types of errors occurring allows for targeted troubleshooting and resolution. It helps prioritise fixing critical issues affecting user experience. Further, the observability tools can also catch the stack traces which makes debugging easier.

Logging

Logs are detailed records generated by a system or application, capturing events, actions, and custom messages logged by developers. Logs are like a dairy for the system. The assist in understand what’s happening to system in your absence.

• Event logging: Any sort of event can be logged. Helps to understand the activities happening around the system.
• Troubleshooting: Detective logs. Providing clues what potentially went wrong. When things go not as expected, these logs can help detect a problem.
• Alerts: These are like a friend informing you when your coffee is too hot. Helps in detecting problem before the come back as severe one.

There can be many and many use cases of these loggings e.g. tracking user journey, using logs as history book, etc.

Tracing

Tracing is like tracking a package, following its journey from one stop to another. In terms of observability, it helps you monitor how requests move into your system from one stop to another. Lets understand tracing in details.

Let’s assume you order a product online and want to track the shipping of your order. Tracing in observability is like a detailed map of your order journey from it’s packing to when it is delivered to your door.

Similarly, when you click “order” button on a website, it triggers few operations behind the scene. Your “order click” event means exactly same to the developer that your order tracking meant to you earlier. Tracing helps developer monitor each step of user’s request. From the click of “order” button, rendering, a request to backend service and all the way to database operations. Developer can track entire path and see how each step performed.

Therefore, just like your order package would have some trackingID, similarly this trace also carries a tracingID which propagates throughout the system for tracing.

In tracing, we name each step as “span”. Span could be Database Query, API calls, rendering etc. For each span, a timespan is noted, from start to end in order to monitor the performance of each step/span.

But wait, why do we care about tracing? If your online store’s delivery process is slow, you would surely want to know the reason to actually what step is causing the delay in process. Similarly, if the API request to place an order is slow, it is important for developer to know that exactly what part of system is causing delay.

However, tracing is not just limited to trace the API requests, we can also trace the user journey which could assist in improving user interaction on the apps.

Tracing plays a crucial role in optimising the system performance and trace the potential bottlenecks. Also is can help in debugging also understanding what part of system actually caused an issue while processing a certain request from start to end.

Integration

If you want to enable the observability for your application, here is a follow-up article to integrate observability into your app. Frontend Observability using Grafana Faro.

If you think that something is missing or could be better interpreted, please drop a feedback, would love to incorporate. Else 👏 👀

Disclaimer:

Bazaar Technologies believes in sharing knowledge and freedom of expression, and it encourages it’s colleagues and friends to share knowledge, experiences and opinions in written form on it’s medium publication, in a hope that some people across the globe might find the content helpful. However the content shared in this post and other posts on this medium publication mostly describe and highlight the opinions of the authors, which might or might not be the actual and official perspective of Bazaar Technologies.